17 ms·

Toml: Tom's Obvious, Minimal Language

358 points by wheresvic1 8y ago

somedudeatwork 8y ago
I never really questioned the name, TOML, but I guess "Tom's Obvious, Minimal Language" works
- gnuvince 8y ago
  To me, there was nothing obvious about the double bracket syntax, e.g.: [[designers]] name = Guido lang = Python [[designers]] name = Larry lang = Perl
  - cies 8y ago
    Yups. And making a whole datetime RFC part of the spec kind of broke with the "minimal" thing. But apart from that I totally prefer it over INF/YML/JSON/XML for many purposes.
    - wvh 8y ago
      I guess there's no way around that though, if you want dates to be first class members. Can't do "a bit of date".
      - mojombo 8y ago
        We added a proper datetime type because the only thing worse than having one is not having one. If you had to supply a datetime as a string, every TOML file would have a different way of doing it, which is...not so obvious.
    - adamch 8y ago
      Excluding the datetime RFC in the name of minimalism would make the language much worse (coughjson). I feel like this is as simple as it could be, but no more.
    - laumars 8y ago
      Datetime does need to be part of the spec if you want your markup files portable otherwise every TOML parser might decode a date slightly differently. In that regard it is really no different to saying "01" (string) is different to 1 (integer) in terms of preserving your data's integrity.
  - laumars 8y ago
    I agree about the double bracket syntax however I don't think that is part of the specification any more, instead nested structures use a dot notation inside single brackets. Both solutions do still feel like a hack though, but the dot notation is definitely less ugly. That all said, for flatter schema's I do personally think TOML is more readable than it's JSON, YAML and XML counterparts. If there is one thing I did like about Windows back when I used to run it, it was the syntax of INI files (which TOML was heavily influenced by). Ultimately though, there is no perfect solution for all problems.
    - freyir 8y ago
      > for flatter schema's I do personally think TOML is more readable than it's JSON, YAML and XML Yes. But for nested data, I find TOML becomes the least readable and I have to fall back to YAML or JSON. Maybe we need just one more ML...
      - deckar01 8y ago
        I disagree. The way JSON and YAML nest data with indentation forces data to be disconnected from it's property chain when there are multiple large items at each level. TOML seems to provide a solution to that by allowing deeply nested paths to be declare explicitly at the top level for each item. You get to choose how to split the paths into containers instead of being locked into a 1-to-1 tree structure.
      - notheguyouthink 8y ago
        Oh man, I can't disagree more. I loathe YAML for readability. When I'm 2 pages down on a yaml tree I have no clue how many indents exist before what I'm working on. Likewise, when I scroll up, I quickly lose track of what the actual parent to the data I was working on is. I've found it to be an absolute mess. JSON doesn't even fit for me, because it's not human intended (imo). Being able to document (comments) configuration is a requirement for me on any config language.
    - unethical_ban 8y ago
      https://github.com/toml-lang/toml#array-of-tables https://github.com/toml-lang/toml#array-of-tables Still there FWIW.
  - krapp 8y ago
    Yeah, that's weird. For the most part the language seems like a smarter slightly more flexible INI which I like (although there's no real standard for INI, most formats don't allow for nested arrays or tables,) but why embrace bracket notation for arrays, but not a keyed syntax with the same brackets for tables? Something like this would have been be a lot cleaner to me: [designers] [name = Guido, lang = Python] [name = Larry, lang = Perl]
  - agumonkey 8y ago
    indicates an 'open' array ?
    - gnuvince 8y ago
      An array of dictionaries. In JSON, my example becomes: { "designers": [ {"name": "Guido", "lang": "Python"}, {"name": "Larry", "lang": "Perl"} ] }
      - mlthoughts2018 8y ago
        This JSON is vastly more readable, frankly. It’s so clear what container type “designers” refers to, and I can read directly what data structures the elements are. I can’t do that in Toml. Unless I just happen to remember some rote memorized convention for what the syntax unpacks into, there’s no way to tell by looking at Toml code. IMO this ought to be priority number one for any utility language like this. No matter what brevity of other syntax there might be, this lack of direct expression of the data structures is too much of a problem. This JSON is also much more readable than the “dot attribute” Toml syntax too, which I think is one of the least intuitive and hardest to read ways of creating nested data structures, certainly vastly less readable than the equivalents in YAML or JSON. I’ve never understood why anyone would say Toml is easier to read than YAML or JSON. It’s drastically harder to read and more confusing.
        agumonkey 8y ago
        Nesting has locality value, which is often desireable.. but as I said, the [[toml]] syntax yields open arrays, it seems you can define thing in multiple passes (which can be harmful but may also be a need once in a while)
        mlthoughts2018 8y ago
        Sure, I only mean that the syntax for it in Toml is extremely hard to read. I personally just find JSON and YAML much, much easier to read.
  - mojombo 8y ago
    Yeah, it's not my favorite part either. We've made them mostly unnecessary by adding inline tables, but for heavy nesting of arrays of tables, you still need to use them, which is why I mentioned that there are still some weaknesses for large, complex config files. Hoping to make this better in 2.0.
    - ben509 8y ago
      In defense of double brackets, I first encountered TOML in pipenv[1], and just by experimenting found I could add another source. So they're reasonably obvious if you see them in an existing file. [1]: https://github.com/pypa/pipfile#pipfile https://github.com/pypa/pipfile#pipfile
      - mojombo 8y ago
        Yeah, they're ok for very simple use cases, it's when you start having more than one level of nesting that things get a little crazy.
- fastball 8y ago
  I'm more a fan of YAML. "YAML Ain't Markup Language"
  - clhodapp 8y ago
    TOML and YAML both have kinda weird names because both were initially incorrectly said to be a "markup language" and then subsequently renamed. The original names were "Yet Another Markup Language" and "Tom's Own Markup Language".
laurent123456 8y ago
(2013)
- aloisdg 8y ago
  v0.5.0 is a new release! Changelog: https://github.com/toml-lang/toml/blob/master/CHANGELOG.md#050--2018-07-11 https://github.com/toml-lang/toml/blob/master/CHANGELOG.md#0...
  - mojombo 8y ago
    Yes, we just released it two days ago! I know v1.0.0 has been a long time coming, but it's important to me that we get it right, as specs have a very long-lasting impact (much more so than a specific version of a library). We are indeed working hard towards a proper 1.0 though!
    - aloisdg 8y ago
      Congrats for the release! I opened an issue in LXIY minutes. I will looking into this new version and update the tutorial :) https://github.com/adambard/learnxinyminutes-docs/issues/3158 https://github.com/adambard/learnxinyminutes-docs/issues/315...
    - simcop2387 8y ago
      Something to consider for 1.0.0, a hexadecimal floating point type value. I don't think it's in there yet, but if it isn't https://www.effectiveperlprogramming.com/2015/06/perl-v5-22-adds-hexadecimal-floating-point-literals/ https://www.effectiveperlprogramming.com/2015/06/perl-v5-22-... They're incredibly useful if you need to specify an exact floating point value, and about rounding or precision issues. Other languages than perl support them, but that article does a good job of demoing them
