[erlang-questions] fast JSON parser in C

[Richard A. O'Keefe]

On 26 Jul 2008, at 3:38 am, Chris Anderson wrote:
> Joe mentioned not using atoms as keys due to the atom table not being
> GC'd. The other consideration is making it unambigious between JSON
> arrays and JSON objects.

Jim Larson pointed out that there are actually THREE alternatives:
(1) always return labels as binaries.
     This is always safe, and always clunky.
(2) always return labels as atoms if you can.
     This is always nice to use, but is only safe if you
     can trust the sender to use a small set of labels.
(3) return labels as atoms if they are EXISTING atoms.
     This is the possibility that I missed (inexcusably).
     It means that a module that expects certain labels to be used
     and mentions those labels will se THOSE labels (and perhaps
     some others) as atoms, giving you the convenience,
     but at the same time it won't add anything to the atom table,
     giving you safety.

> It make sense to me to encode JSON arrays as Erlang lists, for the
> sake of simplicity. I agree that [{"foo",1},{"bar",2}] is easier to
> work with than the pure tuple version, which makes me lean toward
> using the outer wrapping {} as a marker for object-ness.

The latest revision of the EEP does the Joe Armstrong thing of
converting object <-> tuple with NO wrappers.  There is a certain
cuteness factor here: if you have a JSON term, then
	(1) Convert "..." to <<"...">>
	(2) Convert : to ,
and presto changeo, you have an Erlang term.  Easy to remember.
If you want a list, there is always tuple_to_list/1.

The EEP requires order to be preserved on output,
but not on input.  There is an obvious problem with preserving
order within "objects" on input, and that is that it is something
that JSON explicitly says does not matter.  What if people started
to rely on it, and then got a nasty surprise when they ran into a
JSON partner that didn't preserve order?

--
If stupidity were a crime, who'd 'scape hanging?