ingy and I came up with p3rl.org/JSONY as a "JSON with less ceremony" compromise that I often find useful (it has a PEG grammar that's a superset of JSON so pretty easy to re-implement elsewhere)
The hyphen prefixed arrays are very weird. It looks like YAML but behaves differently. Doesn’t help that YAML is also a superset of JSON too.
I also don’t like space (char 32) used as a field delimiter because that opens up entire categories of bugs that are already a daily annoyance for shell scripting.
I respect your thought processes but I can see this particular specification being more confusing than productive to most other people.
The hyphen prefixed arrays were an ingyism. I don't use those at all but since he wrote the grammar I didn't feel like it was particularly fair to bitch about him sneaking in a single feature he wanted.
I use it basically like:
{ key1 value1 key2 [ value2a value2b value2c ] }
i.e. treating JSONY as "JSON but with as much of the syntactical noise as possible optional" which is what I always wanted it to be.
Plus because JSONY isn't at all indentation sensitive pasting chunks of JSON in becomes IMO a lot easier to comprehend.
A valuable thing for me is that if e.g. I'm writing a daemon that communicates via newline delimited JSON over a TCP or UNIX socket I can have a development mode where it uses JSONY as the parser so it's faster/easier to do quick interactive tests with socat.
I'm not going to criticize personal usage but for the point of accuracy the indention sensitive syntax of YAML is entirely optional. Like I said, it's a superset of JSON, which means the following is valid YMAL:
Granted that's still got a few additional control characters (comma and colon) but personally I think that aids readability because it wouldn't be clear to my what the intent of the parameters were in your example if you hadn't named them "key" and "value". But as I said, I'm not going to criticize personal usage.
