I love this. It reminds me of PowerShell configuration files: https://ssg.dev/powershell-accidentally-created-a-nice-confi...

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/

▲ snarfy 13 hours ago | parent | next [-]

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

What valid JSON would be invalid MAML?

▲ sedatk 5 hours ago | parent | next [-]

For example, Unicode escaping seems incompatible. JSON’s “\u1234” format isn’t in the spec. There is a different syntax: “\u{123456}”

▲ qrios 8 hours ago | parent | prev [-]

You are right. And the initial question is also meaningless as there is no difference between these two:

  {"project": "MAML"}

  {project: "MAML"}

A parser is not able to decide if '"project"' equals 'project'.

	▲	whizzter 7 hours ago \| parent [-]
		and the latter is not valid JSON

▲ CBLT 15 hours ago | parent | prev [-]

> TOML isn't great for hierarchical data.

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.

	▲	sedatk 15 hours ago \| parent [-]
		I meant that the constant repetition of the hierarchical information could be cumbersome.