communist_0 8y ago
It's worth remembering that Tom abused his role as a founder of GitHub and resigned. http://www.businessinsider.com/github-harassment-story-2014-4 http://www.businessinsider.com/github-harassment-story-2014-... https://blog.github.com/2014-04-21-results-of-the-github-investigation/ https://blog.github.com/2014-04-21-results-of-the-github-inv...
mojombo 8y ago
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 large, complex config, but I'm hoping to address that in a later version of the spec (perhaps 2.0). Happy to answer any questions you all have about TOML!
- nixpulvis 8y ago
  Hi Tom, huge fan of this project. 1. Would a file path type make any sense to add? TOML is ideal for configurations, and so many configuration options use file paths. I know there are questions about platform dependency, and I don't have all the right answers for how that would work, but I could see it being possible somehow? 2. Data versioning is a big deal to me. For now there's always an option of just adding a "version" key and updating it, but can you think of a better way to do that with TOML? I'm always overly critical of JSON (despite overall being a fan) because it doesn't specify bit sizes of numbers. I notice that TOML has specified 64 bit numbers. It's nice to see that.
  - mojombo 8y ago
    1. How would the file path type differ from a regular string? Would you want specific semantic validation for each platform? 2. This is still a big question, and we've been having a robust argument about it on GitHub [1]. It's a problem that so far has evaded an elegant solution, but usually when that's the case, it just means we haven't been creative enough about it yet! Or did you mean versioning of the data IN the config file? Can you elaborate? [1] https://github.com/toml-lang/toml/issues/522 https://github.com/toml-lang/toml/issues/522
    - nixpulvis 8y ago
      1. Yea the goal would be some kind of validation at parsing time. I'm not super familiar with TOML parsing, but there must be error cases in the implementations, so it seems like using `\` on UNIX systems, for example could return an error. The only hard part about this I see is distinguishing paths from strings syntactically without making TOML overly complex. 2. So basically, the majority of people don't want to type version numbers (I see where they are coming from, but respectfully disagree). I'm not sure if there exists a solution in that case. As for my comment, I was really talking about both kinds of versioning. Mainly that, if my data is version 2.3.1, I'd expect that to also lock the version of TOML, requiring a new version of my data for bumps to the underlying data structure. Again syntax is the hard part, as I'm having trouble imagining a way to actually do this. Furthermore I've seen data formats in the past that let you version "parts" of a format, I personally like this, but don't think it's a good fit for TOML.
