Notation for Relative Tables

[trans]

Seems like one of those obvious things. Exact notation to be determined, but I'll throw out the one that comes to my mind first:

[servers] {
  [alpha]
  ip = "10.0.0.1"
  dc = "eqdc10"

  [beta]
  ip = "10.0.0.2"
  dc = "eqdc10"
}

[CloudiDust]

Tables are not using balanced delimiters now, so I am not quite in favor of this proposed notation.

I would propose utilizing the - symbol to indicate nesting levels, so:

[servers.alpha]
ip = "192.168.0.1"

[servers.beta.ports]
blocked = [80, 8080]

can be written as:

[servers]
-[alpha]
ip = "192.168.0.1"

-[beta]
--[ports]
blocked = [80, 8080]

[BurntSushi]

I'm not sure why this is an obvious thing to have. I think we discussed this a long time ago and rejected it. Let's just keep things simple and have [name] mean exactly one thing. I don't see any obvious drawbacks other than a tiny bit more typing.

[CloudiDust]

Or maybe the | symbol would look better? As in:

[servers]
|[beta]
||[ports]
blocked = [80, 8080]

[CloudiDust]

@BurntSushi, that's a fine decision.

FWIW, I am quite fond of Python's ConfigObj's approach. It has "relative tables", using extra pairs of []s, as in:

[servers]
[[beta]]
[[[ports]]]
blocked = [80, 8080]

But this syntax cannot be adopted by TOML even if relative tables are to be implemented, as [[foo]] has other meanings here.

[wycats]

Another option, which I don't feel all that strongly about, is to allow [.foo] to mean "relative to the parent". I think it looks kind of ugly, and would probably need to be restricted to one level so that multiple things could be nested under a single parent.

@BurntSushi it's not really just a little more typing; it makes nesting under things like [profiles.test.dependencies] essentially a non-starter. Maybe that's a good thing?

[CloudiDust]

@wycats, [.foo] is fine in my eyes, actually I prefer this notation to extra []s. But why should there be an one-level restriction?

[profiles.test]
[.dependencies]

[..rustcheck]
git = "..."

[..spec-rs]
git= "..."

Nice.

[wycats]

[foo]

[.bar]

[.baz]

The [.baz] needs to not be [foo.bar.baz]. Multiple ..s might work, but it will get out of hand quickly and become somewhat unreadable, I fear.

[ChristianSi]

@CloudiDust

[profiles.test]
[.dependencies]

[..rustcheck]

Hmm, do you mean [.dependencies] would expand to [profiles.test.dependencies], and [..rustcheck] to [profiles.rustcheck]? I think that would be confusing.

But I do like @wycats idea to expand names starting with a dot relative to whatever the last fully written table name was (if I got it right). So:

[servers]
[.apha]  # [servers.apha]
[.beta]  # [servers.beta]
[.beta.ports]  #  [servers.beta.ports]

That could come handy in some cases.

[wycats]

That said, when looking at it, it doesn't look as ridiculous as I feared.

[wycats]

I think he's saying that this:

[profiles.test]
[.dependencies]

[..rustcheck]
git = "..."

[..spec-rs]
git= "..."

Would expand to:

[profiles.test]
[profiles.test.dependencies]

[profiles.test.dependencies.rustcheck]
git = "..."

[profiles.test.dependencies.spec-rs]
git= "..."

[wycats]

It kind of looks like a little ASCII tree. You add .s as you descend levels. Like I said, it doesn't look as ridiculous as I thought it would.

FWIW: The verbosity is definitely blocking us from using nesting in Cargo for this kind of thing, but as I said above, that may be a good thing.

[CloudiDust]

@ChristianSi

No, dots represents nesting levels. [..rustcheck] has two leading dots, that means it is a child of the nearest preceding table with a single leading dot, i.e. [.dependencies].

So it expends to [.dependencies.rustcheck], and the process is recursive, we finally get [profiles.test.dependencies.rustcheck].

Sorry I failed to clearly express my idea.

[CloudiDust]

@wycats, yes that's the idea. Thanks. I am on my phone and type slowly.

[ChristianSi]

Ah, so we could say:

[servers]
[.apha]  # [servers.apha]
[.beta]  # [servers.beta]
[..ports]  #  [servers.beta.ports]

