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 <e...@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 ____________________ Racket Users list: http://lists.racket-lang.org/users
