Toml: Reduce verbosity of sub tables

[dstufft]

Right now since sub tables require repeating the keys of any of it's parent tables, any situation where you want multiple sub tables, particularly nested, tends to end up being very verbose, looking something like:

[a]
value = 1

[a.b]
value = 2

[a.c]
value = 3

[a.c.d]
value = 4

[a.e]
value = 5

This I believe makes TOML uglier than it needs to be for situations where you end up with multiple nested sub tables. The problem primarily comes from the repeated key names of the parent tables, so what if TOML just allowed you to omit that? So essentially the above would become:

[a]
value = 1

[.b]
value = 2

[.c]
value = 3

[..d]
value = 4

[.e]
value = 5

The rule would be pretty simple, the . make it relative to the previously defined table with one fewer ..

While whitespace is still optional, you can make it more immediately obvious what is going on by applying some whitespace here to turn the above into something like:

[a]
value = 1

  [.b]
  value = 2

  [.c]
  value = 3

    [..d]
    value = 4

  [.e]
  value = 5

[TheElectronWill]

I think that's a good idea :)
I'll see how to implement it in my TOML parser.

[FranklinYu]

Interesting, but that might lead to:

1. "overhead" in your mind: when you see

``` toml
# something before...

[..key]
value = 1
```

you need to look above (possibly far away) to search for [.b] and [a].

1. complexity for parser, which need to fail correctly and provide meaningful error message to input with

toml [.a] # invalid without top level table above

and

toml [a] [..c] # invalid without intermediate table name

Note that TOML is designed for easy parsing than functionality.

I guess the above explains the downvotes. (Note: I myself do not fully agree with the second; I just provide such a point.)

[rmunn]

While I can see the convenience for writing TOML files, I don't believe it's worth the extra parser complexity. And I realize that I say this as the person who opened #409, but there's a difference. Hex and octal have some use cases where they are _essential_, not just nice-to-have (Unix file permissions, for example), and the added parser complexity is small. This suggestion, though, adds a lot of complexity for (IMHO) very little gain, and I don't believe that the trade-off is worth it in this case.

[jleclanche]

I'm currently evaluating using TOML for an ansible-like DSL which defines tasks like so (simplified):

[defaults]
user = "admin"

[[tasks]]

[[tasks.clone_repo]]
desc = "Clone repo from github"
type = "git"
[task.clone_repo.args]
source = "https://github.com..."
dest = "$HOME/repo"

This is a tough sell due to verbosity and it's the second time I encounter the use case, extremely quickly after picking up TOML which makes me think it's a pretty core issue to the language. Neither JSON nor YAML have this issue due to syntactic scoping.

Another issue caused by the verbosity is the human error element. I was going to write a paragraph about this, until I noticed upon remarshalling that the last header is missing an s. Oops - I guess this leads by example?

What this could look like:

[defaults]
user = "admin"

[[tasks]] # Would that work?

[[.clone_repo]]
desc = "Clone repo from github"
type = "git"
[..args]
source = "https://github.com..."
dest = "$HOME/repo"

Much less repetitive and removes most potential human errors.

To address @franklinyu's concerns regarding mental overhead on read:
This argument would have no ground in a discussion about JSON/YAML (say, about an array with a lot of subvalues) and I don't see why it should be any different here. The concern here is to actually reduce _write_ overhead, which incidentally I believe can reduce read overhead as well. In the cases where it doesn't, as this is an optional feature, it would be wise for the writer to use fully-qualified key names.

As for parser complexity, erroring properly should not be overly complicated here. What this adds to parsing is tracking the last-defined value at each level. I will expand on your example with another potential error though:

[a]
[.aa] # a.aa
[..aaa] # a.aa.aaa
[b]
[..baa]  # !!! could become a.aa.baa if not clearly specified

Conclusion: I'm strong +1 on inclusion of such syntax.

[mojombo]

I've never seen a repetition-reducing syntax of this sort that I think is obvious enough to be included in TOML, including all the proposals seen here. What might solve some of these problems, though, is dotted keys as seen in #499. It's an obvious solution that would allow a reduction in repetition for certain cases.