CCL: Categorical Configuration Language
18 comments
·January 6, 2025theamk
atoav
Not to discredit the author, there are some smart thoughts in there... but I can't help but feel like: yeah of course this is very elegant — but the complexity is not gone, it is elsewhere. And they are not showing that elsewhere.
Namely the parsing code.
sn9
You can literally just look at it: https://github.com/chshersh/ccl/tree/main/lib
atoav
Sure, but it is a configuration format if it is intended to be used in all kind of languages you have to show bow to deal with it in all kind of languages.
Checks that might be trivial in OCaml might be utter footguns in say C.
Don't get me wrong here, I get that this is someones spare time project that they might use for themselves only. I am fine with that. But I am unconvinced if the (I admit: well demonstrated) simplicity of the format translates to simplicity of use in the scope it aimed for (replacement for other wide spread configuration formats).
I don't say it is impossible (or even unlikely) that this is an improvement, I just caution against seeing an elegant minimalist approach and automatically assuming it makes things simpler — remember, computers with their binary file systems already have the most simple format that could exist: zero or one. Yet somehow people shot themselves in the foot parsing those for decades. Much of the complexity of computer systems stems from managing the simplicity of the underlying components (if we ignore the thick layer historically grown cruft).
What would it take to change my mind? Elegant examples how to parse all the examples in that post using major programming languages (C, C++, Javascript, Java, Python, Go, Rust, ...). That is ofc a lot of work, but if the format should be adopted that work would be needed anyways.
diggan
> The biggest problem with this format is that a lot of things are left for the app, so each app will have its own way to implement lists, bools, line wrap support
That seems to be one of the explicit goals:
> Configuration is specific to a particular application. What you want is to follow the rule of the least surprise and utility functions to parse strings.
Since configuration is specific to a particular program, so should the configuration, seems to be what the author is getting at.
Personally, what puts me off this particular configuration language is this part, hidden behind collapsed text:
> In fact, CCL is indentation-sensitive.
Programming/configuring stuff with invisible characters isn't my idea of fun, and it sounds especially cumbersome if everyone is using it differently, since the configuration language leaves a lot up to the users of the configuration.
bobnamob
I’m still sad there’s such an aversion to parens
Edn is a lovely config language that checks most of the authors boxes, while still being “composable”
nickm12
Everyone is entitled to scratch their own itch, but this seems like the most useless configuration language I've ever seen.
Take the "fixed point" example, where you have a boolean setting which one file says should should be "yes" and the other says it should be "no" and the language semantics composes that into a list with both values. For what boolean setting does this make sense?
The article says "Overrides are not a problem because you keep both values. And you can decide what to do with them: keep only the first, keep only the last or use some smart logic to combine both of them. You’re the boss."
If you need custom logic in your application determine the setting to use, how is this language helping you?
evujumenuk
I think this is probably the best place within these comments to note that one thing some people expect of a configuration format is to be able to hide information from the consuming piece of software.
Normally, it is often useful for a program to receive all the configuration from all sources. ("This flag is normally set to TRUE, has been set to FALSE on this system, has been set to TRUE by the user, and now there's an environment variable that says one thing and a command line flag that says something else.") Sometimes, integrating several incoherent settings into one is dependent on its consumer, or even the setting itself. Sometimes, you would like to be able to debug how different settings interact with one another. Sometimes, different settings can be merged without issue.
CCL exposes everything to the program receiving the config, which is something (some) people seem to abhor. I can see how wanting to hide information can be both useful and detrimental, so I'm wondering if this issue is actually orthogonal to configuration languages, meaning CCL, and others, shouldn't even concern themselves with it.
mightyham
I really like the conciseness of this syntax. The language seems very well thought through.
That being said, I've been working with NixOS recently and it's made me reconsider what is useful for a configuration language. In many reasonably large software projects, where configs become very complex, config reuse (in other words templating or meta-configuration) becomes an increasingly helpful feature. Nix configs are great because it's not just a config, but a full blown purely functional language for manipulating the config. It's intuitive and powerful once you get the hang of it, and I sometimes find myself wishing I could use it when I have to work with yaml, json, etc.
one-punch
You might be interested in nickel (https://nickel-lang.org/), which is a modern take on configuration management based on the experience of Nix/NixOS configurations: purely functional configuration, built-in validation (types & contracts), reusable (functions, modules, defaults), and in addition exports to Yaml, Json, etc.
To integrate nickel with nix, see how organist (https://github.com/nickel-lang/organist) does DevShell management.
Bost
Have a look at "Code is Data / Data is Code" https://en.m.wikipedia.org/wiki/Homoiconicity And then see how it's done in real life: https://guix.gnu.org/
trelliscoded
The equal sign is a required character for anything base64 encoded, which includes some things you’d expect to be in a config file, like ssh public keys and x509 certs.
herrington_d
Calling other languages like "none of the tooling" in the "why" section sounds like a huge self-roasting since CCL does not have, say, highlighting/LSP/FFI for adoption.
worthless-trash
Every configuration language that is not code ends up being wrong in multiple ways. We will never learn.
andrewflnr
Out of curiosity, do you like Dhall?
null
junon
What a delightfully arrogant article, to the point I believe it to be satire (stopped reading at section headers, perhaps I missed the punchline).
TOML is by far the most stripped down and easy to understand configuration format I've ever used, allowing just enough syntactic sugar to be useful without changing semantics. The fact it's made by Tom is meaningless, so its flagrant dismissal is silly to me.
Meanwhile, the proposed configuration format sounds like a nightmare to read. There is still clashing syntax, offloads all of the parsing work to the software (which means now you have the same config format with multiple different ways of interpreting values), restricts usage of certain characters with no way of escaping them (someone else mentioned base64), and otherwise requires that you recursively parse it for nested KVs rather than constructing the final in memory structures in a linear pass, adding a layer of indirection prior to parsing.
Not to mention, I really get turned off by this sort of pious writing style.
No thanks. Lots of reasons to dislike config formats we've seen before but this doesn't solve anything in my eyes.
hoseja
You'd think people would be more disinclined to xkcd://927 but for some reason this keeps happening.
That's a lot of words to describe a very simple syntax: name=value pairs, with line continuation using whitespace.
Basically RFC822 email headers, or Debian Control File Format [0] but with "=" instead of ":", and without dedicated comment character.
The biggest problem with this format is that a lot of things are left for the app, so each app will have its own way to implement lists, bools, line wrap support.. Even something like "value override" is left to program implementation. Don't expect YAML/JSON/XML-style automated validators/linters, each program will need its own bespoke parser/generator.
[0] https://www.debian.org/doc/debian-policy/ch-controlfields.ht...