7 ms·

CONL: "Markdown" for your config files

70 points by kretaceous 1y ago

dcreater 1y ago
Yes the existing formats have issues. Highly suspect that yet another format is the answer.
Rucadi 1y ago
Personally I've found great success using NIX as a programmable config file, and outputting json to be read by the application.
Hyperlisk 1y ago
Nice! I share a similar set of thoughts and ideals around configuration languages and I'm working on one as well. Mine has a very similar syntax, so you might be interested! You can find it if you dig through my comments.
bmandale 1y ago
json but: comments and commas are allowed at the end thoughts?
- dwheeler 1y ago
  You are re-inventing JSON5, another competitor in this space: https://json5.org/ https://json5.org/
kiitos 1y ago
> CONL uses indentation for structure. Oops.
- cirwin 1y ago
  Author here. Seemed like the least bad of the options. 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..
  - kiitos 1y ago
    Why is the ability to comment-out entire sections of a config file a primary use case? What are the motivating requirements for this feature? 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.
stared 1y ago
Be like: - don’t mind the peculiarities of formats used for config - create a format where semicolons denote comments (just… doesn’t look right)
- mtlmtlmtlmtl 1y ago
  That part looks fine to me, but then again I'm a lisp guy.
  - saghm 1y ago
    I think this is something in some assembly formats too? I remember seeing it once and wondering if maybe that's where the idea of ending lines in C with semicolons came from since at least in the examples I saw in school, a large number of lines had trailing comments with a description of what the operation was doing.
    - rzzzt 1y ago
      IDA uses ; for comments in its disassembler view, but it looks like C-style // single-line comments and /* comment blocks */ are also accepted by certain tools: https://en.wikibooks.org/wiki/X86_Assembly/Comments https://en.wikibooks.org/wiki/X86_Assembly/Comments
- fph 1y ago
  OP has a detailed rationale for going with semicolons. Feel free to counter those points, but you can't just dismiss the thing with a "doesn't look right" without any argument.
  - stared 1y ago
    Rationale: in the most popular modern langugues it is # or //. 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.
suprjami 1y ago
Sigh. https://xkcd.com/927/ https://xkcd.com/927/
- jsomedon 1y ago
  Damn you fast, I was just about to link that one too :-)
- anon7000 1y ago
  It’s linked in the opening paragraphs of the post lol.
- arp242 1y ago
  The only "sigh" here is the boring and predictive act of someone linking that xkcd as the most laziest and unimaginative content-free put-down that you can do. 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.
ChrisArchitect 1y ago
Earlier: https://news.ycombinator.com/item?id=43804489 https://news.ycombinator.com/item?id=43804489
rsyring 1y ago
Seems better to run with something everyone basically already knows¹ than to invent a new format with relatively zero support? 1: https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml
networked 1y ago
"An INI critique of TOML" this is inspired by was discussed in 2023: https://news.ycombinator.com/item?id=37595766 https://news.ycombinator.com/item?id=37595766. It received a lot of criticism, particularly for invoking Postel's law.
- nickm12 1y ago
  As best as I can tell, "An INI critique of TOML" is a subtle parody, not something to take inspiration from.
  - arp242 1y ago
    It reads like a parody, but the author is pretty serious; they've tried to fairly aggressively inject it in the Wikipedia article as well.
0xbadcafebee 1y ago
Those who don't learn their history are doomed to find new and innovative ways to repeat history. 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.
- wodenokoto 1y ago
  40 year old chiming in to say, what the hell are you talking about?
  - throwaway150 1y ago
    +1 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!
  - Magma7404 1y ago
    KEY=value, INI files?
    - wodenokoto 1y ago
      That was my initial thought too, but I just don't see how they fit the description.
- bonzini 1y ago
  > When config files were written not to be easy to parse, but to make it easier for human beings to configure software 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.
aburdulescu 1y ago
Shameless plug :) 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 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 :)
qznc 1y ago
I like https://nestedtext.org https://nestedtext.org because it doesn’t try to be clever and everything is just a string.
simonask 1y ago
I'm sorry, nothing beats KDL in terms of readability and friendliness. I've been using it in personal projects for a while, and it is just so pleasant. I wish it saw way more widespread usage. https://kdl.dev/ https://kdl.dev/
- immibis 1y ago
  A GUI beats it.
  - HdS84 1y ago
    You caveman! Everybody knew that watching config though a 30*80 chars ssh display in black/white should be enough for everybody. Who needs help displays, validation or even sliders?!
- misiek08 1y ago
  Similar to HCL which is way safer and clearer IMHO than all indent based craziness. Its lovely to see default values loaded thanks to some extra spaces. Brackets for the win! https://github.com/hashicorp/hcl https://github.com/hashicorp/hcl
- shortrounddev2 1y ago
  Looks like xml without < and >
nickm12 1y ago
> it’s really hard to comment out a line in a JSON file, because you end up with an extra trailing , on the previous line 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=109379 https://devblogs.microsoft.com/oldnewthing/20240209-00/?p=10... https://json5.org/ 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.
- jcelerier 1y ago
  > Wrap strings in quotation marks. No one wants that in a config file
throwaway150 1y ago
So everyone now wants a configuration file format named after them, isn't it?
martypitt 1y ago
HOCON is a worthy contender in this space - I wish it got more airtime. (We use it extensively). 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.
- asimpletune 1y ago
  We used hocon at a place that I once worked at and I more or less liked it. It did get a lot of abuse though. I think apple released a configuration language that seemed pretty good for the same things that we used hocon. I think it was pkl or something?
EasyMarion 1y ago
Really like the philosophy here. Keeping config formats minimal and text-first (rather than trying to be 'clever' with types or logic) feels underrated these days. CONL looks like it hits a nice sweet spot between human-editable and machine-parseable without drifting into 'just use a programming language' territory.

