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

181–190 of 229 posts

Re: TOML: Tom's Obvious Minimal Language

#181

Post by jerpint »

daveevad wrote: post #160
MrJohz wrote: post #154

Earlier quoted context omitted.

YAML has a lot of extra stuff going on that can cause accidents if you don't take care. The classic example is the "Norway problem" where "no" (the country code for Norway) is parsed as "false" instead. If "no" is used as a key, this can cause the Norwegian data to disappear or to throw strange errors on load. The other big issue is that, by default, it allows relatively unrestricted code execution in many environmen…

Someone at work recently got bit by unexpected YAML parsing a git commit hash that contained a substring which was a valid number in scientific notation (IIRC 5e38031).

Ouch

Re: TOML: Tom's Obvious Minimal Language

#182

Post by adgjlsfhk1 »

enriquto wrote: post #155

Graybeard opinion: all of toml, yaml, xml, json, kdl, etc., are ridiculously over-engineered for simple configuration files. You can nearly always fulfill all of your needs with a simple two-column text file of key=value pairs that can be parsed by a trivial call to fscanf(3) or whatever your laguage supports (yes, even correctly discarding comments). The world would be a better place if people just gron'd their json…

How does this deal with needing to represent nested data? (the example coming to me now is TOML as a list of libraries each of which has a number of dependencies). I guess you can always do it by duplication, but for a human oriented format, that sounds pretty painful.

Re: TOML: Tom's Obvious Minimal Language

#183

Post by AceJohnny2 »

MrJohz wrote: post #154
Simran-B wrote: post #144

Earlier quoted context omitted.

I don't understand the appeal of TOML. Why not use YAML instead? Seems a lot more "obvious" to read and write to me. And it's the best I know that is strong in both, human and machine readability.

YAML has a lot of extra stuff going on that can cause accidents if you don't take care. The classic example is the "Norway problem" where "no" (the country code for Norway) is parsed as "false" instead. If "no" is used as a key, this can cause the Norwegian data to disappear or to throw strange errors on load. The other big issue is that, by default, it allows relatively unrestricted code execution in many environmen…

YAML is interesting, because at first glance it looks like a pretty convenient, human-readable syntax, it's got lists, dicts/mappings, strings, numbers, booleans... simple enough for 90% of the use-cases, and focusing on "human-readable, right? But look at little deeper and one uncovers some horrors.

In particular, the plethora of boolean values... here let me just grab the regex from the spec [1]:

    y|Y|yes|Yes|YES|n|N|no|No|NO
    |true|True|TRUE|false|False|FALSE
    |on|On|ON|off|Off|OFF
At that point why limit yourself to just the English language?

Then there's the language-specific types or, as YAML calls them, "local tags". The stuff preceded by `!` like

    !!map {
      ? ! "foo"
      : ! "baz"
    }
At that point, you've exceeded the scope of "human-readable".

I'll admit there are some other, er, "complications" that I actually like. In particular, anchors (`&FOO`) and aliases/references (`*FOO`) [2] make it possible to describe arbitrary graphs, and I find it very useful to factorizing blocks. Also, "folding" [3] text, which allows you to spread value/text across multiple lines for readability, while respecting the surrounding indentation, is neat.

[1] https://yaml.org/type/bool.html

[2] https://yaml.org/spec/1.0/#syntax-anchor

[3] https://yaml.org/spec/1.0/#id2566944

Re: TOML: Tom's Obvious Minimal Language

#184

Post by throwaway894345 »

ohazi wrote: post #63
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 Until you realize you can't actually store real integers because every number in js is a float...

> Until you realize you can't actually store real integers because every number in js is a float

JSON !== JS

Re: TOML: Tom's Obvious Minimal Language

#185

Post by TylerE »

Guthur wrote: post #175
TylerE wrote: post #19

Earlier quoted context omitted.

Null is one way to represent such a value, but it’s hardly the only. Option-style algebraic types are another, and more or less strictly superior if working in a language with first class support for such, because they force you to explicitly handle the null/None/Empty/whatever case if you’re doing something with it that could fail (basically anything besides assignment or passing it along).

