

Tom's Obvious, Minimal Language (like INI, only better) - telemachos
https://github.com/mojombo/toml

======
jackalope
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).

------
swatkat
[https://github.com/mojombo/toml/commit/e54978f05197d16fde3ef...](https://github.com/mojombo/toml/commit/e54978f05197d16fde3ef4716fcd348d981b16fe)

<http://news.ycombinator.com/item?id=5272634>

~~~
telemachos
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.

------
fingerprinter
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
How many less characters could there be while still maintaining meaning? Could
you show an example of what you'd prefer?

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

~~~
aroberge
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
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.

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

------
jokull
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.

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

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

~~~
stormbrew
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
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
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.

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

~~~
jayferd
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.

