Toml: why toml map key not use <key>

Created on 27 Dec 2020  路  4Comments  路  Source: toml-lang/toml

currently, [] is use for map key, but it is confused with a list:
[student1]
name=aaa
age=9

why not:
<{map_key}>
name=aaa
age=9

and:
<[list_key]>
name=sss

<{map_key}> is [map_key]
<[list_key]> is [[list_key]]

discussion new-syntax wontfix

Most helpful comment

TOML's table syntax is influenced by many informal INI formats. Headers with square brackets are common in these formats, and that usage is preserved in TOML with additional features. Square brackets are also used for lists, a.k.a. arrays. But lists are values; expect to see an equals sign = when the brackets are used to contain lists.

I can't say anything about the <{}> or <[]> syntaxes; I've never encountered their use in any context. Maybe others here have experience with those sorts of braces, but certainly not enough to merit using such syntax in TOML.

We try to make the language simple to learn, simple enough that you rarely need to resort to the specification more than once to work with it. A quick look at toml.io will give you the essentials and direct you to the formal spec documents for those cases in which you need them.

Hope that helps.

All 4 comments

TOML's table syntax is influenced by many informal INI formats. Headers with square brackets are common in these formats, and that usage is preserved in TOML with additional features. Square brackets are also used for lists, a.k.a. arrays. But lists are values; expect to see an equals sign = when the brackets are used to contain lists.

I can't say anything about the <{}> or <[]> syntaxes; I've never encountered their use in any context. Maybe others here have experience with those sorts of braces, but certainly not enough to merit using such syntax in TOML.

We try to make the language simple to learn, simple enough that you rarely need to resort to the specification more than once to work with it. A quick look at toml.io will give you the essentials and direct you to the formal spec documents for those cases in which you need them.

Hope that helps.

It's very common that languages, be it programming languages or markup/config languages, use similar tokens for different meanings. Like the minus sign - meaning subtraction (binary operator) and negation (unary operator), or the equal sign = being used for assignment or equality comparison.

In the end it's a choice that balances readability, ease of writing, orthogonality and KISS (languages with fewer constructs are generally easier to learn).

Using [...] in toml for multiple concepts checks all these requirements. Sure, at the time of invention, they could've chosen a different one at the cost of complicating the language and arguably complicating readability (remember that toml deliberately 'looks like' ini files and other config formats, so that people have a very small learning curve coming from other formats).

I personally herald the creators of toml for being so adamant at keeping the language as simple as possible to learn and by staying away from obscure tokens and syntax. With all parsers being open source, you can easily expand it to adapt a different format for those scenarios that require a different syntax. Even if I'd have to make the choice only now, I'd still go for the square bracket syntax, as it's simpler, more readable and less typing than the ones proposed here.

Thanks for filing this @Silentdoer! ^>^

I don't have much to add to what has been said already -- TOML isn't going to be changing its syntax for tables. I gonna go ahead and close this now, since I don't think there's anything actionable here. :)

Thanks for filing this @Silentdoer! ^>^

I don't have much to add to what has been said already -- TOML isn't going to be changing its syntax for tables. I gonna go ahead and close this now, since I don't think there's anything actionable here. :)

thank you

Was this page helpful?
0 / 5 - 0 ratings