Maml – a New Configuration Language

As you’ve said, all I did was fork a JSON.stringify function and swap colon for equals.

Anyone have a better solution they’ve worked with?

Edit: Why the downvotes? Terraform is using HCL? Are we talking a different HCL here?

There are currently two items in the FAQ. While the first one seems to be formatted with AI (I don't know if the arguments are AI generated though, how do you tell?), the other certainly doesn't look AI-generated: https://github.com/maml-dev/maml/issues/3#issuecomment-33559...

You might checkout my project, Confetti [1]. I conceived of it as Unix configuration files with the flexibility of S-expressions. I think the examples page on the website shows interesting use cases. It doesn't have a formal execution model, however, for that you might checkout Tcl or Lua.

[1] https://confetti.hgs3.me/

If you squint it looks and works like a functional programming language, but instead of actually being one (like Dhall for example) it simply looks like configuration : keys and values.

The "types are values" and "values defined multiple times must unify" rules are really simple, and enable easy comprehension of what's happening and are powerful enough without it being a full blown programming language.

In a way it kinda reminds me of the TypeScript structural type system in the ways you manipulate types like values, which I like as well.

This is my complaint too. However, they do add a proper integer type, which is the only thing that they do change with the data, as far as I can tell.

> It would be much more interesting to see a language which experiments with what is fundamentally representable

DER (and TER, which is a text format I made up to be compiled into DER (although TER is not really intended to be used directly in application programs); so TER does have comments, hexadecimal numeric literals, and other syntax features) does support many more data types, such as arbitrarily long integers, ASCII, ISO 2022, etc. My own extension to the format adds some additional types, such as a key/value list type and a TRON string type; the key/value list type is the only nonstandard ASN.1 type needed (together with a few of the standard ASN.1 types: sequence, real, UTF-8 string, null, boolean) to represent the same data as JSON does.

> for example like how the Nix language supports functional programming and has functions as a first-class data type.

For some applications this is useful and good but in others it is undesirable, I think.

My experience is different: TOML isn't obvious if there's an array that's far from the leaf data. Maybe that's what you experienced with the hierarchical data?

In my usage of it (where we use base and override config layers), arrays are the enemy. Overrides can only delete the array, not merge data in. TOML merely makes this code smell more smelly, so it's perfect for us.

What valid JSON would be invalid MAML?

Toml fixes some issues with shallow Yaml, but sucks at deeply nested data.

Maml looks nice at cursory glance. It seems to do nesting, numerics, comments, and strings right.

We're really close to having a great format. I'd like to see more attempts before accepting what we have as permanent.

There are dozens of us!

Using parentheses instead of curly braces is fine by me, but it doesnt seem to solve the issue of syntax bikeshedding.

The fundamental problem is “configuration” is a huge area, from simple key-value lists to complex declarative languages. And you want the format to be both easy to read and edit for humans and simple to parse and process for computers. No single format will be perfect for all use cases, but perhaps a compromise can be found which is good enough for most cases.

If anything it's a spec that writes itself.

I've been using it for niri recently, and it's quite nice.

It seems like we will be forced to use both forever though

YAML is also often abused as a DSL and for very large documents (Ansible, k8s, GH Actions, etc.), which makes it a pain to work with.

It's not so much that liking all of this is controversial. It's just a bad opinion. :p

To my knowledge only Zig's multiline strings work this way

    const hello_world_in_c =
        \\#include <stdio.h>
        \\
        \\int main(int argc, char **argv) {
        \\    printf("hello world\n");
        \\    return 0;
        \\}
    ;

Buying a domain is just part of the language craft, it doesn't mean this is a serious effort to supplant JSON. Mostly it just signals that the author is serious about keeping others away from the namespace, which maml is a really good one.

There are thousands of language projects, most of them completely pointless, many of them have a domain, approximately 0 of them are "serious" in the way you're thinking. It's mostly just hobbyists, but people still try to make a name for their work and buying a domain name is a way to protect that investment.

JSON does have significant things wrong with it, both with the syntax and with the data types.

For example, there is no proper integer type (this is the one problem that MAML corrects with the data), and it always uses Unicode (which MAML does not correct).

However, different file formats can be helpful for different purposes.

The "interesting things" include being (or at least aiming to be) the solution to the following problem:

"I need to configure ~200 tasks for each of 7 services in 5 datacenters where some stuff is dependent on DC, some on (service+DC) combination and also some machines where the jobs run need per-machine config overrides.

I want to avoid manual copy-paste-modify and I want to avoid the hell of generating configs from a Turing-complete language"

https://github.com/apple/pkl

I'm also not convinced that the small usability benefits of these alternative formats outweigh the burden of stumbling across them in different projects and then having to remember which parser works with which format.

If I had to choose between living with one canonical, well-established format like JSON and a jumble of 15 incompatible formats, I’d choose the single, well-established one every time.