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

21–30 of 31 posts

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

#21

Post by stormbrew »

jokull wrote: post #13
account_taken wrote: post #11

Earlier quoted context omitted.

Do tell about the problems with JSON for use as a configuration object? Almost every language has a library that can parse JSON.

It’s hard to author by hand. Ever added a comma after the last element in a list? It’s not very forgiving.

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.

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

#22

Post by aroberge »

laurent123456 wrote: post #10

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…

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"

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

#23

Post by jaredmcateer »

cmwelsh wrote: post #17
account_taken wrote: post #11

Earlier quoted context omitted.

Do tell about the problems with JSON for use as a configuration object? Almost every language has a library that can parse JSON.

I like to put comments in my configuration files. How do you comment out blocks of a JSON configuration file?

Pipe it through JSmin or something else that strips comments.

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

#24

Post by jaredmcateer »

jokull wrote: post #13
account_taken wrote: post #11

Earlier quoted context omitted.

Do tell about the problems with JSON for use as a configuration object? Almost every language has a library that can parse JSON.

It’s hard to author by hand. Ever added a comma after the last element in a list? It’s not very forgiving.

That's JavaScript not just JSON, if you install JSHint or JSLint in your editor you'll spot the error right away.

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

#26

Post by GhotiFish »

stormbrew wrote: post #21
jokull wrote: post #13

Earlier quoted context omitted.

It’s hard to author by hand. Ever added a comma after the last element in a list? It’s not very forgiving.

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.

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.

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

#27

Post by jneen »

brokenparser wrote: post #25

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

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.

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

#28

Post by bhangi »

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 ';'.

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

#29

Post by antihero »

dasil003 wrote: post #9
networked wrote: post #8

Earlier quoted context omitted.

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.

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

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

#30

Post by stormbrew »

GhotiFish wrote: post #26
stormbrew wrote: post #21

Earlier quoted context omitted.

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.

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…

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.

Post reply on HN