> what's an object and what's an array? There are no objects — it's all lists (or arrays, if you prefer). This is a good thing, because ordering is always the

> what's an object and what's an array? There are no objects — it's all lists (or arrays, if you prefer). This is a good thing, because ordering is always the same. > What's a keyword and what's a literal? Everything's a byte string: any interpretation above that is a matter for the protocol. This is a good thing, because it means you neatly sidestep issues like JSON's numbers actually being floats rather than integers, as well as issues like numeric precision. 'But I want types!' Of course, they are good. But the type of a number isn't just integer or float: it's integer-which-is-a-known-version or float-which-is-between-zero-and-one-exclusive. You need to check those types at ingestion anyway; it's not a big leap from integer-which-is-a-known-version to string-which-parses-as-an-integer-which-is-a-known-version. > I can barely even tell the heirarchy where it's very visually obvious with the JSON. They are both indicated with indentation. Probably I should have used two spaces for the JSON indentation, but I was lazy.