4 ms·
I recently wrote a TOML parser in Idris2. It's a cool language, but has some quirks. For me, it's that it's just a simple KV store with some sugar (that's nice!
by ghayes 6y ago
I recently wrote a TOML parser in Idris2. It's a cool language, but has some quirks. For me, it's that it's just a simple KV store with some sugar (that's nice!) but it also means that a lot of information is lost forever in parsing. For example, these two documents are strictly identical:
[info]
name = { first="bob", last="jones" }
and
info.name.first="bob"
info.name.first="jones"
This can be seen as a positive (it's a really simple document) or a negative (it's hard to machine-generate nice TOML, and it's easy to think there's more to the structure of a written document than there is).
- alecbz 6y agoCan you expand on the negatives? I don't think I understand what you mean.
- demurgos 6y agoI believe the main negative he is referring to is that there is no canonical representation for a given document. The input file can be structured to share common keys (in the example above it's `info`) or not. Since both inputs are parsed into the same value it means that writing a printer is harder: you now have the choice between different output representations. As a comparison, there's not much choice when serializing to JSON - the only variation is around whitespace. When serializing TOML you need more insight to decide what's the best representation for a human. A contributing factor to this issue is that TOML is mostly used for configuration files, so it often matters that the output is readable.