Hello everyone, I created Confetti: a simple, typeless, and localization-friendly configuration language designed for human-editable configuration files.

In my opinion, JSON works well for data interchange, but it's overused for configuration, it's not localization-friendly, and it's too syntactically noisy. INI is simple but lacks hierarchical structures and doesn't have a formal specification. Confetti is intended to bridge the gap.

I aim to keep Confetti simple and minimalistic, while encouraging others to extend it. Think of it like Markdown for configuration files: there's a core specification, but your welcome to create your own variations that suit your needs.

> Confetti does not compete with JSON or XML, it competes with INI.

It clearly competes with JSON.

I think I would still much rather use JSON5 over this. It's quite similar in terms of structure and terseness, but I don't have to learn anything.

    // This is a comment.
    {
        probe_device: ["eth0", "eth1"],
        users: [
            {
                user: "*",
                login: "anonymous",
                password: "${ENV:ANONPASS}",
                machine: "167.89.14.1",
                proxy: {
                    try_ports: [582, 583, 584],
                },
            },
            {
                user: "Joe Williams",
                login: "joe",
                machine "167.89.14.1",
            },
        ],
    }

Top marks on the name!

Nice, I found one typo/editing thing though which kind of makes it contradict itself:

The first paragraph says:

[...] It is minimalistic, untyped, and opinionated. [...]

but then under "Notable features" it begins with a big bold *Unopinionated*, so that was very confusing.

I don't trust a config file that doesn't enforce quotes around strings. it's a footgun especially when it collides with ill-defined boolean

Nice looking project! The page in one place says it's opinionated and in another place says it's unopinionated. (I guess that means it's unopinionated :) ).

Looks similar to my favorite format KDL: https://kdl.dev/

Good to see a push towards less syntactic overhead, which is still considerable in JSON.

Loving this! Like other commenters here the syntax reminds me of KDL, except a lot simpler. I checked it out and was fully nerdsniped, so wrote an implementation <https://github.com/Heliodex/confetti-go> that passes all conformance tests, giving me a good feel for the language. Pretty easy to get working as well, though I haven't tried adding any of the appendices yet.

JSON, jsonc, json5, hcl, kdl, scfg, caddyfile... and that's just from earlier comments. After a brief search, puzzled, I ask: Is there really no more thorough comparison than wikipedia's[1]? No syntax-across-languages[2]? No design space characterization?

[1] https://en.wikipedia.org/wiki/Comparison_of_data-serializati... [2] https://rigaux.org/language-study/syntax-across-languages.ht...

In the spec <https://confetti.hgs3.me/specification/>:

> Confetti source text consists of zero or more Unicode scalar values. For compatibility with source code editing tools that add end-of-file markers, if the last character of the source text is a Control-Z character (U+001A), implementations may delete this character.

I’ve heard of this once, when researching ASCII control codes and related ancient history, but never once seen it in real life. If you’re insisting on valid Unicode, it sounds to me like you’re several decades past that happening.

And then given that you forbid control characters in the next section… make up your mind. You’re saying both that implementations MAY delete this character, and that source MUST NOT use it. This needs clarification. In the interests of robustness, you need to specify what parsers MUST/SHOULD/MAY do in case of content MUST violations, whether it be reject the entire document, ignore the line, replace with U+FFFD, &c. (I would also recommend recapitalising the RFC 2119 terms. Decapitalising them doesn’t help readability because they’re often slightly awkward linguistically without the reminder of the specific technical meaning; rather it reduces their meaning and impact.)

> For compatibility with Windows operating systems, implementations may treat the sequence Carriage Return (U+000D) followed by Line Feed (U+000A) as a single, indivisible new line character sequence.

This is inviting unnecessary incompatibility. I recommend that you either mandate CRLF merging, or mandate CR stripping, or disallow special CRLF handling. Otherwise you can cause different implementations to parse differently, which has a long history of causing security problems, things like HTTP request smuggling.

I acknowledge this is intended as the base for a family of formats, rather than a strict single spec, but I still think allowing such variation for no good reason is a bad idea. (I’m not all that eager about the annexes, either.)

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 }
        }
    }

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"
    }

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.

I like it! The spec could be more accessibly written, but it's somewhat understandable in casual reading. Perhaps it would benefit from a diagram like json's famous one

