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

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