51–60 of 229 posts
Funny thing: TOML author/inventor calls it a mistake: > TOML is a bad file format. It looks good at first glance, and for really really trivial things it is probably good. But once I started using it and the configuration schema became more complex, I found the syntax ugly and hard to read. > I personally abandoned TOML and as such, I'm not planning on adding any new features > If you're still reading, I'd like to pu…
JSON is basically perfect if it allowed trailing commas and comments. TOML is not a replacement for JSON because of how badly it chokes on nested lists of objects (being both hard to read and hard to write), due to a misguided attempt to avoid becoming JSON-like[1]. [1] https://github.com/toml-lang/toml/issues/516
YAML is a proper superset of JSON.
Earlier quoted context omitted.
Among types and other useful properties, CUE supports everything you asked for. We're even considering adding a "data-only" mode to CUE which would be exactly what you asked for. https://cuelang.org
Is there any concise representation of the language spec? Similar to the spec of JSON [1]. [1] https://www.json.org/json-en.html
That being said, it would be nice to use railroad diagrams to describe syntax in our spec.
Earlier quoted context omitted.
Note that now you have "the Norway problem" instead. https://hitchdev.com/strictyaml/why/implicit-typing-removed/ There's a whole spectrum of config formats including JSON, JSON5, strict YAML, YAML. It's quite messy.
I found yaml to be surprisingly complex and tricky to write for how simple it looks. It is made to be beautiful and easy for a human to read, but the trade-off are a lot of implicit rules you need to be aware of.
Earlier quoted context omitted.
That's already fixed; in the upcoming TOML 1.1 you can write: tbl = { hello = "world", } All the examples in the issue you linked should work. https://github.com/toml-lang/toml/pull/904
published data standards having version is so wrong. now if you see "config in yaml" you know nothing, zero, nada, about the format because all versions are so different and everyone implemented the version at the time and didn't bother to mention version. not to mention you can use a dozen syntaxes for yaml/toml and each application may not understand them all. all this is so silly. we will stick with json and infor…
Many commonly-used standards today weren't created by a bunch of wise men in a room thinking how to bestow their wisdom upon the rest of us, they often originated in real-world applications, were refined over a period of time based pn real-world experience, and then became a standard.
TOML is the same. I hope it will become an RFC some day. We just need to fix a few outstanding issues first.
Most commonly used TOML parsers support 1.0; adding 1.1 support should be pretty easy as the changes aren't that large (I did it in the parser I maintain, and it's 10 lines of code or so that had to be changed, most of them quite trivial).
JSON is basically perfect if it allowed trailing commas and comments. TOML is not a replacement for JSON because of how badly it chokes on nested lists of objects (being both hard to read and hard to write), due to a misguided attempt to avoid becoming JSON-like[1]. [1] https://github.com/toml-lang/toml/issues/516
The problem with comments in configuration files is that they don't survive a `load -> native object -> save` round-trip.
The one thing I wish TOML had added was null. Today many TOML configs still have “nullable” keys which means you need to comment them out to unset them.
The Billion Dollar Mistake lives on. Personally I'm happy it doesn't have explicit null and somewhat surprised it supports NaN (which I thought it didn't) To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound.
If you are referring to Tony Hoare, the “billion dollar mistake” was not the existence of nulls per se, but that all references were nullable, with no support in the type system to distinguish between nullable and non-nullable references.
JSON is basically perfect if it allowed trailing commas and comments. TOML is not a replacement for JSON because of how badly it chokes on nested lists of objects (being both hard to read and hard to write), due to a misguided attempt to avoid becoming JSON-like[1]. [1] https://github.com/toml-lang/toml/issues/516
Are you talking about https://github.com/toml-lang/toml/pull/904 which is merged for 1.1, or something else?
JSON is basically perfect if it allowed trailing commas and comments. TOML is not a replacement for JSON because of how badly it chokes on nested lists of objects (being both hard to read and hard to write), due to a misguided attempt to avoid becoming JSON-like[1]. [1] https://github.com/toml-lang/toml/issues/516
That's already fixed; in the upcoming TOML 1.1 you can write: tbl = { hello = "world", } All the examples in the issue you linked should work. https://github.com/toml-lang/toml/pull/904