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/
> 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?
For example, Unicode escaping seems incompatible. JSON’s “\u1234” format isn’t in the spec. There is a different syntax: “\u{123456}”
You are right. And the initial question is also meaningless as there is no difference between these two:
A parser is not able to decide if '"project"' equals 'project'.and the latter is not valid JSON
> 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.
I meant that the constant repetition of the hierarchical information could be cumbersome.