I am all for people experimenting and making things they like, but a domain was purchased so I can only assume a serious intent to make something of this and my only reaction is that I hope this is not taken seriously and disappears.
Isn’t the spec (https://maml.dev/spec/v0.1), which says “Duplicate keys are not allowed within an object.” sufficient for that?
Or am I misunderstanding what you mean by “array keys”?
It seems the spec is silent on whether key order is significant in dictionaries, though.
Also """ for multiline string, I only encountered that in Python. But apparently Java, Kotlin and Swift also do that now. In js, backquote already do the trick.
And the project is targeting more on configuration file, where TOML or YAML indeed are already competitors just as historically valid as JSON.
Seems to me more like almost no one thought the idea was any good.
The question then becomes: what format is that?
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.
Pardon my naming nitpick and lack of commentary on any technical aspect, but I don't think this is a markup language. What is being marked up? HTML is called that because it's marking up text with like bold and italics and font and color and paragraphs and stuff.
To be fair, YAML's creators had the same misunderstanding. Compare:
MAML seems to be designed as a configuration language, but calls itself a markup language. (YAML did too, but they changed it at some point.)
Yes, the hint is in the name:
Extensible Markup Language (XML)[0]
Thats not an helpful answer when the reason for this discussion is whether MAML, another document format with the term “Markup Language” in its name, is also a markup language. ;)
Your GP comment says that XML has markup in the name so that's a hint that XML is a markup language. Well... so does MAML. But we all agree that MAML is not a markup language. So we can't just say that XML is a markup language because the hint is in the name. By that logic, MAML would be a markup language too but it isn't. We need a stronger argument to explain why XML is a markup language and MAML is not. Like XML can markup content but MAML cannot markup anything. That was your parent comment's point.
This whole subthread has become an example of arguing for the sake of arguing. The messages in this subthread are correct on their own but missing the point of the parent comments.
Really, I do not see the point of this. These configuration languages are just different syntaxes for expressing the same fundamental data, bearing the same semantics. It would be much more interesting to see a language which experiments with what is fundamentally representable, for example like how the Nix language supports functional programming and has functions as a first-class data type.
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.
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.
The problem with mandatory keywords, like “true” and “false”, is they box you into the English language. And which data types should be intrinsic is arbitrary, for example, TOML has data types for date and time, but JSON does not [1]. Where do you draw the line? Confetti let’s you decide.
You might enjoy reading this take on the subject [2].
[1] https://toml.io/en/v1.0.0#offset-date-time
[2] https://github.com/madmurphy/libconfini/wiki/An-INI-critique...
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.
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...
Unfortunately this is becoming more and more common, even here in HN; I don’t think non-english speakers doing this realize how obviously ChatGPT-ish the results are, and how much of its own “thoughts” it injects into the text.
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"
This is basically JSON for humans. YAML is harder to use due to significant indentation (easy to mess up in editors, and hard to identify the context), and TOML isn't great for hierarchical data.
It addresses all my complaints about JSON:
> Comments
> Multiline strings
> Optional commas
> Optional key quotes
I wish it was a superset of JSON (so, a valid JSON would also be valid MAML), but it doesn't seem to be the case.
EDIT: As I understand, HCL is very similar in terms of goals, and has been around for a while. It looks great too. https://github.com/hashicorp/hcl/
What valid JSON would be invalid MAML?
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.
This is a format that's very well defined, good decisions where to be flexible (quoted keys) and when to be strict (no leading zeroes, no leading plus sign, error when integer parsing can't be precise, defining all corner cases in strings).
For almost all of these, I remember cases when something went wrong (or was just annoying) in another format.
I admire efforts to fix things.
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.
When I was a teen I made something called Nabla:
* XML-like syntax
* Schema language
* Compact binary representation
* Trivial parser for binary representation
* Optionally, simple dynamic programming language on top
If anything it's a spec that writes itself.
I've been using it for niri recently, and it's quite nice.
> Optional key quotes
For me, it is an anti-feature.
Each time something is optional, by definition, there is more than one way to do it. I much more prefer opinionated way, so it is consistent.
It is precisely why I like linters, so instead of a few ways to go, I pick one and stick to it. More focus on the content and less on things that do not matter.
I’ll just stick to environment vars or something code
MAML: Takes JSON, makes trailing commas & key-quoting optional. One may not like it, but it does indeed solve the scripting problem, and it's a nice and novel idea. Thereby it's a "Superset" of JSON. All JSON is valid MAML, but all MAML is not valid JSON.
JSONNet: Also a good attempt, directly solving the scripting problem with built-in functions and so on. But can be overwhelming.
Other approach: A strict "Subset" of JSON. Every value MUST end with a comma, whether it's first or last. Every key MUST be quoted. Comments MUST be a valid JSON key-value called ".comment" that will be ignored at parsing but otherwise part of the JSON. JSON5 seems to be more suitable for this.
Why are they optional? Why not just make them mandatory? So I don't need to guess which chars need quotes.
Edit: What most languages also lack: semantics on de-serialization. In the best case, I want to preserve formatting and stuff when the config is changed/re-committed programmatically.
say q:to/END/;
Here is
some multi line
string
END
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;
\\}
;C#:
var helloWorldInC =
"""
#include <stdio.h>
int main(int argc, char **argv) {
printf("hello world\n");
return 0;
}
"""; char string[] =
"multi\n"
"line\n"
"string";
And neither seems to be a great use case for configuration. A markup language, sure, but I'm not sure I see a significant need for multiline strings (even in general) in a config file.
Some benefits of the Raku solution are:
- multiline is just a superset of the standard quoting method (with the "to:/CLOSER/" adverb)
- indent level is set by the left edge of the closer, in the example 'END' ... so you can consistently indent / unindent your source and do not have to crowd all your heredoc to the left margin
- you can pick any delimiter or closer to avoid conflict with the text content
- there's a large selection of quoting adverbs - q (like single quotes), qq (like double quotes), qw (quote word), qx (shell quoting), etc.
Even with perverse patterns (which you cannot guarantee against in variable text), there is a way to gracefully handle:
q«say '''hi"""» #say '''hi"""
That's not a high bar of course, even the apache httpd pseudo xml is nicer than yaml.
[0] https://github.com/search?q=lang%3Acue&type=repositories
It could also do with a datetime datatype, the one thing (apart from comments) that I constantly feel the need for in JSON.
Json doesn't support dates, so we use strings in whatever format.
A good new configuration language should have dates. IMO.
So far it seems like Json with comments =)
This time around, I worked with Claude Code and we basically filled in each other's knowledge gaps to finish implementing every feature I was looking for in about 3 days of work:
Day 1:
- Plugin initialization
- Syntax highlighting
- JSON Schema integration
- Error inspections
Day 2:
- Code formatter (the code style settings page probably took longer to get right than the formatter)
- Test suite for existing features
Day 3:
- Intentions, QuickFix actions, etc. to help quickly reformat or fix issues detected in the file
- More graceful parsing error recovery and reporting
- Contextual completions (e.g., relevant keys/values from a JSON schema, existing keys from elsewhere in the file, etc.)
- Color picker gutter icon from string values that represent colors (in various formats)
I'm sure there are a few other features that I'm forgetting, but at the end of the day, roughly 80-85% of the code was generated from the command line by conversing with Claude Code (Sonnet 4.5) to plan, implement, test, and revise individual features.
For IntelliJ plugins, the SDK docs tend to cover the bare minimum to get common functionality working, and beyond that, the way to learn is by reading the source of existing OSS plugins. Claude was shockingly good at finding extension points for features I'd never implemented before and figuring out how to wire them up (though not always 100% successfully). It turns out that Claude can be quite an accelerator for building plugins for the JetBrains ecosystem.
Bottom line, if you're sitting on an idea for a plugin because you thought it might to take too long to bootstrap and figure out all the IDE integration parts, there's never been a better time to just go for it.
EDIT: Repo link for anyone interested: https://github.com/DavidSeptimus/maml-intellij-plugin
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
In some cases where keeping simple is a feature, it's good to know !
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.
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.
Yaml is popular like python because indentation as a scope depth indicator is far more visually intuitive for low skill programmers than braces (c,json) or counting/matching parents in lisp or begin end tags in xml.
Sorry your kubernetes ecosystem didn't do that. Why not get them to change parsers? A hell of a lot easier than changing k8s to toml or maml.
Because ultimately that's what the frustration of yaml comes from, right? Kubernetes config?
There are dozens of us!
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?
Terraform doesn't have a built-in deep merge function, but it will merge `.tfvars.json` files in the order given on the CLI, if you specify multiple `-var-file` arguments. For what it's worth, as of Terraform 1.8, you can also use functions from third-party providers like isometry/deepmerge [2] to perform a deep merge.
[1] https://developer.hashicorp.com/terraform/language/parameter... [2] https://registry.terraform.io/providers/isometry/deepmerge/l...
Do yourself a favor and use Cuelang instead.
Word of warning though: documentation isn't the best and takes some time to get, but once it clicks...
[0]: https://cuelang.org
(To be fair, I’m in favor of that)
Edit: Oh, no commas.
Or is there any reason why to choose this over the others?