wiradikusuma 8y ago
For more complex config, I highly recommend HOCON (https://github.com/lightbend/config/blob/master/HOCON.md https://github.com/lightbend/config/blob/master/HOCON.md), and its parser in Java (https://github.com/lightbend/config https://github.com/lightbend/config). It feels like Scala (Lightbend is the company behind Scala) in the sense that there are 100 ways to achieve the same thing and having different levels of "code elegance", but for me it's a plus, since I'm a Scala fan.
afraca 8y ago
Does anyone know why such a "joke proposal" (as stated by the author itself) was chosen for pretty significant projects like pip and cargo? (edit: I tried to say it began as something small and personal) (Well, I guess there's not that much to win/lose in the area of config languages, but still) (Also, I think it works pretty well, so this is not to downplay TOML!)
- mojombo 8y ago
  Well, it was only a joke to begin with. I couldn't stand the complexity or ambiguity of YAML and one night I had a few drinks and banged out my thoughts on something better. When people started writing implementations, I realized that TOML might actually have legs and started tightening it up and removing the snarky bits. I guess these projects felt the same pain I did about config files and presto! I think the moral of the story is: just put your whacky ideas out there and see what happens. You never know when you'll hit a chord.
  - afraca 8y ago
    Thanks for response. I edited my response to be less snarky. Good job and thanks for the moral of the story.
- niftich 8y ago
  There's no one clear place to point to about how the decision was made for Cargo, but some nuggets have been left by authors [1]. The gist seems to be that JSON (and YAML, per that comment) was considered a poor format to author and maintain a config file in, and YAML had no lib in Rust and there was no appetite for anyone to write one. Pip's choice was made for them in the form of PEP 518 [2]. The authors of PEP 518 explain their rationale [2][3], which largely boils down to XML being too wordy and awkward to hand-edit, JSON awkward to hand-edit, various formats used by existing python tooling were underspecified and implementation-dependent, and YAML's python parsers being fairly complex and hard to vendor. [1] https://news.ycombinator.com/item?id=7938388 https://news.ycombinator.com/item?id=7938388 [2] https://www.python.org/dev/peps/pep-0518/ https://www.python.org/dev/peps/pep-0518/ [3] https://www.python.org/dev/peps/pep-0518/#other-file-formats https://www.python.org/dev/peps/pep-0518/#other-file-formats
skrebbel 8y ago
If only package.json had been package.toml
- jxub 8y ago
  Would that be hard to implement for npm/yarn? I'm sure that transforming TOML to JSON on the fly could be added as a step somewhere, resulting in changes to the package manager or just a wrapper command. Stylistically, I agree with you as TOML is clean and well thought. Moreover, TOML has support for more data types that JSON lacks leading to ugly workarounds (floats as strings anyone?). The main advantage of JSON is that its encoding/decoding is included in JS as it is, and it's generally deeply ingrained in the Node community.
  - skrebbel 8y ago
    It would not be trivial because npm/yarn don't just read package.json but also modify it. See numerous GitHub issues in either repo about supporting comments inside package.json. Of course nothing is impossible, but I think that the ship has sailed. I was just dreaming of what could have been :-) Subtle details in NPM's behavior would've probably been designed differently if it was necessary to make updates to the package file without destroying layout and context.
niftich 8y ago
The news here is (presumably) the announcement of version 0.5.0 a few days prior [1], which includes several clarifications, rollup changes, and enhancements that accumulated over the last 3 years. In my opinion, one of the more useful features was the addition of Joda-style datetimes [2][3][4][5], which disambiguates between various kinds of datetime constructs aren't interchangeable yet commonly conflated. It's fair criticism that the addition of rich datetime types exceeds the language's original 'minimal' goal, but too many other languages and formats these days just punt to RFC3339 and leave no guidance or tooling on how to represent dateless times or timeless dates without introducing a ton of side-effects. This is a place where language standard libs, with few exceptions, have repeatedly dropped the ball, and similarly, language or library-agnostic, generic guidance is nowhere to be found. TOML raises the bar here, by providing a concept and notation to specify these values at rest, and gives parser writers, as opposed to the users, the task of finding a way to represent these values in whatever way is idiomatic for the given language. [1] https://github.com/toml-lang/toml/blob/master/CHANGELOG.md https://github.com/toml-lang/toml/blob/master/CHANGELOG.md [2] https://github.com/toml-lang/toml/pull/414 https://github.com/toml-lang/toml/pull/414 [3] https://github.com/toml-lang/toml/pull/362 https://github.com/toml-lang/toml/pull/362 [4] https://github.com/toml-lang/toml/issues/412 https://github.com/toml-lang/toml/issues/412 [5] https://github.com/toml-lang/toml/issues/263 https://github.com/toml-lang/toml/issues/263
- mojombo 8y ago
  Glad you like them, we spent quite a bit of time getting them right! Datetimes are a horrible mess of complexity, but hopefully over time languages and tools around them can standardize on a set of common primitives to make all our lives a bit less horribly messy. =)
dvfjsdhgfv 8y ago
Used to be called "INI file" in the past... In any case I'm glad to see it in several open source projects (Mailtrain for example). It's so much easier to read for humans than JSON.
- runjake 8y ago
  As mentioned in the source link, the INI format is not standardized. This is an attempt at a standardized format similar to INI.
- mojombo 8y ago
  Yeah, TOML is definitely INI inspired, but there is no canonical INI spec. I wouldn't say that TOML is INI, though. INI files still exist in their variously poorly specified ways.
communist_1 8y ago
It's worth remembering that Tom abused his role as a founder of GitHub and resigned. http://www.businessinsider.com/github-harassment-story-2014-4 http://www.businessinsider.com/github-harassment-story-2014-... https://blog.github.com/2014-04-21-results-of-the-github-investigation/ https://blog.github.com/2014-04-21-results-of-the-github-inv...
epage 8y ago
Originally, I was fully on board with the homogeneous array requirement but its recently started causing me pains. Homogeneous arrays can come in the following forms - Shallow, literal type (a list of lists, regardless of the nested lists contain) - Full, literal type (a list of dicts of strings) - Logical type There are many times where a list is the best type for my data but I want to take advantage of logical types for easier configuration by my users. Below is an example of what I mean by "homogeneous logical types": `Cargo.toml` has you specify dependencies using a dict [dependencies] foo = { "version" = "1.0" } but allows a short-cut syntax where a string value is assumed to be the version value in the above dict. [dependencies] foo = "1.0" Generally this is done in Rust using Enums enum Dependency { Version(String), Specification(HashMap<String, String>), }
- mojombo 8y ago
  Homogenous arrays are partly to make implementations easier, and because if you really need that flexibility, you can always use an array of inline tables, which has the benefit of giving each sub-element a name, hopefully increasing the obviousness. I'm not sure I understand your complaint, though, can you give me another example of how it's biting you in real life?
  - epage 8y ago
    > you can always use an array of inline tables, which has the benefit of giving each sub-element a name, hopefully increasing the obviousness Except the name would be duplicated with the content I'm storing. As for an example, its effectively Cargo. My use case is very similar (dependency reporting) but my content is slightly different (as I said, the value would effectively duplicate the key)
    - mojombo 8y ago
      Oh, you mean you want something like: list = [ "1.0", "2.7", { version = "1.4", path = "..." }, "9.9", ] Is that correct?
trendandbeyond 8y ago
test
otterpro 8y ago
I didn't know about TOML until I started using Hugo. I've been using YAML and TOML and I find both have their merits, especially for their simplicity. TOML looks like the classic INI file, and is fairly easy to use/learn. I've been trying to move toward TOML for everything. YAML is nice, but I had to be careful about white-space significance and also translation of "YES","NO", etc. https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html https://arp242.net/weblog/yaml_probably_not_so_great_after_a...
- mojombo 8y ago
  Absolutely. That's what I mean about TOML mapping unambiguously to a hash table. Strings in TOML are always quoted. There is no fuzzy interpretation of things like YES and NO. That way madness lies. I also am not a fan of meaningful whitespace, which is why TOML doesn't do that. Glad you're finding TOML useful, good luck on your projects!
  - k__ 8y ago
    I have to admit, the string and array syntax are the only parts that keep me from using it instead of YAML. Probably because they are the only two features that need delimiters at start and end. The rest are only one-liners or simply stop if the next of the same type starts.
  - Pxtl 8y ago
    > There is no fuzzy interpretation of things like YES and NO I think the big problem is that YAML is dynamically typed. If I had schema-enforced config files, I'd be perfectly happy to say that for boolean typed data all the values of YES and NO and ON and OFF and T and F and 0 and 1 can all be reasonably interpreted as a Boolean True and False. The problem happens when a string-typed or integer-typed member can also have their ON value interpreted into Boolean TRUE.
    - mojombo 8y ago
      Yeah, I'll agree with that, among many other issues with YAML. =) A schema would at least solve that problem, but I don't think most simple config users want to define a schema, so strong typing is a better solution.
EamonnMR 8y ago
It's surprisingly easy to add it as an optional drop-in, ex: https://github.com/EamonnMR/OpenLockstep/blob/master/data.py#L31 https://github.com/EamonnMR/OpenLockstep/blob/master/data.py...
tpaschalis 8y ago
Just dropping a useless comment to say thanks! Between Tom's work on Github, Jekyll, and TOML, I think he has influenced a vast amount of developers! For the projects I've used TOML on, it was a nice breath of fresh air and a terrific improvement over JSON (still mad about JSON's lack of comments). Simplicity wins!
- mojombo 8y ago
  It's never useless to say thanks! I really appreciate your kind words, it's the fuel that powers a lot of open source. Keep it up!
- erikpukinskis 8y ago
  Not to mention inventing MySpace!
thanatropism 8y ago
Funny enough, I learned how to/started to use TOML today. I was running some [redacted] experiments using a .pyc compiled script and wanted to experiment with parameters -- but then I had to compile the script again and again. Enter TOML: I can paste a bunch of "var_x = 2"-type statements (there's like 50) directly from Python, read them as a dictionary and find-replace all appearances in like 5 minutes while I'm waiting for an Uber. Thanks Tom!
- mojombo 8y ago
  Awesome, sounds like the perfect use case for TOML!
timvisee 8y ago
Cool. TOML is used quite extensively in Rust projects. I think it's awesome for very simple configurations. And newcomers don't have to learn anything in order to change a TOML configuration, which is very powerfull.
- mojombo 8y ago
  Yeah, Cargo and Rust have been really important in TOML gaining adoption. Love the Rust community!
- kvark 8y ago
  TOML is a great format, but it can not universally replace JSON, because it's designed for small nested depth. I've been trying to push RON as an alternative, and it works very well for WebRender, Amethyst, and other projects in Rust.
miguelrochefort 8y ago
Looks a lot like Rebol/Red.
losvedir 8y ago
I just started a rust project and so had to learn TOML since that's what the package manager (and a lot of the ecosystem) uses. For some reason, though, I just struggle with the syntax. It says it's "obvious" but it wasn't to me. I think it says something that the README is full of "this TOML would be represented like this JSON", to help you understand what's going on. Every time I saw that, I was like "oh, now I get it." I don't know if that means JSON is just inherently more understandable, or I'm just more used to it, though. Are there obvious downsides to JSON for config that I'm missing? What are the advantages of TOML over JSON? Maybe eventually it'll "click", though. I think the following mean the same thing: [[foo]] bar = {baz = 5} [[foo.bar]] baz = 5 But I don't think the following works: [[foo]] [[bar]] baz = 5 That is, I think the double bracket syntax always starts at the top level? While the `=` are relative to the double brackets above it? Something about all that is non-obvious to me, and I don't love that there's multiple ways to do the same thing.
- Pxtl 8y ago
  Yeah, most of TOML looks good, but the .INI style [table] and even wierder the [[table-array]] thing seems like they were trying to hammer a square peg into a round hole for the sake of having config files that look like INIs.
  - scrollaway 8y ago
    Backwards-compatibility with ini is in my opinion one of the more powerful aspects of TOML which help adoption. Kinda like how UTF8 is ASCII-backcompatible.
    - deleted 8y ago
      [deleted]
- woodrowbarlow 8y ago
  > Are there obvious downsides to JSON for config that I'm missing? for me, there are two. firstly, TOML supports comments. secondly, TOML or INI is very readable without indentation. i have learned that removing indentation from configuration files makes non-technical people much more comfortable editing the file by hand. when many non-technical people see braces and indentation, they feel overwhelmed and associate it with complexity. i don't really use TOML's more advanced features, though. i basically just use it like INI.
TooBrokeToBeg 8y ago
> Whitespace means tab (0x09) or space (0x20). > Newline means LF (0x0A) or CRLF (0x0D0A). Complicating things from the start. Not a good sign.
- boramalper 8y ago
  Well some (many, actually) people use Windows too, and some prefer tabs and some prefer spaces; I can’t see why this is a problem? A language for configs is different from a data interchange language: the former is intended to be written and edited by humans. See https://arp242.net/weblog/json_as_configuration_files-_please_dont https://arp242.net/weblog/json_as_configuration_files-_pleas...
- sametmax 8y ago
  Indentation is not significant. And you can't expect windows users to always check their editor is lf compliant. Toml is not just for programmers
Nadya 8y ago
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 ambiguous name.alternative = "Robert" # And this is backwards to me name.alternative.first = "Robert" Some people might suggest to instead do first.name = "Bob" last.name = "Smith" alternative.first.name = "Robert" But now nothing is scoped to [name] and if I need to get the full name I can't just pull in [name] but need to pull in [first], [last], and [alternative]. That's really messy in my opinion. All of these are names and should be scoped to [name] and not their own structure.
- latk 8y ago
  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?
  - Nadya 8y ago
    >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". Your explanation is perfect and I understand the justification why it isn't possible now - so thanks for that! The array alternative provided by xinau is also an acceptable replacement - maybe even better to be honest, especially in this particular scenario. >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? I came back from lunch and realized what I was trying to do didn't make sense while trying to convert it to JSON. Having name.first be both a value and contain an object doesn't make sense - unless it were to contain an array value but then why have the object and not just have the value? All very silly. So I guess my "only issue with TOML" is that I never sat down and tried to express what I wanted to express in any other way. It made a lot more sense in my head than on paper. :)
anonu 8y ago
How does toml compare to Google protobufs as a configuration system?
- mojombo 8y ago
  Protocol Buffers is a data serialization format and unsuitable for configuration, as the binary serialized data is not human readable.
exabrial 8y ago
Does TOML have a schema?
- mojombo 8y ago
  Not currently, but it's something I'd like to add as a separate spec sometime later.
  - firepoet 8y ago
    In case you're curious, one of the Clojure libraries I found while researching TOML seems to have an ABNF grammar. It sits at the top of this file: https://github.com/lantiga/clj-toml/blob/0.4.0-instaparse/src/clj_toml/core.clj https://github.com/lantiga/clj-toml/blob/0.4.0-instaparse/sr... What a lovely language! I may have to use it..
kaushalmodi 8y ago
Here's the TOML parser in Nim language: https://github.com/NimParsers/parsetoml https://github.com/NimParsers/parsetoml. It works great based on my small amount of testing, and TOML is awesome! I wish more people start using it.
andris9 8y ago
I am using TOML in most of my projects and once the configuration files grew too large I just extended the syntax with “#@include filepath” declarations and split up the config files. Works great. https://github.com/nodemailer/wild-config/blob/master/README.md#toml-extensions https://github.com/nodemailer/wild-config/blob/master/README...
noisy_boy 8y ago
Some questions I couldn't find answers for: - Is interpolation supported? e.g. "key1" = "value" and then "key2" = "$key1". That would be very useful in avoiding repetition. - What is the keyword for null? e.g. when I want to set the value to null
- TheDong 8y ago
  > interpolation? No, there is no facility for variable templating, interpolation, references, or anything of the like in toml. If you wanted that, you could implement it in your application by doing post-processing on strings, or you could not use TOML. > What is the keyword for null? If you have "x = 1", you can always comment it out with "# x = 1". There's no specific support for null. it would be kinda silly to have it anyways since null is a language construct more than anything else, and e.g. some lanuages support mixed strings + nulls in one array, but many don't.
amai 8y ago
The syntax for tables is awkward compared to CSV (This is actually also true for XML, JSON, YAML).
amelius 8y ago
I'm not a fan of configuration files. Instead, I prefer the style of "calling" the program from within a script, and passing the configuration as parameters. This also allows to pass e.g. callback functions. Imho, this is much more flexible, and the advantages grow over time, whereas configuration files tend to accumulate awkward/convoluted constructs as the software matures.
mchahn 8y ago
Should it be called a "language" when it has grammar but no semantics? (just curious)

358 points by wheresvic1 8y ago

somedudeatwork 8y ago

I never really questioned the name, TOML, but I guess "Tom's Obvious, Minimal Language" works

gnuvince 8y ago
To me, there was nothing obvious about the double bracket syntax, e.g.: [[designers]] name = Guido lang = Python [[designers]] name = Larry lang = Perl
- cies 8y ago
  Yups. And making a whole datetime RFC part of the spec kind of broke with the "minimal" thing. But apart from that I totally prefer it over INF/YML/JSON/XML for many purposes.
  - wvh 8y ago
    I guess there's no way around that though, if you want dates to be first class members. Can't do "a bit of date".
    - mojombo 8y ago
      We added a proper datetime type because the only thing worse than having one is not having one. If you had to supply a datetime as a string, every TOML file would have a different way of doing it, which is...not so obvious.
  - adamch 8y ago
    Excluding the datetime RFC in the name of minimalism would make the language much worse (coughjson). I feel like this is as simple as it could be, but no more.
  - laumars 8y ago
    Datetime does need to be part of the spec if you want your markup files portable otherwise every TOML parser might decode a date slightly differently. In that regard it is really no different to saying "01" (string) is different to 1 (integer) in terms of preserving your data's integrity.
- laumars 8y ago
  I agree about the double bracket syntax however I don't think that is part of the specification any more, instead nested structures use a dot notation inside single brackets. Both solutions do still feel like a hack though, but the dot notation is definitely less ugly. That all said, for flatter schema's I do personally think TOML is more readable than it's JSON, YAML and XML counterparts. If there is one thing I did like about Windows back when I used to run it, it was the syntax of INI files (which TOML was heavily influenced by). Ultimately though, there is no perfect solution for all problems.
  - freyir 8y ago
    > for flatter schema's I do personally think TOML is more readable than it's JSON, YAML and XML Yes. But for nested data, I find TOML becomes the least readable and I have to fall back to YAML or JSON. Maybe we need just one more ML...
    - deckar01 8y ago
      I disagree. The way JSON and YAML nest data with indentation forces data to be disconnected from it's property chain when there are multiple large items at each level. TOML seems to provide a solution to that by allowing deeply nested paths to be declare explicitly at the top level for each item. You get to choose how to split the paths into containers instead of being locked into a 1-to-1 tree structure.
    - notheguyouthink 8y ago
      Oh man, I can't disagree more. I loathe YAML for readability. When I'm 2 pages down on a yaml tree I have no clue how many indents exist before what I'm working on. Likewise, when I scroll up, I quickly lose track of what the actual parent to the data I was working on is. I've found it to be an absolute mess. JSON doesn't even fit for me, because it's not human intended (imo). Being able to document (comments) configuration is a requirement for me on any config language.
  - unethical_ban 8y ago
    https://github.com/toml-lang/toml#array-of-tables https://github.com/toml-lang/toml#array-of-tables Still there FWIW.
- krapp 8y ago
  Yeah, that's weird. For the most part the language seems like a smarter slightly more flexible INI which I like (although there's no real standard for INI, most formats don't allow for nested arrays or tables,) but why embrace bracket notation for arrays, but not a keyed syntax with the same brackets for tables? Something like this would have been be a lot cleaner to me: [designers] [name = Guido, lang = Python] [name = Larry, lang = Perl]
- agumonkey 8y ago
  indicates an 'open' array ?
  - gnuvince 8y ago
    An array of dictionaries. In JSON, my example becomes: { "designers": [ {"name": "Guido", "lang": "Python"}, {"name": "Larry", "lang": "Perl"} ] }
    - mlthoughts2018 8y ago
      This JSON is vastly more readable, frankly. It’s so clear what container type “designers” refers to, and I can read directly what data structures the elements are. I can’t do that in Toml. Unless I just happen to remember some rote memorized convention for what the syntax unpacks into, there’s no way to tell by looking at Toml code. IMO this ought to be priority number one for any utility language like this. No matter what brevity of other syntax there might be, this lack of direct expression of the data structures is too much of a problem. This JSON is also much more readable than the “dot attribute” Toml syntax too, which I think is one of the least intuitive and hardest to read ways of creating nested data structures, certainly vastly less readable than the equivalents in YAML or JSON. I’ve never understood why anyone would say Toml is easier to read than YAML or JSON. It’s drastically harder to read and more confusing.
      - agumonkey 8y ago
        Nesting has locality value, which is often desireable.. but as I said, the [[toml]] syntax yields open arrays, it seems you can define thing in multiple passes (which can be harmful but may also be a need once in a while)
        mlthoughts2018 8y ago
        Sure, I only mean that the syntax for it in Toml is extremely hard to read. I personally just find JSON and YAML much, much easier to read.
- mojombo 8y ago
  Yeah, it's not my favorite part either. We've made them mostly unnecessary by adding inline tables, but for heavy nesting of arrays of tables, you still need to use them, which is why I mentioned that there are still some weaknesses for large, complex config files. Hoping to make this better in 2.0.
  - ben509 8y ago
    In defense of double brackets, I first encountered TOML in pipenv[1], and just by experimenting found I could add another source. So they're reasonably obvious if you see them in an existing file. [1]: https://github.com/pypa/pipfile#pipfile https://github.com/pypa/pipfile#pipfile
    - mojombo 8y ago
      Yeah, they're ok for very simple use cases, it's when you start having more than one level of nesting that things get a little crazy.
fastball 8y ago
I'm more a fan of YAML. "YAML Ain't Markup Language"
- clhodapp 8y ago
  TOML and YAML both have kinda weird names because both were initially incorrectly said to be a "markup language" and then subsequently renamed. The original names were "Yet Another Markup Language" and "Tom's Own Markup Language".

laurent123456 8y ago

(2013)

aloisdg 8y ago
v0.5.0 is a new release! Changelog: https://github.com/toml-lang/toml/blob/master/CHANGELOG.md#050--2018-07-11 https://github.com/toml-lang/toml/blob/master/CHANGELOG.md#0...
- mojombo 8y ago
  Yes, we just released it two days ago! I know v1.0.0 has been a long time coming, but it's important to me that we get it right, as specs have a very long-lasting impact (much more so than a specific version of a library). We are indeed working hard towards a proper 1.0 though!
  - aloisdg 8y ago
    Congrats for the release! I opened an issue in LXIY minutes. I will looking into this new version and update the tutorial :) https://github.com/adambard/learnxinyminutes-docs/issues/3158 https://github.com/adambard/learnxinyminutes-docs/issues/315...
  - simcop2387 8y ago
    Something to consider for 1.0.0, a hexadecimal floating point type value. I don't think it's in there yet, but if it isn't https://www.effectiveperlprogramming.com/2015/06/perl-v5-22-adds-hexadecimal-floating-point-literals/ https://www.effectiveperlprogramming.com/2015/06/perl-v5-22-... They're incredibly useful if you need to specify an exact floating point value, and about rounding or precision issues. Other languages than perl support them, but that article does a good job of demoing them

communist_0 8y ago

It's worth remembering that Tom abused his role as a founder of GitHub and resigned. http://www.businessinsider.com/github-harassment-story-2014-4 http://www.businessinsider.com/github-harassment-story-2014-... https://blog.github.com/2014-04-21-results-of-the-github-investigation/ https://blog.github.com/2014-04-21-results-of-the-github-inv...

mojombo 8y ago

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 large, complex config, but I'm hoping to address that in a later version of the spec (perhaps 2.0). Happy to answer any questions you all have about TOML!

nixpulvis 8y ago
Hi Tom, huge fan of this project. 1. Would a file path type make any sense to add? TOML is ideal for configurations, and so many configuration options use file paths. I know there are questions about platform dependency, and I don't have all the right answers for how that would work, but I could see it being possible somehow? 2. Data versioning is a big deal to me. For now there's always an option of just adding a "version" key and updating it, but can you think of a better way to do that with TOML? I'm always overly critical of JSON (despite overall being a fan) because it doesn't specify bit sizes of numbers. I notice that TOML has specified 64 bit numbers. It's nice to see that.
- mojombo 8y ago
  1. How would the file path type differ from a regular string? Would you want specific semantic validation for each platform? 2. This is still a big question, and we've been having a robust argument about it on GitHub [1]. It's a problem that so far has evaded an elegant solution, but usually when that's the case, it just means we haven't been creative enough about it yet! Or did you mean versioning of the data IN the config file? Can you elaborate? [1] https://github.com/toml-lang/toml/issues/522 https://github.com/toml-lang/toml/issues/522
  - nixpulvis 8y ago
    1. Yea the goal would be some kind of validation at parsing time. I'm not super familiar with TOML parsing, but there must be error cases in the implementations, so it seems like using `\` on UNIX systems, for example could return an error. The only hard part about this I see is distinguishing paths from strings syntactically without making TOML overly complex. 2. So basically, the majority of people don't want to type version numbers (I see where they are coming from, but respectfully disagree). I'm not sure if there exists a solution in that case. As for my comment, I was really talking about both kinds of versioning. Mainly that, if my data is version 2.3.1, I'd expect that to also lock the version of TOML, requiring a new version of my data for bumps to the underlying data structure. Again syntax is the hard part, as I'm having trouble imagining a way to actually do this. Furthermore I've seen data formats in the past that let you version "parts" of a format, I personally like this, but don't think it's a good fit for TOML.

wiradikusuma 8y ago

For more complex config, I highly recommend HOCON (https://github.com/lightbend/config/blob/master/HOCON.md https://github.com/lightbend/config/blob/master/HOCON.md), and its parser in Java (https://github.com/lightbend/config https://github.com/lightbend/config). It feels like Scala (Lightbend is the company behind Scala) in the sense that there are 100 ways to achieve the same thing and having different levels of "code elegance", but for me it's a plus, since I'm a Scala fan.

afraca 8y ago

Does anyone know why such a "joke proposal" (as stated by the author itself) was chosen for pretty significant projects like pip and cargo? (edit: I tried to say it began as something small and personal) (Well, I guess there's not that much to win/lose in the area of config languages, but still) (Also, I think it works pretty well, so this is not to downplay TOML!)

mojombo 8y ago
Well, it was only a joke to begin with. I couldn't stand the complexity or ambiguity of YAML and one night I had a few drinks and banged out my thoughts on something better. When people started writing implementations, I realized that TOML might actually have legs and started tightening it up and removing the snarky bits. I guess these projects felt the same pain I did about config files and presto! I think the moral of the story is: just put your whacky ideas out there and see what happens. You never know when you'll hit a chord.
- afraca 8y ago
  Thanks for response. I edited my response to be less snarky. Good job and thanks for the moral of the story.
niftich 8y ago
There's no one clear place to point to about how the decision was made for Cargo, but some nuggets have been left by authors [1]. The gist seems to be that JSON (and YAML, per that comment) was considered a poor format to author and maintain a config file in, and YAML had no lib in Rust and there was no appetite for anyone to write one. Pip's choice was made for them in the form of PEP 518 [2]. The authors of PEP 518 explain their rationale [2][3], which largely boils down to XML being too wordy and awkward to hand-edit, JSON awkward to hand-edit, various formats used by existing python tooling were underspecified and implementation-dependent, and YAML's python parsers being fairly complex and hard to vendor. [1] https://news.ycombinator.com/item?id=7938388 https://news.ycombinator.com/item?id=7938388 [2] https://www.python.org/dev/peps/pep-0518/ https://www.python.org/dev/peps/pep-0518/ [3] https://www.python.org/dev/peps/pep-0518/#other-file-formats https://www.python.org/dev/peps/pep-0518/#other-file-formats

skrebbel 8y ago

If only package.json had been package.toml

jxub 8y ago
Would that be hard to implement for npm/yarn? I'm sure that transforming TOML to JSON on the fly could be added as a step somewhere, resulting in changes to the package manager or just a wrapper command. Stylistically, I agree with you as TOML is clean and well thought. Moreover, TOML has support for more data types that JSON lacks leading to ugly workarounds (floats as strings anyone?). The main advantage of JSON is that its encoding/decoding is included in JS as it is, and it's generally deeply ingrained in the Node community.
- skrebbel 8y ago
  It would not be trivial because npm/yarn don't just read package.json but also modify it. See numerous GitHub issues in either repo about supporting comments inside package.json. Of course nothing is impossible, but I think that the ship has sailed. I was just dreaming of what could have been :-) Subtle details in NPM's behavior would've probably been designed differently if it was necessary to make updates to the package file without destroying layout and context.

niftich 8y ago

The news here is (presumably) the announcement of version 0.5.0 a few days prior [1], which includes several clarifications, rollup changes, and enhancements that accumulated over the last 3 years. In my opinion, one of the more useful features was the addition of Joda-style datetimes [2][3][4][5], which disambiguates between various kinds of datetime constructs aren't interchangeable yet commonly conflated. It's fair criticism that the addition of rich datetime types exceeds the language's original 'minimal' goal, but too many other languages and formats these days just punt to RFC3339 and leave no guidance or tooling on how to represent dateless times or timeless dates without introducing a ton of side-effects. This is a place where language standard libs, with few exceptions, have repeatedly dropped the ball, and similarly, language or library-agnostic, generic guidance is nowhere to be found. TOML raises the bar here, by providing a concept and notation to specify these values at rest, and gives parser writers, as opposed to the users, the task of finding a way to represent these values in whatever way is idiomatic for the given language. [1] https://github.com/toml-lang/toml/blob/master/CHANGELOG.md https://github.com/toml-lang/toml/blob/master/CHANGELOG.md [2] https://github.com/toml-lang/toml/pull/414 https://github.com/toml-lang/toml/pull/414 [3] https://github.com/toml-lang/toml/pull/362 https://github.com/toml-lang/toml/pull/362 [4] https://github.com/toml-lang/toml/issues/412 https://github.com/toml-lang/toml/issues/412 [5] https://github.com/toml-lang/toml/issues/263 https://github.com/toml-lang/toml/issues/263

mojombo 8y ago
Glad you like them, we spent quite a bit of time getting them right! Datetimes are a horrible mess of complexity, but hopefully over time languages and tools around them can standardize on a set of common primitives to make all our lives a bit less horribly messy. =)

dvfjsdhgfv 8y ago

Used to be called "INI file" in the past... In any case I'm glad to see it in several open source projects (Mailtrain for example). It's so much easier to read for humans than JSON.

runjake 8y ago
As mentioned in the source link, the INI format is not standardized. This is an attempt at a standardized format similar to INI.
mojombo 8y ago
Yeah, TOML is definitely INI inspired, but there is no canonical INI spec. I wouldn't say that TOML is INI, though. INI files still exist in their variously poorly specified ways.

communist_1 8y ago

epage 8y ago

Originally, I was fully on board with the homogeneous array requirement but its recently started causing me pains. Homogeneous arrays can come in the following forms - Shallow, literal type (a list of lists, regardless of the nested lists contain) - Full, literal type (a list of dicts of strings) - Logical type There are many times where a list is the best type for my data but I want to take advantage of logical types for easier configuration by my users. Below is an example of what I mean by "homogeneous logical types": `Cargo.toml` has you specify dependencies using a dict [dependencies] foo = { "version" = "1.0" } but allows a short-cut syntax where a string value is assumed to be the version value in the above dict. [dependencies] foo = "1.0" Generally this is done in Rust using Enums enum Dependency { Version(String), Specification(HashMap<String, String>), }

mojombo 8y ago
Homogenous arrays are partly to make implementations easier, and because if you really need that flexibility, you can always use an array of inline tables, which has the benefit of giving each sub-element a name, hopefully increasing the obviousness. I'm not sure I understand your complaint, though, can you give me another example of how it's biting you in real life?
- epage 8y ago
  > you can always use an array of inline tables, which has the benefit of giving each sub-element a name, hopefully increasing the obviousness Except the name would be duplicated with the content I'm storing. As for an example, its effectively Cargo. My use case is very similar (dependency reporting) but my content is slightly different (as I said, the value would effectively duplicate the key)
  - mojombo 8y ago
    Oh, you mean you want something like: list = [ "1.0", "2.7", { version = "1.4", path = "..." }, "9.9", ] Is that correct?

trendandbeyond 8y ago

test

otterpro 8y ago

I didn't know about TOML until I started using Hugo. I've been using YAML and TOML and I find both have their merits, especially for their simplicity. TOML looks like the classic INI file, and is fairly easy to use/learn. I've been trying to move toward TOML for everything. YAML is nice, but I had to be careful about white-space significance and also translation of "YES","NO", etc. https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html https://arp242.net/weblog/yaml_probably_not_so_great_after_a...

mojombo 8y ago
Absolutely. That's what I mean about TOML mapping unambiguously to a hash table. Strings in TOML are always quoted. There is no fuzzy interpretation of things like YES and NO. That way madness lies. I also am not a fan of meaningful whitespace, which is why TOML doesn't do that. Glad you're finding TOML useful, good luck on your projects!
- k__ 8y ago
  I have to admit, the string and array syntax are the only parts that keep me from using it instead of YAML. Probably because they are the only two features that need delimiters at start and end. The rest are only one-liners or simply stop if the next of the same type starts.
- Pxtl 8y ago
  > There is no fuzzy interpretation of things like YES and NO I think the big problem is that YAML is dynamically typed. If I had schema-enforced config files, I'd be perfectly happy to say that for boolean typed data all the values of YES and NO and ON and OFF and T and F and 0 and 1 can all be reasonably interpreted as a Boolean True and False. The problem happens when a string-typed or integer-typed member can also have their ON value interpreted into Boolean TRUE.
  - mojombo 8y ago
    Yeah, I'll agree with that, among many other issues with YAML. =) A schema would at least solve that problem, but I don't think most simple config users want to define a schema, so strong typing is a better solution.

EamonnMR 8y ago

It's surprisingly easy to add it as an optional drop-in, ex: https://github.com/EamonnMR/OpenLockstep/blob/master/data.py#L31 https://github.com/EamonnMR/OpenLockstep/blob/master/data.py...

tpaschalis 8y ago

Just dropping a useless comment to say thanks! Between Tom's work on Github, Jekyll, and TOML, I think he has influenced a vast amount of developers! For the projects I've used TOML on, it was a nice breath of fresh air and a terrific improvement over JSON (still mad about JSON's lack of comments). Simplicity wins!

mojombo 8y ago
It's never useless to say thanks! I really appreciate your kind words, it's the fuel that powers a lot of open source. Keep it up!
erikpukinskis 8y ago
Not to mention inventing MySpace!

thanatropism 8y ago

Funny enough, I learned how to/started to use TOML today. I was running some [redacted] experiments using a .pyc compiled script and wanted to experiment with parameters -- but then I had to compile the script again and again. Enter TOML: I can paste a bunch of "var_x = 2"-type statements (there's like 50) directly from Python, read them as a dictionary and find-replace all appearances in like 5 minutes while I'm waiting for an Uber. Thanks Tom!

mojombo 8y ago
Awesome, sounds like the perfect use case for TOML!

timvisee 8y ago

Cool. TOML is used quite extensively in Rust projects. I think it's awesome for very simple configurations. And newcomers don't have to learn anything in order to change a TOML configuration, which is very powerfull.

mojombo 8y ago
Yeah, Cargo and Rust have been really important in TOML gaining adoption. Love the Rust community!
kvark 8y ago
TOML is a great format, but it can not universally replace JSON, because it's designed for small nested depth. I've been trying to push RON as an alternative, and it works very well for WebRender, Amethyst, and other projects in Rust.

miguelrochefort 8y ago

Looks a lot like Rebol/Red.

losvedir 8y ago

I just started a rust project and so had to learn TOML since that's what the package manager (and a lot of the ecosystem) uses. For some reason, though, I just struggle with the syntax. It says it's "obvious" but it wasn't to me. I think it says something that the README is full of "this TOML would be represented like this JSON", to help you understand what's going on. Every time I saw that, I was like "oh, now I get it." I don't know if that means JSON is just inherently more understandable, or I'm just more used to it, though. Are there obvious downsides to JSON for config that I'm missing? What are the advantages of TOML over JSON? Maybe eventually it'll "click", though. I think the following mean the same thing: [[foo]] bar = {baz = 5} [[foo.bar]] baz = 5 But I don't think the following works: [[foo]] [[bar]] baz = 5 That is, I think the double bracket syntax always starts at the top level? While the `=` are relative to the double brackets above it? Something about all that is non-obvious to me, and I don't love that there's multiple ways to do the same thing.

Pxtl 8y ago
Yeah, most of TOML looks good, but the .INI style [table] and even wierder the [[table-array]] thing seems like they were trying to hammer a square peg into a round hole for the sake of having config files that look like INIs.
- scrollaway 8y ago
  Backwards-compatibility with ini is in my opinion one of the more powerful aspects of TOML which help adoption. Kinda like how UTF8 is ASCII-backcompatible.
  - deleted 8y ago
    [deleted]
woodrowbarlow 8y ago
> Are there obvious downsides to JSON for config that I'm missing? for me, there are two. firstly, TOML supports comments. secondly, TOML or INI is very readable without indentation. i have learned that removing indentation from configuration files makes non-technical people much more comfortable editing the file by hand. when many non-technical people see braces and indentation, they feel overwhelmed and associate it with complexity. i don't really use TOML's more advanced features, though. i basically just use it like INI.

TooBrokeToBeg 8y ago

> Whitespace means tab (0x09) or space (0x20). > Newline means LF (0x0A) or CRLF (0x0D0A). Complicating things from the start. Not a good sign.

boramalper 8y ago
Well some (many, actually) people use Windows too, and some prefer tabs and some prefer spaces; I can’t see why this is a problem? A language for configs is different from a data interchange language: the former is intended to be written and edited by humans. See https://arp242.net/weblog/json_as_configuration_files-_please_dont https://arp242.net/weblog/json_as_configuration_files-_pleas...
sametmax 8y ago
Indentation is not significant. And you can't expect windows users to always check their editor is lf compliant. Toml is not just for programmers

Nadya 8y ago

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 ambiguous name.alternative = "Robert" # And this is backwards to me name.alternative.first = "Robert" Some people might suggest to instead do first.name = "Bob" last.name = "Smith" alternative.first.name = "Robert" But now nothing is scoped to [name] and if I need to get the full name I can't just pull in [name] but need to pull in [first], [last], and [alternative]. That's really messy in my opinion. All of these are names and should be scoped to [name] and not their own structure.

latk 8y ago
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?
- Nadya 8y ago
  >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". Your explanation is perfect and I understand the justification why it isn't possible now - so thanks for that! The array alternative provided by xinau is also an acceptable replacement - maybe even better to be honest, especially in this particular scenario. >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? I came back from lunch and realized what I was trying to do didn't make sense while trying to convert it to JSON. Having name.first be both a value and contain an object doesn't make sense - unless it were to contain an array value but then why have the object and not just have the value? All very silly. So I guess my "only issue with TOML" is that I never sat down and tried to express what I wanted to express in any other way. It made a lot more sense in my head than on paper. :)

anonu 8y ago

How does toml compare to Google protobufs as a configuration system?

mojombo 8y ago
Protocol Buffers is a data serialization format and unsuitable for configuration, as the binary serialized data is not human readable.

exabrial 8y ago

Does TOML have a schema?

mojombo 8y ago
Not currently, but it's something I'd like to add as a separate spec sometime later.
- firepoet 8y ago
  In case you're curious, one of the Clojure libraries I found while researching TOML seems to have an ABNF grammar. It sits at the top of this file: https://github.com/lantiga/clj-toml/blob/0.4.0-instaparse/src/clj_toml/core.clj https://github.com/lantiga/clj-toml/blob/0.4.0-instaparse/sr... What a lovely language! I may have to use it..

kaushalmodi 8y ago

Here's the TOML parser in Nim language: https://github.com/NimParsers/parsetoml https://github.com/NimParsers/parsetoml. It works great based on my small amount of testing, and TOML is awesome! I wish more people start using it.

andris9 8y ago

I am using TOML in most of my projects and once the configuration files grew too large I just extended the syntax with “#@include filepath” declarations and split up the config files. Works great. https://github.com/nodemailer/wild-config/blob/master/README.md#toml-extensions https://github.com/nodemailer/wild-config/blob/master/README...

noisy_boy 8y ago

Some questions I couldn't find answers for: - Is interpolation supported? e.g. "key1" = "value" and then "key2" = "$key1". That would be very useful in avoiding repetition. - What is the keyword for null? e.g. when I want to set the value to null

TheDong 8y ago
> interpolation? No, there is no facility for variable templating, interpolation, references, or anything of the like in toml. If you wanted that, you could implement it in your application by doing post-processing on strings, or you could not use TOML. > What is the keyword for null? If you have "x = 1", you can always comment it out with "# x = 1". There's no specific support for null. it would be kinda silly to have it anyways since null is a language construct more than anything else, and e.g. some lanuages support mixed strings + nulls in one array, but many don't.

amai 8y ago

The syntax for tables is awkward compared to CSV (This is actually also true for XML, JSON, YAML).

amelius 8y ago

I'm not a fan of configuration files. Instead, I prefer the style of "calling" the program from within a script, and passing the configuration as parameters. This also allows to pass e.g. callback functions. Imho, this is much more flexible, and the advantages grow over time, whereas configuration files tend to accumulate awkward/convoluted constructs as the software matures.

mchahn 8y ago

Should it be called a "language" when it has grammar but no semantics? (just curious)