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

From: Greg Hendershott (greghendershott at gmail.com)
Date: Tue Apr 23 14:35:31 EDT 2013

I've used the JSON library with various web APIs and found the design
decisions to make sense in practice.

1. Arrays vs. lists: In Racket lists are the de facto thing for this.
Anyway, I don't think the objective of JSON is to be faithful to
Javascript per se. (If it were, shouldn't the choice be a dictionary,
since IIUC that's what JS arrays really are? ;) )

2. Symbols for dict keys: Although this struck me as odd, at first,
too, after a very short while it made sense. A couple small practical
points: You're saving some typing (leading ' instead of " and ").
Plus, symbols are colored differently than strings, making it easier
to visually parse the keys and values. IMO.

If after using it a bit it doesn't click, for you, you certainly could
try Neil's library, or fork your own variation. I'm definitely not
saying you're wrong to want it to work differently. I just wanted to
chime in and say it works well, for me.

On Mon, Apr 22, 2013 at 3:46 PM, Erik Pearson <erik at adaptations.com> wrote:
> 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
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users

Posted on the users mailing list.