On Tue, 7 Jul 2026 at 19:00, Zsolt Parragi <[email protected]> wrote:
>
> What do you think about this in general? About using TOML? About the
> specific TOML format I suggested here?
Insofar my vote counts, TOML gets a -1 from me.
The argument is twofold: We don't have any TOML support, and I'm an
anti-fan of TOML.
While it is conceptually simple to read and write key-value and nested
object data, the implementation of its nested table notation and its
array-of-tables feature makes the whole configuration language more
complicated and confusing than the "obvious" and "minimal" implied by
its name, to the point of being practically unsuitable for what it's
being used for. Allow me to explain.
The common method for defining objects is as follows:
...
[path.to.the.table]
key = value
Which one would understand is approximately equivalent to (json)
{ "path": { "to": { "the": { "table": { "key": "value" } } } } }
There's an issue though: This interpretation depends on the previous
definitions.
E.g.
[[path.to.the]]
...
[path.to.the.table]
key = value
will be interpreted as
{ "path": { "to": { "the": [{ "table": { "key": "value" } }] } } }
So you can't rely on a consecutive snippet of the document to be
safely and correctly evaluated as a (sub)document of the whole, like
what you can in recursively defined formats like JSON or YAML
documents(*). This -to me- makes the format extremely annoying to work
with and unsuitable for anything related to configuration files, where
copying snippets is one of the most used and important methods of
inputting data.
The only recursively parsed component in TOML is the inline table (and
inline arrays) feature, which seems to map almost directly to JSON.
However, it can't be used as the top level definition (you can't have
an inline table or inline array as top-level object), and the other
structure-related parts of the language require the whole parsed
document as context to make sure the current table key name isn't
conflicting with one that was defined earlier in the document. I don't
believe that's a suitable property for configuration languages.
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)
(*): Yes, there are some features in the YAML language that break this
rule, such as references and inclusions. I'm willfully ignoring those,
as I'm of the opinion that a YAML without those is a better YAML.
