5 ms·

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

33 points by telemachos 14y ago

jokull 14y ago
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.
- dasil003 14y ago
  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
  - networked 14y ago
    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/ https://yaml-online-parser.appspot.com/
    - dasil003 14y ago
      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.
      - antihero 14y ago
        That is utterly stupid isn't it, how could the designers of YAML count a capital "NO" as a key as False. Wow. Edit, holy fuck all these are booleans: y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF
- account_taken 14y ago
  Do tell about the problems with JSON for use as a configuration object? Almost every language has a library that can parse JSON.
  - jokull 14y ago
    It’s hard to author by hand. Ever added a comma after the last element in a list? It’s not very forgiving.
    - stormbrew 14y ago
      This is actually one of the worst things about it to me, other than the lack of comments. A language that has comma-separated lists and doesn't allow trailing commas on the list as a whole is frustrating to use in a version controlled context because adding an item requires modifying the item before, which leads to more (and less obviously solvable) merge conflicts.
      - GhotiFish 14y ago
        I've seen a style of list initialization that sort of addresses this issue. I like it, but I don't see it used very often. Darn you standards! kittyBreeds = ["Himalayan" ,"Bengal" ,"Siamese" ,"Burmese" ,"Cornish Rex" //rawr ,"LaPerm" ,"Manx" //This is not a real cat! >:( // ,"lolcat" ,"Munchkin" ,"Ocicat" ]; In this way the issue with the commas is relegated to the first element, rather than the last. Since appending is more common, this seems a better style.
        stormbrew 14y ago
        Interesting approach. This strikes me as kind of like the classic "put the constant on the left" advice in C/C++ that, no matter how many people agree it's a good idea, no one ever does because the cognitive effort of understanding it is high enough to diminish the correctness benefit. In other words, you know you're just gonna end up with this in your code after a few months: kittyBreeds = ["Himalayan", ,"Bengal", "Siamese", "Cornish Rex", ,"Manx"] and not only is it now even worse for changing lines (correcting it and adding another will be -1+3 instead of just -1+2, the optimal +1 a distant memory), but it's just plain a mess and probably people don't know why they need to do it.
- luser001 14y ago
  You seem picky. :) But check out libconfig. Maybe it'll work for you.
swatkat 14y ago
https://github.com/mojombo/toml/commit/e54978f05197d16fde3ef4716fcd348d981b16fe https://github.com/mojombo/toml/commit/e54978f05197d16fde3ef... http://news.ycombinator.com/item?id=5272634 http://news.ycombinator.com/item?id=5272634
- telemachos 14y ago
  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.
deleted 14y ago
[deleted]
drhowarddrfine 14y ago
Plain text files can probably do all this.
laurent123456 14y ago
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.
- adamtj 14y ago
  That's not hard to parse. Inline comments are nice. You'll be doing more reading of files that writing of parsers.
- aroberge 14y ago
  WAT?. Python can parse the above very nicely, thank you. >>> value = "example # no that's not a comment" # but here's one >>> value "example # no that's not a comment"
  - laurent123456 14y ago
    At the time I wrote that, the only Python parser was removing the comments by splitting the line on "#", which mean it wouldn't work with the example I mentioned. It seems there are now several other Python parsers, so some of them are probably getting it right.
fingerprinter 14y ago
I don't know if this is the answer, but I'm a fan of someone trying. I personally never jumped on YAML or JSON. I liked that they weren't XML, but they each felt like XML++ too much for me. There was still too much, I don't know, weirdness/typing/oops! Don't get me wrong, I think they were better than XML, but only marginally. It would be nice to see more of a phase change type of approach. I'd LOVE to see something like this (or something else) that involves much less typing/special characters/etc than YAML and JSON. Personal opinion.
- nicksergeant 14y ago
  How many less characters could there be while still maintaining meaning? Could you show an example of what you'd prefer?
  - lutusp 14y ago
    > How many less characters could there be "Less" characters? Do you mean physical smaller characters, like "e" instead of "E"? Or do you perhaps mean fewer characters? http://en.wikipedia.org/wiki/Fewer_vs._less http://en.wikipedia.org/wiki/Fewer_vs._less
- deleted 14y ago
  [deleted]
jackalope 14y ago
Possible improvements occur to me: 1. If indentation is significant and required, dotted notation should be optional: [foo] [bar] [car] The parser should be able to understand that this results in a foo.bar.car structure without explicitly using dotted notation in the keys. 2. Support include files. With #1 implemented, includes would be extremely powerful and flexible. Since indentation is required, no special syntax is needed to relatively position the included files. And without requiring dotted notation in keys, include files can be reused in a configuration (such as common settings in the [servers] section of the example).
brokenparser 14y ago
I see your mixed use of square brackets and raise you a syntax error.
- jayferd 14y ago
  Yeah, that's gonna be a tough one. But I think the "square bracket list" things only ever occur in value position, and the headers only ever occur in root position, so it's not that hard.
bhangi 14y ago
So the objection to JSON comes down to a couple of things: no comments and fragility in face of a trailing comma. I wonder if the right thing though would be to fix JSON (maybe even call it something else) rather than throw the baby out with the bathwater. Personally, of course, I think we should just use a slightly modified version of s-exprs which would be easier to parse. (:keyword value) where value can be an atom, list of atoms or a list of keyword value pairs. Comments could follow the Lisp convention and start with semi-colon and end with newline. Only 5 characters to escape, namely, '(', ')', ':', ' ' and ';'.

