4 ms·

There is also .ini, it's simpler than toml, though has more inconsistent implementations and formats. But the '[[table]]' is just '[table]' and I like the '[tab

by rdtsc 11mo ago

There is also .ini, it's simpler than toml, though has more inconsistent implementations and formats. But the '[[table]]' is just '[table]' and I like the '[table.subtable]' syntax better. But since we're criticizing formats ;-) maml https://maml.dev https://maml.dev is fairly good good. * I like multiline blocks and comment style * I do not like optional commas, either require them or not. I'd lean toward requiring them. * Not sure about ordered object keys. How should languages represent that, a map/dict kind of a data structure won't work it would have to be an ordered dict/list of kvs etc. Two objects {"a":"x", "b":"y"} and {"b":"y", "a":"x"} will be different then. I get the idea, but I am leaning toward not liking it by the time I finished typing all that. * I like booleans and null. Good for not having ons and offs those are just annoying.

skrebbel 11mo ago
About the ordered keys, most good languages have an ordered map type, either by accident or by design. Those few languages that don’t would need a list of key-value pairs. Given that this is for config, the performance cost of linear-scanning such a list would be negligible in realistic use cases. Personally I think it’s a very good decision. Simply by declaring that objects are ordered, it becomes the case and it unlocks a whole lot of useful mechanisms.
- rdtsc 11mo ago
  > Simply by declaring that objects are ordered, it becomes the case and it unlocks a whole lot of useful mechanisms. I wonder what it allows that unordered objects with sorted keys if needed couldn't allow. To me , it just adds an extra constraint on the programming language, but most of all, I don't like it because it's simply surprising. If the syntax look like a json object it should behave like a json object. Now if it was completely different syntax [a = b, c = d, ...] or something of that sort, or sexp ((a,b), (c,d),...).

by rdtsc 11mo ago

skrebbel 11mo ago

About the ordered keys, most good languages have an ordered map type, either by accident or by design. Those few languages that don’t would need a list of key-value pairs. Given that this is for config, the performance cost of linear-scanning such a list would be negligible in realistic use cases. Personally I think it’s a very good decision. Simply by declaring that objects are ordered, it becomes the case and it unlocks a whole lot of useful mechanisms.

rdtsc 11mo ago
> Simply by declaring that objects are ordered, it becomes the case and it unlocks a whole lot of useful mechanisms. I wonder what it allows that unordered objects with sorted keys if needed couldn't allow. To me , it just adds an extra constraint on the programming language, but most of all, I don't like it because it's simply surprising. If the syntax look like a json object it should behave like a json object. Now if it was completely different syntax [a = b, c = d, ...] or something of that sort, or sexp ((a,b), (c,d),...).