Every other language has figured this one out: just support trailing commas. JSON5 supports comments and trailing commas.
https://devblogs.microsoft.com/oldnewthing/20240209-00/?p=10... https://json5.org/
> The first version of CONL used # as a comment token, but I quickly ran into issues. URLs contain #, so my next version...
Every other language has figured this one out as well. Wrap strings in quotation marks.
> That led to a data-model where each value is one of scalar|list|map (Compared to JSON’s null|bool|number|string|object|array, this felt good).
I'm not sure what a "scalar" is in CONL (is it always a string?) but a config file format having fewer types than JSON does not feel good to me. Even JSON's hand-wavy "number" type is problematic (whether "1" is an integer or float or some some other type is implementation-defined). TOML got it right to distinguish integers from floats. TOML got this right.
No one wants that in a config file
If you're older than 40, you remember that there did exist an aeon, long, long ago, when people did not use data object serialization formats as config files. When config files were written not to be easy to parse, but to make it easier for human beings to configure software. When nobody believed there was one single good way to do everything. When software was written not to aid computers, but to aid humans.
Config files have always been a variant of key-value or section-key-value, except that we used to have ad hoc (and probably buggy, inconsistent, incomplete or all three) rules for quoting; array items separated by a mix of spaces, commas or something else; comments (semicolon, percent, sharp) different for each program. Case sensitivity was also a crap shoot, sometimes different between keys and values.
These days TOML (which more or less just works) just works. I have mixed feelings about YAML but certainly I would not swap it with endless variants of sendmail's m4 madness.
Again with the TOML vs YAML? Ya'll can't come up with anything but another version of the same old thing? You don't need to do the same thing everyone else does with a tiny twist. Think outside the box. Expand your mind!
Sure, Sendmail/M4 was a pain in the ass. Postfix was more along the lines of key-value. But Exim had its own rule format, and Qmail took simplicity to the extreme by creating a different file for all the different options.
How about an X11 config file? Nginx? Puppet? Bind? Fstab? Vimrc? Rsyslog? Netrc? Cups? Pppd? Iptables? Apt? Cron? Sysctl? SSH? Just name a program on Linux that wasn't created in the last 15 years and it will have a different config file format, tailored to the users and use cases of that application. And none of them are JSON, YAML, or TOML.
You don't have to make yours completely unique, but you also don't have to go "oh well, there's only 3 formats to choose from, I guess I will have to settle for one of those". DO YOUR OWN THING! It's your program! Don't be a slave to convention!
The second "just works" should have been "is almost always enough".
Yeah. I've got no idea what your parent comment is talking about.
> When config files were written not to be easy to parse, but to make it easier for human beings to configure software.
*eyes rolling*. All I can remember is the hundreds of hours I've spent trying to figure out how to configure something in Apache httpd, BIND, iptables, and god forbid, Sendmail!!
Config files were written not to be easy to <anything>. There was no rhyme or reason. Every project had their own bespoke config. All from the whims and fancies of the devs of the project.
Good thing that was all in the past and I had no job and no responsibilities. If software today made configuration like they did 40 years ago, I'd just give up!
JSON superset, optional quotes for keys, sensible string handling, comments, automatic env variable handling, variable references.
It's not perfect (all sufficiently powerful configuration language has quirks), but I love it.
Oops.
Being able to comment out sections of a config file easily is a prime use-case; and that really implies using newlines as delimiters, and well, you fall into this trap..
That aside, you don't need semantically-meaningful indentation to support commenting-out whole sections, see e.g. any braces-based lexer/parser that supports `/* ... */` style comments.
I've also been playing around with a configuration format, for similar reasons, although my approach is to make it easy(enough) to read/parse for both humans and machines.
HN post: https://news.ycombinator.com/item?id=42516608
Any feedback is welcomed, but keep in mind is just a toy project which has only one user in mind(me), no plans to conquer the world or solve the config format problems for all :)
- don’t mind the peculiarities of formats used for config
- create a format where semicolons denote comments (just… doesn’t look right)
In JS (well, its why we have JSON), it is //. In YAML, it is #.
Moreover - semicolon is a natural character used in comments (unlike // or #). It inferes with our human parsing.
comments and
commas are allowed at the end
thoughts?
Lots of people post ideas to Hacker News. Lots of good ideas, lots of bad ideas, and lots in-between. It's very much against the hacker spirit to be such a dismissive lazy jerk about it.