70 points by kretaceous 1y ago

Yes the existing formats have issues. Highly suspect that yet another format is the answer.

Personally I've found great success using NIX as a programmable config file, and outputting json to be read by the application.

Hyperlisk 1y ago

Nice! I share a similar set of thoughts and ideals around configuration languages and I'm working on one as well. Mine has a very similar syntax, so you might be interested! You can find it if you dig through my comments.

bmandale 1y ago

json but: comments and commas are allowed at the end thoughts?

dwheeler 1y ago
You are re-inventing JSON5, another competitor in this space: https://json5.org/ https://json5.org/

kiitos 1y ago

> CONL uses indentation for structure. Oops.

cirwin 1y ago
Author here. Seemed like the least bad of the options. 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..
- kiitos 1y ago
  Why is the ability to comment-out entire sections of a config file a primary use case? What are the motivating requirements for this feature? 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.

stared 1y ago

Be like: - don’t mind the peculiarities of formats used for config - create a format where semicolons denote comments (just… doesn’t look right)

mtlmtlmtlmtl 1y ago
That part looks fine to me, but then again I'm a lisp guy.
- saghm 1y ago
  I think this is something in some assembly formats too? I remember seeing it once and wondering if maybe that's where the idea of ending lines in C with semicolons came from since at least in the examples I saw in school, a large number of lines had trailing comments with a description of what the operation was doing.
  - rzzzt 1y ago
    IDA uses ; for comments in its disassembler view, but it looks like C-style // single-line comments and /* comment blocks */ are also accepted by certain tools: https://en.wikibooks.org/wiki/X86_Assembly/Comments https://en.wikibooks.org/wiki/X86_Assembly/Comments
fph 1y ago
OP has a detailed rationale for going with semicolons. Feel free to counter those points, but you can't just dismiss the thing with a "doesn't look right" without any argument.
- stared 1y ago
  Rationale: in the most popular modern langugues it is # or //. 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.

suprjami 1y ago

Sigh. https://xkcd.com/927/ https://xkcd.com/927/

jsomedon 1y ago
Damn you fast, I was just about to link that one too :-)
anon7000 1y ago
It’s linked in the opening paragraphs of the post lol.
arp242 1y ago
The only "sigh" here is the boring and predictive act of someone linking that xkcd as the most laziest and unimaginative content-free put-down that you can do. 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.

ChrisArchitect 1y ago

Earlier: https://news.ycombinator.com/item?id=43804489 https://news.ycombinator.com/item?id=43804489

rsyring 1y ago

Seems better to run with something everyone basically already knows¹ than to invent a new format with relatively zero support? 1: https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml

networked 1y ago

"An INI critique of TOML" this is inspired by was discussed in 2023: https://news.ycombinator.com/item?id=37595766 https://news.ycombinator.com/item?id=37595766. It received a lot of criticism, particularly for invoking Postel's law.

nickm12 1y ago
As best as I can tell, "An INI critique of TOML" is a subtle parody, not something to take inspiration from.
- arp242 1y ago
  It reads like a parody, but the author is pretty serious; they've tried to fairly aggressively inject it in the Wikipedia article as well.

0xbadcafebee 1y ago

Those who don't learn their history are doomed to find new and innovative ways to repeat history. 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.

wodenokoto 1y ago
40 year old chiming in to say, what the hell are you talking about?
- throwaway150 1y ago
  +1 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!
- Magma7404 1y ago
  KEY=value, INI files?
  - wodenokoto 1y ago
    That was my initial thought too, but I just don't see how they fit the description.
bonzini 1y ago
> When config files were written not to be easy to parse, but to make it easier for human beings to configure software 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.

aburdulescu 1y ago

Shameless plug :) 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 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 :)

qznc 1y ago

I like https://nestedtext.org https://nestedtext.org because it doesn’t try to be clever and everything is just a string.

simonask 1y ago

I'm sorry, nothing beats KDL in terms of readability and friendliness. I've been using it in personal projects for a while, and it is just so pleasant. I wish it saw way more widespread usage. https://kdl.dev/ https://kdl.dev/

immibis 1y ago
A GUI beats it.
- HdS84 1y ago
  You caveman! Everybody knew that watching config though a 30*80 chars ssh display in black/white should be enough for everybody. Who needs help displays, validation or even sliders?!
misiek08 1y ago
Similar to HCL which is way safer and clearer IMHO than all indent based craziness. Its lovely to see default values loaded thanks to some extra spaces. Brackets for the win! https://github.com/hashicorp/hcl https://github.com/hashicorp/hcl
shortrounddev2 1y ago
Looks like xml without < and >

nickm12 1y ago

> it’s really hard to comment out a line in a JSON file, because you end up with an extra trailing , on the previous line 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=109379 https://devblogs.microsoft.com/oldnewthing/20240209-00/?p=10... https://json5.org/ 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.

jcelerier 1y ago
> Wrap strings in quotation marks. No one wants that in a config file

throwaway150 1y ago

So everyone now wants a configuration file format named after them, isn't it?

martypitt 1y ago

HOCON is a worthy contender in this space - I wish it got more airtime. (We use it extensively). 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.

asimpletune 1y ago
We used hocon at a place that I once worked at and I more or less liked it. It did get a lot of abuse though. I think apple released a configuration language that seemed pretty good for the same things that we used hocon. I think it was pkl or something?

EasyMarion 1y ago

Really like the philosophy here. Keeping config formats minimal and text-first (rather than trying to be 'clever' with types or logic) feels underrated these days. CONL looks like it hits a nice sweet spot between human-editable and machine-parseable without drifting into 'just use a programming language' territory.