Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TOML: Tom's Obvious Minimal Language

toml.io

Post reply on HN
Print view View original

21–30 of 229 posts

Re: TOML: Tom's Obvious Minimal Language

#21

Post by pydry »

SPBS wrote: post #10

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

I think this was partly what the pytoml author was alluding to when he slated the format:

https://github.com/avakar/pytoml/issues/15#issuecomment-2177...

Datetimes were clearly a mistake to include too. It took the M out of TOML.

Re: TOML: Tom's Obvious Minimal Language

#22

Post by KronisLV »

SPBS wrote: post #10

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

> JSON is basically perfect if it allowed trailing commas and comments.

I agree, especially in regards to the comments, because sometimes the data itself isn't enough and additional human-readable context can be really useful!

In that regard, JSON5 is a wonderful idea, even if sadly it isn't widespread: https://json5.org/

It also supports the trailing commas and overall just feels like what JSON should be, to make it better without overcomplicating it.

Re: TOML: Tom's Obvious Minimal Language

#23

Post by afiori »

lexicality wrote: post #15
afiori wrote: post #12

Earlier quoted context omitted.

CSS has two magic values that would be useful in many configuration scenarios: - unset: ignore values of this property - initial: use the default value These would be useful e.g. with overrides. I agree that nulls in a config files are often not a good idea because it is not clear how they are going to be interpreted. PS: Css also has inherit that could mean "use the local default" while initial could mean use system…

Unfortunately that's not what `unset` does and I feel like the confusion it causes and the complication it adds to any CSS parser suggests it's a bad idea!

lol, I guess this might be an argument against null

Re: TOML: Tom's Obvious Minimal Language

#24

Post by the_mitsuhiko »

arp242 wrote: post #11
the_mitsuhiko wrote: post #3

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.

It's been discussed a few times over the years: https://github.com/toml-lang/toml/issues/921 https://github.com/toml-lang/toml/issues/803 https://github.com/toml-lang/toml/issues/802 https://github.com/toml-lang/toml/issues/146 https://github.com/toml-lang/toml/issues/30 Obviously there is a bit of a demand, and it certainly has valid use cases, but also has downsides.

I'm aware of the discussions. I also gave up trying to get NULL into TOML and I think I'm reference in one of those issues. Personally I do not create TOML configs where absence of key has a meaning, but I'm also exposed to other people's TOMLs where this is an actual issue with all the consequences this causes.

And that ignores the issue of nulls in arrays which are sometimes needed. For instance I have been exposed to parameterized SQL queries in TOML where you need to use the empty object to represent NULL, a particularly absurd incarnation of this.

Re: TOML: Tom's Obvious Minimal Language

#25

Post by arp242 »

the_mitsuhiko wrote: post #18
arp242 wrote: post #14

Earlier quoted context omitted.

> There is a big difference between configuration language formats and programming languages. In general: I agree. But configuration formats (including TOML) also need to map well to programming languages, so you can't seem them as entirely separate. One argument against Null is that it doesn't elegantly map to a data structure in all programming languages.

> One argument against Null is that it doesn't elegantly map to a data structure in all programming languages. TOML has plenty of constructs that don't map well to many languages. Plenty of language implementations do not know how to work with the datetime type, some TOML implementations barf on objects in lists. In some TOML implementations you also end up with nulls showing up when certain empty table constructs ar…

Making it map to every single language is always going to be hard, but most (mainstream) languages come with support for these kind of things in the language itself or standard library. That's not a good reason to add more though. It also pushes the complexity the complexity to the people using TOML in their programs, rather than the people writing TOML parsers: in some languages like Python or JavaScript you can "just" use a string and it's nullable, but in other languages you have to muck about with pointers, special types, options, etc.

Re: TOML: Tom's Obvious Minimal Language

#26

Post by Sujeto »

bruce511 wrote: post #5

I'm puzzling over where I would use this sort of thing, over say Json, or simple xml, and I realise that it's mostly useful in cases where you're expected to edit the configuration in a text editor. That's not something I come across a lot - all my software (that I use) has a visual interface, and so raw editing of text/config files is not something we do. So context really comes into play here. I can see how this wo…

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.

Re: TOML: Tom's Obvious Minimal Language

#27

Post by conaclos »

I 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 JSON5 proposal [2].

EKON [3] is certainly the best candidate. However, it didn't get any traction.

[1] https://github.com/d3x0r/JSON6 [2] https://json5.org/ [3] https://github.com/ekon-org/ekon

Re: TOML: Tom's Obvious Minimal Language

#28

Post by danielvaughn »

bruce511 wrote: post #5

I'm puzzling over where I would use this sort of thing, over say Json, or simple xml, and I realise that it's mostly useful in cases where you're expected to edit the configuration in a text editor. That's not something I come across a lot - all my software (that I use) has a visual interface, and so raw editing of text/config files is not something we do. So context really comes into play here. I can see how this wo…

I just started a new job where we’re writing a lot of Python, and I’m seeing TOML everywhere

Re: TOML: Tom's Obvious Minimal Language

#29

Post by arp242 »

the_mitsuhiko wrote: post #24
arp242 wrote: post #11

Earlier quoted context omitted.

It's been discussed a few times over the years: https://github.com/toml-lang/toml/issues/921 https://github.com/toml-lang/toml/issues/803 https://github.com/toml-lang/toml/issues/802 https://github.com/toml-lang/toml/issues/146 https://github.com/toml-lang/toml/issues/30 Obviously there is a bit of a demand, and it certainly has valid use cases, but also has downsides.

I'm aware of the discussions. I also gave up trying to get NULL into TOML and I think I'm reference in one of those issues. Personally I do not create TOML configs where absence of key has a meaning, but I'm also exposed to other people's TOMLs where this is an actual issue with all the consequences this causes. And that ignores the issue of nulls in arrays which are sometimes needed. For instance I have been exposed…

I'm not saying there aren't reasonable and valid use cases, there obviously are. But there are also downsides, so the question is how it all balances out. Almost every feature that has ever been added to anything has reasonable and valid use cases, but clearly not everything should have all the features.

Re: TOML: Tom's Obvious Minimal Language

#30

Post by 4ad »

conaclos wrote: post #27

I 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…

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

Post reply on HN