JSON encoding of Loyc trees

@vladimir-vg mentioned he wanted to store syntax as "JSON in text file... file tree in Git or tree in IPFS". I'm not sure about those last two, but it would made sense to standardize a JSON representation of Loyc trees, so I'm sketching out a proposal. This proposal will mainly take the form of a series of examples showing how a given bit of LES3 code will be represented in JSON.

Identifiers

LES3	JSON	Comment
`Hello`	`"Hello"`	Strings = identifiers in JSON
`` \| `""`	The empty identifier is the empty string
`\t\0\n\u1234` \| `"\t\0\n\u1234"`	Escape sequences are largely the same
`\u01F4A9`.\u10FFFF` \| `"\uD83D\uDCA9.\uDBFF\uDFFF"`	Astral characters are surrogate pairs in JSON
`\xFF.\uD800` \| `"\xFF.\uD800"`	Invalid UTF-8 bytes are transliterated to 0xDCxx characters. High surrogates (0xD800..0xDBFF) are left alone.
`#` \| `"+#"` \| Single-character strings with an ASCII code of 64 or less are reserved for special purposes. Use a `+` prefix (#98) to define a single-character identifier with one of these values.
`#if` \| `"#if"`	This rule does not affect multi-char identifiers
`'+` \| `"'+"`	This rule does not affect normal operators
`_` \| `"_"` \| This rule does not affect normal identifiers such as `_` (ASCII 95)

Literals

LES3	JSON	Comment
`x"hi!"`	`{"x": "hi!"}`	In general, literals become objects with one prop; the key is a "type marker"
`"hi!"`	`{"": "hi!"}`	The empty type marker represents a string
`@`"hi!" \| `{"@": 123}`	As usual, unusual type markers are allowed
`123`	`123`	JSON number => assume type marker is "_"
`123.0`	`{"_": "123.0"}`	JSON parsers may ignore the difference between "123" and "123.0". If a floating-point number is an integer, it should be stored in string form
`1234f`	`{"_f":"1234"}`	The type marker starts with `_` for all numbers
`1234f`	`{"_f":1234}`	In JSON, the second array element can be a number
`123`	`{"_":123}`	As usual, it can be stored as a pair instead
`true`	`true`	True and false are themselves (type marker `bool`)
`true`	`{"bool":"true"}`	Same thing in cumbersome form
`null`	`null`	Null is itself
`null`	`{"null":""}`	Null in cumbersome form
`json"{\"x\":123}"`	`{"json":{ "x": 123 }}`	Special case: object as JSON string
`json"[\"x", 123]"`	`{"json":["x", 123]}`	Special case: array as JSON string
`json"{\"x\":123}"`	`{"json":"{\"x\":123}"}`	Using special cases is optional
`json"{x:123}"`	`{"json":"{x:123}"}`	This cannot be stored in object form

Note that general JSON objects like { "x":1, "y":2 } have no interpretation above, and serve as an indicator that the JSON file does not represent a Loyc tree.

Calls

LES3	JSON	Comment
`foo()`	`["foo"]`	Calls are arrays
`1234(z)`	`[1234, "z"]`	As usual, literals can be called
`x"hi!"(z)`	`[{"x":"hi!"}, "z"]`	As usual, literals can be called
`foo(x, 2, null)`	`["foo", "x", 2, null]`	Call with 3 arguments
`x + 2`	`["'+", "x", 2]`	As usual, operators are identifiers with an apostrophe prefix
`{ }`	`["'{}"]`	As usual, braced block is a call to `'{}`
`#foo(42)`	`["#foo", 42]`	As usual, there's nothing special about `#`
`.foo 42`	`["#foo", 42]`	Remember, LES3's dot-notation means `#`
`{ "x": 123 }`	`["'{}", ["':", {"":"x"}, 123]]`	JSON stored in a Loyc tree is ugly when saved in JSON
`["x", 123]`	`["'[]", {"":"x"}, 123]`	JSON stored in a Loyc tree is ugly when saved in JSON
`foo(x)(y)`	`[["foo", "x"], "y"]`	As usual, complex targets are possible

Attributes

LES3	JSON	Comment
`@Foo X`	`["@","Foo","x"]`	In general, attributes are attached via arrays that start with the magic string "@"
`@x foo()`	`["@","x",["foo"]]`	(which, as mentioned before, is not an identifier)
`@x @y(z) foo`	`["@","x",["y", "z"],"foo"]`	There can be multiple attributes. The final item is the tree to which the attributes are attached.
`@123 X`	`["@",123,"x"]`	As usual, attributes can be any Loyc tree including literals.
`/comment/ X`	`["@",["%MLComment","comment"],"X"]`	Trivia are attached in the standard way
`foo`	`["@","foo"]`	This is legal, but pointless
N/A	`["@"]`	Meaningless and illegal
N/A	`"@"`	Meaningless and illegal

Edited Jan 21, 2021: since no one has reported interest in using the JSON encoding, I've changed parts of the proposal without notice. Most notably, backreferences and attributes now use a more compact encoding. Previously, @a @b foo() would be represented as {"@":["a","b"], "":["foo"]}, but now it's ["@","a","b", ["foo"]].

LES3	JSON	Comment
`@.id tree(a.b.c)`	`["*","id", ["tree",["'.",["'.","a","b"],"c"]]]`	A subtree that also has a name.
`@@id`	`["*","id"]`	Backreference to a previously defined subtree.
`@.id2 @x tree2()`	`["*","id2", ["@","x", ["tree2"]]]`	Define a subtree with an attribute.
`@x @@id2`	`["@","x", ["*","id2"]]`	Refer to a previously defined subtree and attach an attribute.
``(x) \| `["+","x"]	As mentioned above, certain one-character identifiers such as `*` must have `+` prepended to avoid ambiguity.

qwertie / ecsharp