There was also an earlier entry where it was "Tom's Own Markup Language" (2013-02-24):
TOML: Tom's Obvious Minimal Language
61–70 of 229 posts
Re: TOML: Tom's Obvious Minimal Language
#62JSON 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.
I'm unconvinced.
Re: TOML: Tom's Obvious Minimal Language
#63JSON 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
Until you realize you can't actually store real integers because every number in js is a float...
Re: TOML: Tom's Obvious Minimal Language
#64JSON 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
Re: TOML: Tom's Obvious Minimal Language
#65JSON 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.
Re: TOML: Tom's Obvious Minimal Language
#66JSON 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
{name: "value"}
And then maybe 123_456 syntaxIt's a slippery slope ... pretty soon it's hard to write a JSON parser, and there are more bugs
The trailing comma one is trivial, I'll grant that
Re: TOML: Tom's Obvious Minimal Language
#67Earlier quoted context omitted.
I moved some config files from json to yaml. Maintaining the documentation became a lot easier, because before I had a document describing every config option, which I had to maintain separately, instead now I have comments in the config file itself.
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.
Which is 14 years old.
EDIT: this sounded adversarial which was not my intention. Plenty of libraries do not support 1.2 which sucks, I just meant that it's something solved in theory a long time ago.
Re: TOML: Tom's Obvious Minimal Language
#68Re: TOML: Tom's Obvious Minimal Language
#69I pretty like the idea of a superset of JSON that supports (1) comments, (2) trailing commas, (3) unquoted properties, (4) optional {} for the root object, (5) multi-line strings, (6) number separator. JSON6 proposal [1] supports all of this, except (4). Unfortunately it also supports more and make the spec a bit too complex for my taste (JSON has a compact spec; any extension should honor this). Same issue with JSON…
Re: TOML: Tom's Obvious Minimal Language
#70I pretty like the idea of a superset of JSON that supports (1) comments, (2) trailing commas, (3) unquoted properties, (4) optional {} for the root object, (5) multi-line strings, (6) number separator. JSON6 proposal [1] supports all of this, except (4). Unfortunately it also supports more and make the spec a bit too complex for my taste (JSON has a compact spec; any extension should honor this). Same issue with JSON…
Comments are preserved when you read a file, change some of its contents, and write it back out again.