Yeah, that doesn't look bad...

[johanfange]

Doesn't seem like a huge win to me. Is it worth it?

Besides, it isn't truly relative either. It doesn't allow copy-pasting one chunk of toml into another, like one can do in json or xml. E.g. {"text":"hi"}, can be pasted into {"messages":[ ]} without modification: {"messages":[{"text":"hi"}]}

[servers]

[.alpha]
ip = "10.0.0.1"
dc = "eqdc10"
[..ports]
in = 215

[.beta]
ip = "10.0.0.2"
dc = "eqdc10"
[..ports]
in = 215
out = 216

vs

[servers]

[servers.alpha]
ip = "10.0.0.1"
dc = "eqdc10"
[servers.alpha.ports]
in = 215

[servers.beta]
ip = "10.0.0.2"
dc = "eqdc10"
[servers.beta.ports]
in = 215
out = 216

[mirhagk]

I think the biggest usefulness of it would be copying structure from XML files, where you have something like:

<logConfig>
   <file value="log.txt"/>
   <level value="5"/>
</logConfig>

which if converted without changing structure would become:

[logConfig]
[.file]
value="log.txt"
[.level]
value="5"

Of course that being said, this specification shouldn't cater to converting XML documents to this format, as the above should obviously just be:

[logConfig]
file="log.txt"
value=5

I agree with the earlier sentiment that this would make nesting easier, but that isn't necessarily a good thing.

[johanfange]

If we really want to go down this path, I suggest we expand #235 to allow multi-line inline tables instead. This would allow code somewhat similar to JSON:

[logConfig]
file = {
  value="log.txt"
}
level = {
  value="5"
}

Or even deeper nested:

[configs]
logConfig = {
  file = {
    value="log.txt"
  },
  level = {
    value="5"
  }
}

[mirhagk]

@johanfange Okay and now that TOML supports JSON, what should the M stand for?

[johanfange]

@mirhagk You tell me. TOML does seem to suffer from some feature creep.

Either way, with #235, we already support this almost-JSON. Well, as long as you keep it to one line.

One option is to add more syntax to support this feature as in the initial post. However, if we get #235, it would clearly be simpler to just relax the one-line restriction for inline tables.

[mirhagk]

Yes that is true. By allowing #235 we've already made it so regular expressions can't be used. Its not much harder to allow them to be multi line after that.

[redhotvengeance]

#235 was inspired by the discussion in #219, which specifically decided to keep the notation single-lined to discourage users from treating TOML like JSON.

[mirhagk]

But as it stands it simply discourages nice formatting with json. I'd prefer to see it instead disallow nesting. That'd prevent json from working within it, and also make it easier to parse as well.

[redhotvengeance]

@mirhagk Keep in mind that the notation in #235 is JSON-like, but not strictly JSON. But besides that, I think this discussion is getting off-track, since you're advocating against #235, and that debate would be better served on the #235 thread.

[mirhagk]

True, but it is relevant here as an alternative.

I am personally okay with the [..childOfChild] syntax. I find it intuitive enough, just leaving out the part before the . Its the kind of thing that certain organisations/projects will ban, but others will be grateful for. I am also of the opinion that config files shouldn't be nested so much that they even need this

[BurntSushi]

I personally really dislike this entire idea. I don't think TOML should have relative paths. A config is simpler and easier to understand without them because every table name can be resolved completely just by looking at it. With relative paths, you need to examine the tree of tables to resolve the full key.

I understand that there is some value to reducing the length of long key names, but I also think there is even greater value in 1) mitigating against deep levels of nesting and 2) knowing the full table name just by looking at it.

[mojombo]

I agree with you, @BurntSushi. TOML will most often be "write once, read many" and as such should be optimized for clarity in reading, which is aided by fully qualified table names.

[mirhagk]

Besides which with the aforementioned feature creep that TOML has, I feel like a feature like this can wait until we get a lot more real world usage before its added. Its easier to add it later than remove it.

[wycats]

I agree with @BurntSushi and @mojombo, for the record.

[mojombo]

@BurntSushi, @wycats Thanks for your thoughts. Closing this for now, as nothing here aligns with the Obviousness mantra of TOML.