Seems beyond the simplicity TOML was aiming for. Absence is absence in the file, in your programming language you can wrap in whatever trickier you like or is relevant.

The trick is distinguishing empty string vs no value vs key not being present.

Re: TOML: Tom's Obvious Minimal Language

#186

Post by Guthur »

TylerE wrote: post #185
Guthur wrote: post #175

Earlier quoted context omitted.

Seems beyond the simplicity TOML was aiming for. Absence is absence in the file, in your programming language you can wrap in whatever trickier you like or is relevant.

The trick is distinguishing empty string vs no value vs key not being present.

Key not being present is no value, key present has value, empty string or otherwise, seems simple enough.

You can add advanced semantics on load, the file does nothing by itself after all.

Re: TOML: Tom's Obvious Minimal Language

#187

Post by danmur »

Simran-B wrote: post #144
friend_and_foe wrote: post #103

I use TOML and JSON for everything. I like them both quite a bit. TOML gets a lot of criticism for not being JSON and JSON gets a lot of criticism for... not being entirely fit for it's stated purpose. However, they're both fantastic if you use them for what they're good at: TOML for human readable configurations that you expect a user to modify, JSON for representing data that a machine will read all of the time but…

I don't understand the appeal of TOML. Why not use YAML instead? Seems a lot more "obvious" to read and write to me. And it's the best I know that is strong in both, human and machine readability.

I assume neither of us has experienced these YAML bites that others have :).

I don't mind TOML but I don't find it either intuitive or obvious. The syntax for how nested things are flattened I just find really hard to read and write. It's fine though, not that big a deal.

Re: TOML: Tom's Obvious Minimal Language

#188

Post by ryan-duve »

pachico wrote: post #37

My main issue with TOML is precisely described in the homepage example: [servers] [servers.alpha] is error prone. An sub heading shouldn't need to know about its parent, much less to have to copy it entirely.

I think it is not needed? Or did you mean something other than this?

    Python 3.11.3 (main, May  4 2023, 05:53:32) [GCC 10.2.1 20210110]
    Type 'copyright', 'credits' or 'license' for more information
    IPython 8.13.2 -- An enhanced Interactive Python. Type '?' for help.
    
    In [1]: !cat /tmp/x.toml
    [servers.alpha]
    x = 10
    
    In [2]: import tomllib
       ...: 
       ...: with open("/tmp/x.toml", "rb") as f:
       ...:     t = tomllib.load(f)
       ...: 
       ...: t
    Out[2]: {'servers': {'alpha': {'x': 10}}}

Re: TOML: Tom's Obvious Minimal Language

#189

Post by elondaits »

chrismorgan wrote: post #48
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…

I strongly dislike the idea of optional {} on the root object. It’s weird special-casing that adds complexity (code and cognitive) for no adequate reason, destroying the neat contextless recursion of parsing. Remember also that objects aren’t the only valid JSON values; and why should objects be privileged over, say, arrays? You could make [] optional too without introducing actual grammatical ambiguity, other than d…

Arrays at the root of JSON are dangerous and best avoided:

https://stackoverflow.com/questions/3503102/what-are-top-lev...

Re: TOML: Tom's Obvious Minimal Language

#190

Post by xedrac »

adgjlsfhk1 wrote: post #182
enriquto wrote: post #155

Graybeard opinion: all of toml, yaml, xml, json, kdl, etc., are ridiculously over-engineered for simple configuration files. You can nearly always fulfill all of your needs with a simple two-column text file of key=value pairs that can be parsed by a trivial call to fscanf(3) or whatever your laguage supports (yes, even correctly discarding comments). The world would be a better place if people just gron'd their json…

How does this deal with needing to represent nested data? (the example coming to me now is TOML as a list of libraries each of which has a number of dependencies). I guess you can always do it by duplication, but for a human oriented format, that sounds pretty painful.

With freeform keys, you can nest all day. But you'll likely just reinvent the wheel when you want certain features.

aaa.bbb.enabled = true

aaa.ccc.enabled = true

Post reply on HN