Show HN: I made Confetti: a configuration language file format

Whoa. This is really cool. I've thought a lot about markup / configuration languages. Aside from types (won't get into typed/typeless here) there are basically just a few possible structures: lists, maps, tables (lists of maps with same keys), and trees (xml-like with nested nodes of particular types) are the ones I think about.

Most existing formats are really bad for at least one of these. Tables in JSON have tons of repetition. XML doesn't have a clear and obvious way to do maps. Almost anything other than XML is awkward at best for node trees.

Confetti seems to cover maps, trees, and non-nested lists really well, which isn't a combination any other format I'm aware of covers as well.

Nested lists and tables seem like they would be more awkward, though from what I can tell "-" is a legal argument, so you could do:

    nestedlist {
        - { - 1 ; - 2 }
        - {
            - { - a ; - b }
            - { - c ; - d }
        }
    }

To get something like [[1, 2], [[a, b], [c, d]]]. Of course you could also name the items (item { item 1 ; item 2 }), but either way this is certainly more awkward than a nested list in JSON or YAML.

I think a table could be done like JSON/HTML with repeated keys, but maybe also like:

    table name age favorite-color {
        row Bob 87 red
        row "Someone else" 106 "bright neon green"
    }

This is actually pretty nice.

In any event, I love seeing more exploration of configuration languages, so thanks for sharing this!

My number 1 request is a parser on the documentation page that shows parse tree and converts to JSON or other formats so you can play with it.

Good catch! It's "unopinionated" for the user and "opinionted" in its design decisions. I'll stick with "unopinionated" for consistency.

The "expression arguments extension" is intended to allow for 'richer' expressions wherever an argument is expected. In the following example, it shows how you might use it if you need basic control flow in your configuration:

    if (x > y) {
        print "x is greater than y"
    }

It's freeform so your application would need to interpret what's between the '(' and ')'.

The "punctuator arguments extension" is the one I'm most anxious about since it might be too flexible, but I'd like to hear feedback. It lets you define your own domain-specific punctuators for your configuration so, for example, you might decide that "=" is a punctuator which means the following is equivalent:

    x = 123
    x=123

Under standard interpretation, if you wanted "=" it be distinct from "x" and "123", then white space would be required.

The "comment syntax extension" is just C style comments.

My goal was to keep the language basic while encouraging custom flavors. If an extension becomes ubiquitous, then - depending on what it is - it might merge with the standard or be added to the annex.

Yes, the "${}" would be for the program to evaluate; referencing environment variables that way isn't uncommon in Unix configuration files.

"Reverse Solidus" is the Unicode name for the character [1], so if you don't like the name, blame Unicode :)

I hadn't thought of using '[' and ']' for multi-line directives, that's an interesting suggestion. It vaguely resembles arrays as they appear in various other languages. It fits with Confetti's design of, ultimately, being user interpreted.

[1] https://www.compart.com/en/unicode/U+005C

Well im working alot with json in my job and privat coding life used from all sorts of different languages, and so far i always could sort stuff out.

And well - if anyone trusts external coders he should be damned (or isnt he already for doing so? never trust external data - the golden rule...)

Your case is interesting, i worked with Neo4j years ago in a PHP project and never run into such issues, but maybe i was just lucky.

Nowadays i code mostly golang and im always making sure that whatever an external party sends me is what im expecting (validation ...).

To your point of preventing somebody to write bad code - i've given up on that. Whenever i thought the environment will enforce someone to write proper code, people proof me to be wrong be finding new ways to do the most absurd things.

But ye, its worth a try.

So - why i question such a thing? Because i'm not a fan of adding more and more 3'rd party dependencies to my projects. And while confetti might be a good thing (i never said it can't be) it wont get into any default packaging in a forseeable future meaning i have to make sure that the dependency stays stable which adds another task and liability on my end. So instead of having to deal with the devil i know (validating json data) i have to deal with a new one to eliminate the old one.

Time will tell if confetti will make its way into stable reliable state for common languages - than i might give it a try.