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
