Toml: Tom's Obvious, Minimal Language • Hacker News Board

Re: Toml: Tom's Obvious, Minimal Language

#41

Post by notheguyouthink » Fri, Jul 13, 2018, 3:18 PM UTC

freyir wrote: post #17

laumars wrote: post #8

Earlier quoted context omitted.

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…

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

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.

Re: Toml: Tom's Obvious, Minimal Language

#42

Post by otterpro » Fri, Jul 13, 2018, 3:20 PM UTC

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

Re: Toml: Tom's Obvious, Minimal Language

#43

Post by mojombo » Fri, Jul 13, 2018, 3:20 PM UTC

epage wrote: post #30

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 type…

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?

Re: Toml: Tom's Obvious, Minimal Language

#44

Post by nixpulvis » Fri, Jul 13, 2018, 3:22 PM UTC

mojombo wrote: post #29

nixpulvis wrote: post #25

Earlier quoted context omitted.

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 "v…

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…

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.

Re: Toml: Tom's Obvious, Minimal Language

#45

Post by nixpulvis » Fri, Jul 13, 2018, 3:23 PM UTC

KirinDave wrote: post #36

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…

Hi Tom. Dave here. I like a lot of the features in TOML, but I'm curious, can I have a pony? (Folks downvoting, PLEASE JUST LET PEOPLE HAVE JOKES EVERY NOW AND THEN)

No soup for you.

Re: Toml: Tom's Obvious, Minimal Language

#46

Post by mojombo » Fri, Jul 13, 2018, 3:24 PM UTC

otterpro wrote: post #42

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_prob…

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!

Re: Toml: Tom's Obvious, Minimal Language

#47

Post by stevefan1999 » Fri, Jul 13, 2018, 3:32 PM UTC

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…

This project reminds me of the good old INI files.

Re: Toml: Tom's Obvious, Minimal Language

#48

Post by aloisdg » Fri, Jul 13, 2018, 3:32 PM UTC

mojombo wrote: post #16

aloisdg wrote: post #7

Earlier quoted context omitted.

v0.5.0 is a new release! Changelog: https://github.com/toml-lang/toml/blob/master/CHANGELOG.md#0...

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!

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

Re: Toml: Tom's Obvious, Minimal Language

#49

Post by mojombo » Fri, Jul 13, 2018, 3:37 PM UTC

stevefan1999 wrote: post #47

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…

This project reminds me of the good old INI files.

As it should! It was inspired by INI, but with a desire for a proper spec that unambiguously maps the config file to a hash table.

Re: Toml: Tom's Obvious, Minimal Language

#50

Post by echohack5 » Fri, Jul 13, 2018, 3:38 PM UTC

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…

Hey Tom,

I just wanted to say thank you real quick.

We use TOML in [Habitat](https://github.com/habitat-sh/habitat) to define default and overridable configuration. It's super easy and expressive.

The [Habitat Core Plans](https://github.com/habitat-sh/core-plans) have quite a few examples about how it gets used in the project. If you are looking for examples of larger configuration files with .toml, then that might be a good place to look for some real world use.

Thank you again!