4 ms·
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 hav
by Pxtl 1y ago
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.
- foxglacier 1y agoThe 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.
- verdverm 1y agohttps://cuelang.org https://cuelang.org | https://cuetorials.com 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
- tptacek 1y agoThis 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 1y agoAnd 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 1y agoI feel like on the output side you might be working against LLM training? But I don't know.
- rs186 1y agoI 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.