[racket] JSON module: why symbols for object keys? lists for arrays?

From: Erik Pearson (erik at adaptations.com)
Date: Mon Apr 22 15:46:39 EDT 2013

Hi,

I've just starting playing with JSON in racket. The goal is to use
JSON + Mustache-like templates to generate content. I've done this
lots with CL and Javascript, now trying the Racket approach. I'm
wondering about a couple of design decisions for the JSON module. For
one, I was a bit surprised but not shocked to see json object property
keys implemented as symbols. I assume it is for performance reasons? I
know there is be a trade off between the cost of converting strings to
symbols, the efficiency of symbol-based eq hash tables vs string equal
hash tables, etc. For me there is also the increase in complexity when
translating from JSON to jsexpr -- when components of JSON are
translated into different objects in the host language it is yet
another thing to remember, multiple forms of symbols, another layer of
coding. With some very relaxed testing (using code that would be
typical of my application), I've actually found string equal hash
tables to be a tad faster.

There is a similar issue with lists being used to represent JSON
arrays, over the more obvious choice of Racket vector. Maybe this is
because there are more core functions for dealing with lists compared
to the limited number for vectors (for data processing type things
like foldl). I suppose it is YMMV depending on how you use the data.
Random element access, simple iteration, or more complex folding, etc.

Anyway, I was hoping the authors or associates could comment on these
design decisions. A related topic is whether the approach of the JSON
module to allow specification of implementation for NULL, for
instance, could be extended to Objects and Arrays. On the other hand,
maybe it is better to fork a new JSON module with different and
specific implementation details, either for personal use or as part of
the standard library (it takes about 5 minutes to make the necessary
changes.)

Thanks,
Erik

Posted on the users mailing list.