One thing I didn't understand is this example on the homepage:

> password "${ENV:ANONPASS}"

The spec doesn't seem to mention any ${}. Is this for the program to manage rather than the parser of the config going out to fetch an env var? If so, I find this a bit out of scope to show; at least, it confused me about whether that's built-in/supported syntax or if it's just a literal with syntax intended for a different program

Depending on how set in stone this is, another complaint I might have is that you still have the trailing comma issue from JSON, except it's not a comma but a backslash (reverse solidus, as the spec calls it—my mobile keyboard didn't even know that word). Maybe starting a list of arguments with [ could allow one to use any number of lines for the values, until a ] is encountered?

It reminds me of the Caddyfile.

   example.com {
   root \* /var/www/wordpress
   encode
   php_fastcgi unix//run/php/php-version-fpm.sock
   file_server

Nice! I like it. I've always liked INI for the exact advantage you cite - typelessness.

Blah blah blah it doesn't have a spec. Lack of a spec doesn't matter from the user's POV in this problem domain, as all configuration files are categorically application-specific anyway. It doesn't matter to the developer either, insofar as whatever implementation you use fits your needs. This isn't object notation, it's not data interchange, it's configuration.

This also reminds me of HCL

https://github.com/hashicorp/hcl?tab=readme-ov-file#informat...

Why is typeless considered something good?

I like the look of it, very clean

Though I'm not sure why using keywords like `true`, `false` or `null` are seen as a negative. Especially the numeral digits, its the system that most of the world uses...

Congrats on shipping this. It's similar to something that was in the back of my mind for a while. I'll give it a try!

Nice that Unicode is supported, and the localization is a nice twist

Are there any examples of what's possible with extensions?

To author:

In the "Material Definitions" example there are no { }. Why not? What's the difference? Is indentation significant?

Great work!

Suggestion, might be good to include Lua in the comparison table - since it’s also used for config as well.

So weird, I was toying with a DSL 1-2 years ago and strongly considered turning it into a configuration language because the ergonomics were much nicer than JSON or YAML, and reminded me of HCL in a way. It looked very similar to this.

I abandoned the effort, but nice to know that someone else had a similar idea. Will be trying this out!

So much continual effort wasted when for over 20 years we've had XML.

XML still works well as a configuration format.

Is it verbose? Very much so, but it ticks all the boxes:

- No ambiguity

- Typed

- Quick to parse

- Has Schemas that allow validation

- Widespread tooling support

All we needed was for applications to publish their XML schema files and any XML tool could allow for friendly editing.

I'm still a fan of HJSON, and JSON5 looks quite nice, but this does as well. That's all I can really say. There are so many choices, but looks like you did really well on this one.

Looks a lot like scfg.

https://git.sr.ht/~emersion/scfg

I really like this kind of config file. People are saying it's useless because you should just use JSON, but I think that misses the fundamental point of this style of config: you configure "things" not as part of a huge tree structure, but as their own free-standing structures. Users don't go into an array of users as a 3rd level of indentation, users are their own top-level thing.

This allows really cool things, like modular configs where one "main" config file can include multiple specific-purpose configs. One file can contain the "default users" while another can contain additional users, for example. Or each user can get its own file.

Looks nice. Less syntactic noise that many other efforts, a good thing IMHO.

Not at all in the direction where I'd want a configuration language to go... The marginal "improvements" wrt' punctuation are just inconsequential.

I'd take Prolog without I/O and (some? all?) extra-logical predicates as configuration language. Maybe if there's a way to require recursion to terminate, that'd be great, but not essential.

Can you please add comparison of your language with nix lang?

I like how the spec defines character classes by just passing the buck to Unicode

=====

Forbidden Characters

Forbidden characters are Unicode scalar values with general category Control, Surrogate, and Unassigned. Forbidden characters must not appear in the source text.

White Space

White space characters are those Unicode characters with the Whitespace property, including line terminators.

I don’t intend this to be mean, but is this satire? Confetti seems to proudly use concepts which are very much NOT popular right now.

For example, you’ve reintroduced the Norway Problem. https://news.ycombinator.com/item?id=36745212

And I personally hope to never edit another file which lacks a strict schema like this does.

Obligatory XKCD: https://xkcd.com/927/