Looks like Microsoft's .INI file format.
TOML: Tom's Obvious Minimal Language
131–140 of 229 posts
Re: TOML: Tom's Obvious Minimal Language
#132Earlier quoted context omitted.
> JSON is basically perfect Until you realize you can't actually store real integers because every number in js is a float...
You can store arbitrary precision numbers in JSON. The spec explicitly doesn't lock you into floats or any other specific number format.
True. But the spec also doesn’t provide a way to tell if a stored number should be decoded as a float or an integer - which makes it a right pain to use correctly in most programming languages. I’d love it if json natively supported:
- Separate int / float types
- A binary blob type
- Dates
- Maps with non string keys.
Even javascript supports all this stuff now at a language level; it’s just JSON that hasn’t caught up.
Re: TOML: Tom's Obvious Minimal Language
#133Earlier quoted context omitted.
Only if you are both sides of the transmission. If you're sending JSON to code you didn't write you will eventually get bitten by software lossy re-encoding. Lots of places use strings for this reason. It's like API's that mess up the semantics of PUT/GET so implementing idempotency is extra annoying.
But JSON is strings. So 123.4 is essentially "123.4" but with the indication that it is supposed to be semantically a numerical value.
Right. I want to see an indication of what sort of numerical value it is. Big integers interpreted as floats lose precision. And floats decoded as integers truncate anything after the decimal place. JSON makes it way too easy to get this stuff wrong when decoding.
Re: TOML: Tom's Obvious Minimal Language
#134Earlier quoted context omitted.
You don't; you check the library or application's documentation. TOML went through some substantial changes in the past with 0.4, 0.5, and 1.0. As I mentioned in my other comment[1], it's not ideal, but it is what it is. I wouldn't be surprised if 1.1 would be the last version. Maybe there will be a 1.2 to clarify some things, but I wouldn't expect any further major changes. [1]: https://news.ycombinator.com/item?id=…
> You don't Great. Very obvious.
As much as it pains me to say so, this is probably fine for configuration languages so long as they’re backwards compatible. Eg toml is used by rust’s cargo tool. Cargo can just say “hey Cargo.toml is parsed in toml version 1.1 format”.
Re: TOML: Tom's Obvious Minimal Language
#135Using JSON for configuration was and continues to be a terrible blunder.
TOML fills that role wonderfully. And it isn’t full of complexity that turns Yaml into a mess.
Re: TOML: Tom's Obvious Minimal Language
#136I 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…
I like Google's Jsonnet [1], which has all of this except for 4. Jsonnet is quite mature, with fairly wide language adoption, and has the benefit of supporting expressions, including conditionals, arithmetic, as well as being able to define reusable blocks inside function definitions or external files. It's not suitable as a serialization format, but great for config. It's popular in some circles, but I'm sad that it…
Yeah, I like jsonnet a lot for config files.
Re: TOML: Tom's Obvious Minimal Language
#137JSON 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
> JSON is basically perfect Until you realize you can't actually store real integers because every number in js is a float...
JSON’s numbers are not IEEE-754. They’re numbers with an optionally infinite number of decimal places. It’s up to a parser to handle it. Python can parse these into integers if there isn’t a decimal place.
It’s in the name, but be careful not to get confused with JSON being JavaScript.
Re: TOML: Tom's Obvious Minimal Language
#138Using JSON for configuration was and continues to be a terrible blunder. TOML fills that role wonderfully. And it isn’t full of complexity that turns Yaml into a mess.
I've had the complete opposite experience. Neither YAML or TOML are very obvious to me. I always have to double and triple check that my syntax does what I assume it will do. I never have that problem with JSON.
Re: TOML: Tom's Obvious Minimal Language
#139Using JSON for configuration was and continues to be a terrible blunder. TOML fills that role wonderfully. And it isn’t full of complexity that turns Yaml into a mess.
I've had the complete opposite experience. Neither YAML or TOML are very obvious to me. I always have to double and triple check that my syntax does what I assume it will do. I never have that problem with JSON.
Not adding comments to a config file is recipe for complete disaster. You can kinda fake it but it’s just a silly headache. Which is recognized given there’s now “JSONC” but now you’ve got even more confusion determining what systems can actually accept comments or not. That’s always fun.
I’m curious what parts of TOML do people find confusing? It’s such a tiny markup language.