33 points by telemachos 14y ago

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.

dasil003 14y ago
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
- networked 14y ago
  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/ https://yaml-online-parser.appspot.com/
  - dasil003 14y ago
    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.
    - antihero 14y ago
      That is utterly stupid isn't it, how could the designers of YAML count a capital "NO" as a key as False. Wow. Edit, holy fuck all these are booleans: y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF
account_taken 14y ago
Do tell about the problems with JSON for use as a configuration object? Almost every language has a library that can parse JSON.
- jokull 14y ago
  It’s hard to author by hand. Ever added a comma after the last element in a list? It’s not very forgiving.
  - stormbrew 14y ago
    This is actually one of the worst things about it to me, other than the lack of comments. A language that has comma-separated lists and doesn't allow trailing commas on the list as a whole is frustrating to use in a version controlled context because adding an item requires modifying the item before, which leads to more (and less obviously solvable) merge conflicts.
    - GhotiFish 14y ago
      I've seen a style of list initialization that sort of addresses this issue. I like it, but I don't see it used very often. Darn you standards! kittyBreeds = ["Himalayan" ,"Bengal" ,"Siamese" ,"Burmese" ,"Cornish Rex" //rawr ,"LaPerm" ,"Manx" //This is not a real cat! >:( // ,"lolcat" ,"Munchkin" ,"Ocicat" ]; In this way the issue with the commas is relegated to the first element, rather than the last. Since appending is more common, this seems a better style.
      - stormbrew 14y ago
        Interesting approach. This strikes me as kind of like the classic "put the constant on the left" advice in C/C++ that, no matter how many people agree it's a good idea, no one ever does because the cognitive effort of understanding it is high enough to diminish the correctness benefit. In other words, you know you're just gonna end up with this in your code after a few months: kittyBreeds = ["Himalayan", ,"Bengal", "Siamese", "Cornish Rex", ,"Manx"] and not only is it now even worse for changing lines (correcting it and adding another will be -1+3 instead of just -1+2, the optimal +1 a distant memory), but it's just plain a mess and probably people don't know why they need to do it.
luser001 14y ago
You seem picky. :) But check out libconfig. Maybe it'll work for you.

swatkat 14y ago

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

telemachos 14y ago
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.

deleted 14y ago

[deleted]

drhowarddrfine 14y ago

Plain text files can probably do all this.

laurent123456 14y ago

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.

adamtj 14y ago
That's not hard to parse. Inline comments are nice. You'll be doing more reading of files that writing of parsers.
aroberge 14y ago
WAT?. Python can parse the above very nicely, thank you. >>> value = "example # no that's not a comment" # but here's one >>> value "example # no that's not a comment"
- laurent123456 14y ago
  At the time I wrote that, the only Python parser was removing the comments by splitting the line on "#", which mean it wouldn't work with the example I mentioned. It seems there are now several other Python parsers, so some of them are probably getting it right.

fingerprinter 14y ago

I don't know if this is the answer, but I'm a fan of someone trying. I personally never jumped on YAML or JSON. I liked that they weren't XML, but they each felt like XML++ too much for me. There was still too much, I don't know, weirdness/typing/oops! Don't get me wrong, I think they were better than XML, but only marginally. It would be nice to see more of a phase change type of approach. I'd LOVE to see something like this (or something else) that involves much less typing/special characters/etc than YAML and JSON. Personal opinion.

nicksergeant 14y ago
How many less characters could there be while still maintaining meaning? Could you show an example of what you'd prefer?
- lutusp 14y ago
  > How many less characters could there be "Less" characters? Do you mean physical smaller characters, like "e" instead of "E"? Or do you perhaps mean fewer characters? http://en.wikipedia.org/wiki/Fewer_vs._less http://en.wikipedia.org/wiki/Fewer_vs._less
deleted 14y ago
[deleted]

jackalope 14y ago

Possible improvements occur to me: 1. If indentation is significant and required, dotted notation should be optional: [foo] [bar] [car] The parser should be able to understand that this results in a foo.bar.car structure without explicitly using dotted notation in the keys. 2. Support include files. With #1 implemented, includes would be extremely powerful and flexible. Since indentation is required, no special syntax is needed to relatively position the included files. And without requiring dotted notation in keys, include files can be reused in a configuration (such as common settings in the [servers] section of the example).

brokenparser 14y ago

I see your mixed use of square brackets and raise you a syntax error.

jayferd 14y ago
Yeah, that's gonna be a tough one. But I think the "square bracket list" things only ever occur in value position, and the headers only ever occur in root position, so it's not that hard.

bhangi 14y ago

So the objection to JSON comes down to a couple of things: no comments and fragility in face of a trailing comma. I wonder if the right thing though would be to fix JSON (maybe even call it something else) rather than throw the baby out with the bathwater. Personally, of course, I think we should just use a slightly modified version of s-exprs which would be easier to parse. (:keyword value) where value can be an atom, list of atoms or a list of keyword value pairs. Comments could follow the Lisp convention and start with semi-colon and end with newline. Only 5 characters to escape, namely, '(', ')', ':', ' ' and ';'.