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

Tom's Obvious, Minimal Language (like INI, only better)

github.com

Post reply on HN
Print view View original

1–10 of 31 posts

Re: Tom's Obvious, Minimal Language (like INI, only better)

#4

Post by telemachos »

swatkat wrote: post #3

https://github.com/mojombo/toml/commit/e54978f05197d16fde3ef... http://news.ycombinator.com/item?id=5272634

Whoops. I tend to rely on the site itself to block (recent) dupes. I guess the different title threw it, though I would have expected the identical URL to get caught.

Re: Tom's Obvious, Minimal Language (like INI, only better)

#5

Post by dasil003 »

jokull wrote: post #2

INI, JSON and YAML all have problems. None of them are serious enough for me to consider this for a small project with one or two config files required. Good to be able to point to a config file syntax done right though.

But the combination of Tom's reputation and the nightmare security situation currently unfolding with YAML means this project has a very high likelihood of becoming defacto standard in the Ruby community. The thought of being able to get rid of YAML from my code base entirely is an appealing end unto itself. Security aside, YAML is just ridiculously complex and error-prone.

Can you tell at a glance what is wrong with this YAML snippet:

  scandinavia:
    SE: Sweden
    NO: Norway
    FI: Finland

Re: Tom's Obvious, Minimal Language (like INI, only better)

#8

Post by networked »

dasil003 wrote: post #5
jokull wrote: post #2

INI, JSON and YAML all have problems. None of them are serious enough for me to consider this for a small project with one or two config files required. Good to be able to point to a config file syntax done right though.

But the combination of Tom's reputation and the nightmare security situation currently unfolding with YAML means this project has a very high likelihood of becoming defacto standard in the Ruby community. The thought of being able to get rid of YAML from my code base entirely is an appealing end unto itself. Security aside, YAML is just ridiculously complex and error-prone. Can you tell at a glance what is wrong with…

I'm not familiar enough with YAML to see the problem at a glance but parsing the snippet with an online parser [1] suggests that unless you put quotation marks around "NO" it gets parsed into a boolean False. Looks precarious, especially since not requiring strings to be quoted is kind of a selling point of YAML.

[1] https://yaml-online-parser.appspot.com/

Re: Tom's Obvious, Minimal Language (like INI, only better)

#9

Post by dasil003 »

networked wrote: post #8
dasil003 wrote: post #5

Earlier quoted context omitted.

But the combination of Tom's reputation and the nightmare security situation currently unfolding with YAML means this project has a very high likelihood of becoming defacto standard in the Ruby community. The thought of being able to get rid of YAML from my code base entirely is an appealing end unto itself. Security aside, YAML is just ridiculously complex and error-prone. Can you tell at a glance what is wrong with…

I'm not familiar enough with YAML to see the problem at a glance but parsing the snippet with an online parser [1] suggests that unless you put quotation marks around "NO" it gets parsed into a boolean False. Looks precarious, especially since not requiring strings to be quoted is kind of a selling point of YAML. [1] https://yaml-online-parser.appspot.com/

That's it, but you cheated :)

I had to spend half an hour debugging a bizarre side effect of that parsing to pinpoint the problem.

Re: Tom's Obvious, Minimal Language (like INI, only better)

#10

Post by laurent123456 »

The format could be very simple, but... allowing comments after values make it unnecessarily complex to parse. For example:

     value = "example # no that's not a comment" # but here's one
If inline comments where not allowed we could just check the first and last character for a quote and we know we have a string, same for arrays (check for [ and ]). But with inline comments, we need to parse the whole string.

As far as I can see both the C# and Python parsers don't handle this kind of comment correctly at the moment, and probably many implementations will have troubles with that. They should just drop this option in my opinion.

Post reply on HN