[Pxtl]

I'm sorry I don't see this adding value over various other formats. I don't really want a new object serialization format, I just want the existing ones to have the features I need. YAML but with static typing and schema. XML but without crazy internet features. TOML but with an object format that doesn't hurt my brain. JSON but with decent multiline strings and comments. NestedText but with a sub-standard that provides static-typing and schema and whatnot.

[tptacek]

This isn't really an interchange formula so much as something you'd JIT compile down to when handing things off to an LLM, right?

[furyofantares]

And on the way out of the LLM. Token savings nice on the way out too, and then also I have to imagine it's better for the LLM to see one format in all of it's context instead of two.

It seems like a nice idea to me if restricted to that. Although I guess I am not sure if it's really intended that way - the array count for example is probably pretty bad for LLM output.

[tptacek]

I feel like on the output side you might be working against LLM training? But I don't know.

[verdverm]

https://cuelang.org | https://cuetorials.com

CUE can emit the other formats (minus XML because it's a beast of ambiguity, but there are other tools for json->xml i.e.)

It also has modules and imports, a very underrated feature for config languages if you haven't experienced it before

[rs186]

I don't think you even need to care about this as a format. It could exist only during communication and encoded/decoded by middleware, and everything still works.

[foxglacier]

The benchmarks show it performs better than them, so that's the value - cost savings and improved accuracy. I suppose you could convert JSON to TOON just for the LLM and not actually read it with your own brain.