On Thu, Dec 13, 2018 at 6:30 AM Thompson, David <dthomps...@worcester.edu> wrote: > > On Thu, Dec 13, 2018 at 12:56 AM Aleix Conchillo Flaqué > <aconchi...@gmail.com> wrote: > > > > Hi, > > > > I'm pleased to announce a new guile-json release 2.0.0. This is a > > breaking change release. It is not possible anymore to specify a JSON > > object using alists. Instead alist->hash-table needs to be explicitly > > used (examples can be found on the github page). This makes the > > bidirectional mapping between Guile hash-tables and JSON objects > > consistent. > > > > https://github.com/aconchillo/guile-json > > I'm a little disappointed to see this change.
Sorry to hear that. Let's see if we can fix it :-). > There are a few major > issues with using hash tables for this purpose: > > * They have no read syntax > * They use a procedural, mutable API > * They are slower than alists when the number of keys is small, which > is 99% of the time when dealing with serializing objects > The reason I chose hash-tables back in 2013 was that I wanted to an unordered data structure to strictly comply with the JSON spec. Probably it doesn't really matter if an object is ordered or not but I just wanted to stay as close to the spec as possible. Then, for JSON arrays the obvious choice was to use lists. I didn't even think about using vectors to represent arrays until jao (geiser's author) told me a couple of days ago. I agree with your points. My main concern is the one about the read syntax, not too worried about performance (may be I should?). I have to say I hate that users have to write alist->hash-table in guile-json 2.0.0, it's a pain in the butt. So I'm super open to make any changes to the library that make it better for the users. > For these reasons I do not use hash tables in my JSON > parser/serializer that I submitted to Guile years ago (but was never > merged) and use in many of my own projects. > Didn't know about that. > Why not do something like Racket does and use vectors for JSON arrays > and alists for JSON objects? It's not the ideal API IMO, but this way > only core data types with read syntax are used and is an improvement > over using hash tables. > That's one idea I was thinking to play with. That would really be a breaking change all over the library. The current breaking change only affects people building JSON (not sure how many of those are there), my guess is that most people only use the parser, but then they have to access the object through a hash-table. So, this would be a big change for them. I was also thinking to look at "reader macros", which was also a suggestion from jao. I'm not sure if you can do that in Guile, but I have found this: https://lists.gnu.org/archive/html/guile-user/2016-03/msg00039.html The idea would be to keep using hash-tables internally but allow the user to do something like: {"foo" 1234} to represent an object. Basically adding a bit of syntactic sugar. Best, Aleix
