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

Toml: Tom's Obvious, Minimal Language

github.com

Post reply on HN
Print view View original

101–110 of 204 posts

Re: Toml: Tom's Obvious, Minimal Language

#101

Post by adrianmalacoda »

DonHopkins wrote: post #83
mojombo wrote: post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

So like YAML, TOML ain't markup language either, despite the recursive acronym and the "ML" suffix. If your name was Mark instead of Tom, would you have named it MARKML, and would it still not be markup language?

This does not claim to be a markup language.

According to the repo history, it did... 5 years ago, until someone noticed and corrected it.

Re: Toml: Tom's Obvious, Minimal Language

#102

Post by KingMob »

mojombo wrote: post #79
dustingetz wrote: post #74

Earlier quoted context omitted.

Tom, have you heard of EDN and Transit? Like JSON, but: 1. Extensible, custom types 2. Streamy, efficient, compressed and fast, leverages platform's existing native/optimized JSON parsers 3. Wide platform reach 4. Made by Rich Hickey http://blog.cognitect.com/blog/2014/7/22/transit

I have not, and while it looks cool, it seems to be optimized for data transfer between applications, not a human readable config format.

Transit is more about data transfer, but EDN is mostly meant to be a better JSON (useful date types, doesn't care about commas, has comments, etc)

Re: Toml: Tom's Obvious, Minimal Language

#103

Post by kolpa »

gregn610 wrote: post #92
mojombo wrote: post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

A killer feature of TOML compared to JSON is that it allows comments. A config file without comments and examples ain't great. I found the double square bracket syntax useful and understandable. Agreed it's not obviously .INI or perfectly elegant but it certainly works and has its use-cases. Anyways, thank you @mojombo!

Json allows comments, but they have to be in string fields of an object so they survive reserialization.

Re: Toml: Tom's Obvious, Minimal Language

#104

Post by oblong »

gregn610 wrote: post #92
mojombo wrote: post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

A killer feature of TOML compared to JSON is that it allows comments. A config file without comments and examples ain't great. I found the double square bracket syntax useful and understandable. Agreed it's not obviously .INI or perfectly elegant but it certainly works and has its use-cases. Anyways, thank you @mojombo!

JSON is a serialization protocol not a config file format idiot.

Re: Toml: Tom's Obvious, Minimal Language

#105

Post by latk »

Nadya wrote: post #99

Since Tom is browsing, I have a question - and this is my one and only major issue with TOML. # THIS IS INVALID a.b = 1 a.b.c = 2 Why? I'm sure there is very good reasoning - but it makes me have to reason about my data in a manner I consider backwards/confusing. name.first = "Bob" name.last = "Smith" # Can't do this because name.first has already been defined # name.first.alternative = "Robert" # This is too ambiguo…

Because the "a.b" is not a key, but a table "a" that contains an entry with key "b". If you write "a.b = 1" then that integer is not a table, and can't have an entry called "c".

Because it avoids these problems, your "name.alternative.first" example seems perfectly sensible to me. Alternatively, the name might be an array:

    [[name]]
    first = "Bob"
    last = "Smith

    [[name]]
    first = "Robert"
It's probably best to think of TOML as convenient syntax for creating a JSON-like structure. What kind of JSON would you expect as the result of your config examples?

Re: Toml: Tom's Obvious, Minimal Language

#106

Post by xinau »

Nadya wrote: post #99

Since Tom is browsing, I have a question - and this is my one and only major issue with TOML. # THIS IS INVALID a.b = 1 a.b.c = 2 Why? I'm sure there is very good reasoning - but it makes me have to reason about my data in a manner I consider backwards/confusing. name.first = "Bob" name.last = "Smith" # Can't do this because name.first has already been defined # name.first.alternative = "Robert" # This is too ambiguo…

I don't know if this is the intend of Tom, but I was also stumbling on this issue and the only reasonable explanation I can come up with is that:

One key can't have multiple values with different types. For example in json:

  { "name" : 
    { "first" : "Bob",
      "last" : "Smith"
    }
  }
How would you add a "alternative" key to the "first" value type. The only way i can think of is something like this.

  { "name" : 
    { "first" : "Bob",
      "first.alternative": "Robert",
      "last" : "Smith"
    }
  }
or as @latk suggested, let "first" be an array, with it's first entry being the non alternatives.

  { "name" : 
    { "first" : ["Bob", "Robert"],
      "last" : "Smith"
    }
  }
I think this is by design. To quote @mojombo "simple configuration file that maps unambiguously to a hash table".

But this is only a guess.

Re: Toml: Tom's Obvious, Minimal Language

#107

Post by svacko »

dustingetz wrote: post #74
mojombo wrote: post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

Tom, have you heard of EDN and Transit? Like JSON, but: 1. Extensible, custom types 2. Streamy, efficient, compressed and fast, leverages platform's existing native/optimized JSON parsers 3. Wide platform reach 4. Made by Rich Hickey http://blog.cognitect.com/blog/2014/7/22/transit

There is also a similar project - Hjson, a user interface for JSON- https://hjson.org/

Re: Toml: Tom's Obvious, Minimal Language

#108

Post by Groxx »

mojombo wrote: post #55
hyperpape wrote: post #54

Earlier quoted context omitted.

I'm a pretty big fan of TOML, though I've mostly only used it for Cargo. What are the limitations for large complex configs, and do you think there's currently a better configuration format for them? Feel free to link elsewhere if there's a canonical location for this discussion.

The limitations are mainly around nested arrays of tables. As has been mentioned here already, the [[array-of-tables]] syntax that currently allows this can be super confusing, and is definitely the worst part of TOML right now. Even so, you can often work around this weakness by reworking your config file to pick up on a specific naming scheme (perhaps every "server-*" table is interpreted as a member of an array) o…

is this e.g. due to the verbosity of re-declaring field names every time? or something else?

e.g. CSVs handle 2D tables reasonably efficiently, since you just specify values:

    field_a, field_b, field_c
    1, 2, 3
    3, 4, 5
but I imagine TOML would benefit from something that lets you define nested tables without re-defining the table every time... which probably conflicts with the "obvious" goal. Hmm.

Re: Toml: Tom's Obvious, Minimal Language

#109

Post by mlthoughts2018 »

gregn610 wrote: post #92
mojombo wrote: post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

A killer feature of TOML compared to JSON is that it allows comments. A config file without comments and examples ain't great. I found the double square bracket syntax useful and understandable. Agreed it's not obviously .INI or perfectly elegant but it certainly works and has its use-cases. Anyways, thank you @mojombo!

I used to feel this way, and also used to be frustrated about multi-line strings in JSON. With years of experience now, though, I actually appreciate JSON omitting these features.

Config files should absolutely not have or need comments. If you need them directly in the config file, something is wrong. Applications should document their default settings in a different way, preferably in a README or generated documentation that also explains how to use environment variables to override the defaults. That sort of separate companion doc is the right place for notes about defaults or "why" certain config values exist in the file. The same is true for using JSON to store parameter files, etc. It's actually quite important to keep metadata about the config / params / etc. specifically out of those files, so that they are absolutely nothing but value files. Information about why a file contains those values belongs elsewhere, and it's an anti-pattern IMO to rely on comments in the config / param file.

Re: Toml: Tom's Obvious, Minimal Language

#110

Post by Waterluvian »

mlthoughts2018 wrote: post #109
gregn610 wrote: post #92

Earlier quoted context omitted.

A killer feature of TOML compared to JSON is that it allows comments. A config file without comments and examples ain't great. I found the double square bracket syntax useful and understandable. Agreed it's not obviously .INI or perfectly elegant but it certainly works and has its use-cases. Anyways, thank you @mojombo!

I used to feel this way, and also used to be frustrated about multi-line strings in JSON. With years of experience now, though, I actually appreciate JSON omitting these features. Config files should absolutely not have or need comments. If you need them directly in the config file, something is wrong. Applications should document their default settings in a different way, preferably in a README or generated document…

I have never disagreed with someone more than I do now. =)

Config absolutely needs comments. Context is everything. Comments allow me to explain to other humans why the config is the way it is. Dumping that out to a separate file is begging for it to fall out of sync when there's no comment instructing anyone to go and update the other file. Plus that's just kind of silly.

Post reply on HN