* guile-json 2.0.0 released @ 2018-12-13 5:18 Aleix Conchillo Flaqué 2018-12-13 14:30 ` Thompson, David 0 siblings, 1 reply; 23+ messages in thread From: Aleix Conchillo Flaqué @ 2018-12-13 5:18 UTC (permalink / raw) To: guile-user 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 Happy hacking! Aleix ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-13 5:18 guile-json 2.0.0 released Aleix Conchillo Flaqué @ 2018-12-13 14:30 ` Thompson, David 2018-12-13 16:35 ` John Cowan 2018-12-13 22:48 ` Aleix Conchillo Flaqué 0 siblings, 2 replies; 23+ messages in thread From: Thompson, David @ 2018-12-13 14:30 UTC (permalink / raw) To: Aleix Conchillo Flaqué; +Cc: Guile User On Thu, Dec 13, 2018 at 12:56 AM Aleix Conchillo Flaqué <aconchillo@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. 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 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. 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. - Dave ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-13 14:30 ` Thompson, David @ 2018-12-13 16:35 ` John Cowan 2018-12-13 16:56 ` Thompson, David 2018-12-13 22:48 ` Aleix Conchillo Flaqué 1 sibling, 1 reply; 23+ messages in thread From: John Cowan @ 2018-12-13 16:35 UTC (permalink / raw) To: dthompson2; +Cc: guile-user On Thu, Dec 13, 2018 at 9:31 AM Thompson, David <dthompson2@worcester.edu> wrote: * 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 > I agree with these objections. > Why not do something like Racket does and use vectors for JSON arrays > and alists for JSON objects? In fact Racket uses hash tables, but it provides a (non-standard) lexical syntax for them: #hasheq followed by an a-list. > 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. > My objection to using vectors for JSON arrays is that they are often built up element by element, which JavaScript arrays support but Scheme vectors do not. So in practice you would create a list and then convert it to a vector. While the same thing is sometimes done with objects, it is more common for an object to have a reasonably fixed structure, which can be well represented as a vector of pairs, the vector equivalent of an alist. When the elements of the object are variable, they can be built up as an alist and then converted with list->vector. So given that we are changing the structure anyhow, I recommend this approach. -- John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org Even a refrigerator can conform to the XML Infoset, as long as it has a door sticker saying "No information items inside". --Eve Maler ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-13 16:35 ` John Cowan @ 2018-12-13 16:56 ` Thompson, David 2018-12-13 17:09 ` John Cowan 0 siblings, 1 reply; 23+ messages in thread From: Thompson, David @ 2018-12-13 16:56 UTC (permalink / raw) To: John Cowan; +Cc: Guile User On Thu, Dec 13, 2018 at 11:35 AM John Cowan <cowan@ccil.org> wrote: > > > > On Thu, Dec 13, 2018 at 9:31 AM Thompson, David <dthompson2@worcester.edu> wrote: > >> * 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 > > > I agree with these objections. > >> >> Why not do something like Racket does and use vectors for JSON arrays >> and alists for JSON objects? > > > In fact Racket uses hash tables, but it provides a (non-standard) lexical > syntax for them: #hasheq followed by an a-list. Ah, okay. I missed this detail in the docs. (I've never actually used Racket) >> 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. > > > My objection to using vectors for JSON arrays is that they are often built up > element by element, which JavaScript arrays support but Scheme vectors > do not. So in practice you would create a list and then convert it to a vector. Yes, I agree. For my own uses, I have avoided vectors for this reason, and also the reason that typically, when serializing, the user has a list of something, not a vector of something. > While the same thing is sometimes done with objects, it is more common > for an object to have a reasonably fixed structure, which can be well > represented as a vector of pairs, the vector equivalent of an alist. > When the elements of the object are variable, they can be built up > as an alist and then converted with list->vector. > > So given that we are changing the structure anyhow, I recommend this > approach. I think I understand what you are saying, but to me it has similar shortcomings as other options due the need of a something->vector procedure. An approach I've used in the past is to tag alists with a special symbol so that they can be distinguished from regular lists. Something like this: '(@ ("foo" . 1) ("bar" . 2)) The assoc-ref procedure will happily work with this structure, so reading parsed data requires nothing special. And for serialization procedures it is simple to add the '@' tag. I'm almost always using quasiquote in my serializers: `(@ ("foo" . ,(thing-foo thing)) ("bar" . ,(thing-bar thing))) There's an old patch of mine to add JSON to the Guile standard library that uses this approach. Unfortunately I was never able to get the code to meet the standards for merging. - Dave ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-13 16:56 ` Thompson, David @ 2018-12-13 17:09 ` John Cowan 2018-12-13 17:33 ` Thompson, David 0 siblings, 1 reply; 23+ messages in thread From: John Cowan @ 2018-12-13 17:09 UTC (permalink / raw) To: dthompson2; +Cc: guile-user Interesting. That's the approach (SXML attribute lists) that I had thought of earlier and abandoned because (a) you cannot search it with assoc and (b) you have to be careful to test in the order "empty JSON array, JSON object, non-empty JSON array", which is annoying. An approach which solves (a) but not (b) is to use (@) as the marker rather than just @. An array vs. vector approach of some kind solves (b). Another possibility is to continue to use a-lists but to require that the key be a symbol rather than a string. Since symbols can't appear in JSON representations, this is not subject to conflation, provided the implementation doesn't use a symbol for JSON null. You'd want a convenience predicate `json-object?` to identify such things. This solves both (a) and (b) provided you are careful to use symbols as keys internally. On Thu, Dec 13, 2018 at 11:56 AM Thompson, David <dthompson2@worcester.edu> wrote: > On Thu, Dec 13, 2018 at 11:35 AM John Cowan <cowan@ccil.org> wrote: > > > > > > > > On Thu, Dec 13, 2018 at 9:31 AM Thompson, David < > dthompson2@worcester.edu> wrote: > > > >> * 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 > > > > > > I agree with these objections. > > > >> > >> Why not do something like Racket does and use vectors for JSON arrays > >> and alists for JSON objects? > > > > > > In fact Racket uses hash tables, but it provides a (non-standard) lexical > > syntax for them: #hasheq followed by an a-list. > > Ah, okay. I missed this detail in the docs. (I've never actually used > Racket) > > >> 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. > > > > > > My objection to using vectors for JSON arrays is that they are often > built up > > element by element, which JavaScript arrays support but Scheme vectors > > do not. So in practice you would create a list and then convert it to a > vector. > > Yes, I agree. For my own uses, I have avoided vectors for this > reason, and also the reason that typically, when serializing, the user > has a list of something, not a vector of something. > > > While the same thing is sometimes done with objects, it is more common > > for an object to have a reasonably fixed structure, which can be well > > represented as a vector of pairs, the vector equivalent of an alist. > > When the elements of the object are variable, they can be built up > > as an alist and then converted with list->vector. > > > > So given that we are changing the structure anyhow, I recommend this > > approach. > > I think I understand what you are saying, but to me it has similar > shortcomings as other options due the need of a something->vector > procedure. > > An approach I've used in the past is to tag alists with a special > symbol so that they can be distinguished from regular lists. > Something like this: > > '(@ ("foo" . 1) ("bar" . 2)) > > The assoc-ref procedure will happily work with this structure, so > reading parsed data requires nothing special. And for serialization > procedures it is simple to add the '@' tag. I'm almost always using > quasiquote in my serializers: > > `(@ ("foo" . ,(thing-foo thing)) ("bar" . ,(thing-bar thing))) > > There's an old patch of mine to add JSON to the Guile standard library > that uses this approach. Unfortunately I was never able to get the > code to meet the standards for merging. > > - Dave > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-13 17:09 ` John Cowan @ 2018-12-13 17:33 ` Thompson, David 2018-12-13 18:28 ` John Cowan 0 siblings, 1 reply; 23+ messages in thread From: Thompson, David @ 2018-12-13 17:33 UTC (permalink / raw) To: John Cowan; +Cc: Guile User On Thu, Dec 13, 2018 at 12:09 PM John Cowan <cowan@ccil.org> wrote: > > Interesting. That's the approach (SXML attribute lists) that I had thought of earlier and abandoned because (a) you cannot search it with assoc and (b) you have to be careful to test in the order "empty JSON array, JSON object, non-empty JSON array", which is annoying. An approach which solves (a) but not (b) is to use (@) as the marker rather than just @. An array vs. vector approach of some kind solves (b). > > Another possibility is to continue to use a-lists but to require that the key be a symbol rather than a string. Since symbols can't appear in JSON representations, this is not subject to conflation, provided the implementation doesn't use a symbol for JSON null. You'd want a convenience predicate `json-object?` to identify such things. This solves both (a) and (b) provided you are careful to use symbols as keys internally. I have also experimented with this approach as well, but the things living in my brain haven't reached consensus about whether they think it's better. It has the nice benefit of not using anything "foreign" to anyone already familiar with core Scheme data structures, and a pattern matcher can easily distinguish a JSON object from a JSON array. The catch is that '() becomes both the empty array and empty object so there's no way for the serializer to do the right thing all the time. You could introduce a special value for one of those cases, and hey we're back at square one! ;) - Dave ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-13 17:33 ` Thompson, David @ 2018-12-13 18:28 ` John Cowan 0 siblings, 0 replies; 23+ messages in thread From: John Cowan @ 2018-12-13 18:28 UTC (permalink / raw) To: dthompson2; +Cc: guile-user On Thu, Dec 13, 2018 at 12:33 PM Thompson, David <dthompson2@worcester.edu> wrote: The catch is that '() becomes both the empty array and empty > object so there's no way for the serializer to do the right thing all > the time. You could introduce a special value for one of those cases, > and hey we're back at square one! ;) > Ouch, yes. I suppose the Final Answer is to have a JSON config object which specifies the protocol for creating, populating, and dissecting objects (and maybe arrays, unless everyone can agree they are lists), essentially a record of procedures. That way everyone can do what they want -- but it complicates building programs on top of such an overly flexible library. It's a hard problem. So far the workable solutions seem to be: lists for arrays, hash tables for objects lists for arrays, vectors of pairs for objects vectors for arrays, alists for objects None are ideal. -- John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org Be yourself. Especially do not feign a working knowledge of RDF where no such knowledge exists. Neither be cynical about RELAX NG; for in the face of all aridity and disenchantment in the world of markup, James Clark is as perennial as the grass. --DeXiderata, Sean McGrath > - Dave > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-13 14:30 ` Thompson, David 2018-12-13 16:35 ` John Cowan @ 2018-12-13 22:48 ` Aleix Conchillo Flaqué 2018-12-14 1:03 ` Aleix Conchillo Flaqué ` (2 more replies) 1 sibling, 3 replies; 23+ messages in thread From: Aleix Conchillo Flaqué @ 2018-12-13 22:48 UTC (permalink / raw) To: Thompson, David; +Cc: guile-user On Thu, Dec 13, 2018 at 6:30 AM Thompson, David <dthompson2@worcester.edu> wrote: > > On Thu, Dec 13, 2018 at 12:56 AM Aleix Conchillo Flaqué > <aconchillo@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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-13 22:48 ` Aleix Conchillo Flaqué @ 2018-12-14 1:03 ` Aleix Conchillo Flaqué 2018-12-14 2:28 ` John Cowan 2018-12-18 16:45 ` Ludovic Courtès 2 siblings, 0 replies; 23+ messages in thread From: Aleix Conchillo Flaqué @ 2018-12-14 1:03 UTC (permalink / raw) To: Thompson, David; +Cc: guile-user On Thu, Dec 13, 2018 at 2:48 PM Aleix Conchillo Flaqué <aconchillo@gmail.com> wrote: > > 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. Somebody (not sure who rain-1 is) just did that for me: https://github.com/aconchillo/guile-json/issues/25 What do you guys think? Aleix ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-13 22:48 ` Aleix Conchillo Flaqué 2018-12-14 1:03 ` Aleix Conchillo Flaqué @ 2018-12-14 2:28 ` John Cowan 2018-12-18 16:45 ` Ludovic Courtès 2 siblings, 0 replies; 23+ messages in thread From: John Cowan @ 2018-12-14 2:28 UTC (permalink / raw) To: Aleix Conchillo Flaqué; +Cc: guile-user, dthompson2 On Thu, Dec 13, 2018 at 5:48 PM Aleix Conchillo Flaqué <aconchillo@gmail.com> wrote: 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. > RFC 8259, the latest JSON RFC, clarifies this: JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences. So there is no *requirement* not to preserve order, there is simply no requirement to preserve it. -- John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, "The Nine Billion Names of God" ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-13 22:48 ` Aleix Conchillo Flaqué 2018-12-14 1:03 ` Aleix Conchillo Flaqué 2018-12-14 2:28 ` John Cowan @ 2018-12-18 16:45 ` Ludovic Courtès 2018-12-18 18:09 ` Aleix Conchillo Flaqué 2018-12-18 23:48 ` rain1 2 siblings, 2 replies; 23+ messages in thread From: Ludovic Courtès @ 2018-12-18 16:45 UTC (permalink / raw) To: guile-user Hello! Thanks for the new release! Aleix Conchillo Flaqué <aconchillo@gmail.com> skribis: > I was also thinking to look at "reader macros" I’d recommend against that: reader macros are global, so they could clash with unrelated bits of code, they are non-standard, and they often don’t buy you much. There are cases where having a shorthand, like #' or #~ in Guix makes a real difference, but for a dictionary data type, you could do with a regular macro. Ludo’. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-18 16:45 ` Ludovic Courtès @ 2018-12-18 18:09 ` Aleix Conchillo Flaqué 2018-12-19 10:48 ` Ludovic Courtès 2018-12-18 23:48 ` rain1 1 sibling, 1 reply; 23+ messages in thread From: Aleix Conchillo Flaqué @ 2018-12-18 18:09 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-user On Tue, Dec 18, 2018 at 8:46 AM Ludovic Courtès <ludo@gnu.org> wrote: > > I’d recommend against that: reader macros are global, so they could > clash with unrelated bits of code, they are non-standard, and they often > don’t buy you much. > > There are cases where having a shorthand, like #' or #~ in Guix makes a > real difference, but for a dictionary data type, you could do with a > regular macro. > Thanks for the advice! Any comments on the discussion between alist/vector vs hash-tables/list? How hard would it be for Guix to change to the alist/vector approach? I'm just considering options and would like input from anyone who uses guile-json, specially Guix who's probably the biggest user. Best, Aleix ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-18 18:09 ` Aleix Conchillo Flaqué @ 2018-12-19 10:48 ` Ludovic Courtès 2018-12-19 18:14 ` Aleix Conchillo Flaqué 0 siblings, 1 reply; 23+ messages in thread From: Ludovic Courtès @ 2018-12-19 10:48 UTC (permalink / raw) To: Aleix Conchillo Flaqué; +Cc: guile-user Hi Aleix, Aleix Conchillo Flaqué <aconchillo@gmail.com> skribis: > Any comments on the discussion between alist/vector vs > hash-tables/list? How hard would it be for Guix to change to the > alist/vector approach? I'm just considering options and would like > input from anyone who uses guile-json, specially Guix who's probably > the biggest user. I sympathize with David’s comments and would have been happy keeping the ability to pass alists as inputs. :-) I haven’t checked but IIUC quite a bit of code in Guix would have to be modified to use ‘alist->hash-table’. As for vectors vs. lists, I suppose Scheme vectors in theory correspond directly to JS arrays (O(1) access), so that’d be an argument in favor of using vectors on the Scheme side. However vectors in Scheme are less convenient than lists, as John noted, and I’m guessing that often lists are good enough. Tricky! Thanks, Ludo’. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-19 10:48 ` Ludovic Courtès @ 2018-12-19 18:14 ` Aleix Conchillo Flaqué 2018-12-19 19:17 ` rain1 ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Aleix Conchillo Flaqué @ 2018-12-19 18:14 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-user On Wed, Dec 19, 2018 at 2:48 AM Ludovic Courtès <ludo@gnu.org> wrote: > > Hi Aleix, > > Aleix Conchillo Flaqué <aconchillo@gmail.com> skribis: > > > Any comments on the discussion between alist/vector vs > > hash-tables/list? How hard would it be for Guix to change to the > > alist/vector approach? I'm just considering options and would like > > input from anyone who uses guile-json, specially Guix who's probably > > the biggest user. > > I sympathize with David’s comments and would have been happy keeping the > ability to pass alists as inputs. :-) > Yes, me too. The problem was that guile-json was broken, since there was no way to distinguish json arrays (lists) from json objects (alists) and the code that guile-json had was doing the wrong thing. > I haven’t checked but IIUC quite a bit of code in Guix would have to be > modified to use ‘alist->hash-table’. > > As for vectors vs. lists, I suppose Scheme vectors in theory correspond > directly to JS arrays (O(1) access), so that’d be an argument in favor > of using vectors on the Scheme side. However vectors in Scheme are less > convenient than lists, as John noted, and I’m guessing that often lists > are good enough. Tricky! > My guess is that most of the time people build objects with JSON so it seems logic to map them to the most convenient way to represent that in Scheme which would be alists. So, I'm really considering switching to alists for objects and vectors for arrays. Thanks! Aleix ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-19 18:14 ` Aleix Conchillo Flaqué @ 2018-12-19 19:17 ` rain1 2018-12-19 20:05 ` John Cowan 2018-12-20 9:34 ` Aleix Conchillo Flaqué 2 siblings, 0 replies; 23+ messages in thread From: rain1 @ 2018-12-19 19:17 UTC (permalink / raw) To: Aleix Conchillo Flaqué; +Cc: guile-user On 2018-12-19 18:14, Aleix Conchillo Flaqué wrote: > On Wed, Dec 19, 2018 at 2:48 AM Ludovic Courtès <ludo@gnu.org> wrote: >> >> Hi Aleix, >> >> Aleix Conchillo Flaqué <aconchillo@gmail.com> skribis: >> >> > Any comments on the discussion between alist/vector vs >> > hash-tables/list? How hard would it be for Guix to change to the >> > alist/vector approach? I'm just considering options and would like >> > input from anyone who uses guile-json, specially Guix who's probably >> > the biggest user. >> >> I sympathize with David’s comments and would have been happy keeping >> the >> ability to pass alists as inputs. :-) >> > > Yes, me too. The problem was that guile-json was broken, since there > was no way to distinguish json arrays (lists) from json objects > (alists) and the code that guile-json had was doing the wrong thing. > >> I haven’t checked but IIUC quite a bit of code in Guix would have to >> be >> modified to use ‘alist->hash-table’. >> >> As for vectors vs. lists, I suppose Scheme vectors in theory >> correspond >> directly to JS arrays (O(1) access), so that’d be an argument in favor >> of using vectors on the Scheme side. However vectors in Scheme are >> less >> convenient than lists, as John noted, and I’m guessing that often >> lists >> are good enough. Tricky! >> > > My guess is that most of the time people build objects with JSON so it > seems logic to map them to the most convenient way to represent that > in Scheme which would be alists. > > So, I'm really considering switching to alists for objects and vectors > for arrays. > > Thanks! > > Aleix Yes scheme arrays <-> json arrays scheme alists <-> json objects seems like a good choice. it is a bijection, nothing clashes or overlaps and everything has a literal syntax. It will mean we have to use vector-ref/vector-map instead of car/map and stuff, but I think that's fine. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-19 18:14 ` Aleix Conchillo Flaqué 2018-12-19 19:17 ` rain1 @ 2018-12-19 20:05 ` John Cowan 2018-12-19 21:13 ` Ludovic Courtès 2018-12-20 9:34 ` Aleix Conchillo Flaqué 2 siblings, 1 reply; 23+ messages in thread From: John Cowan @ 2018-12-19 20:05 UTC (permalink / raw) To: Aleix Conchillo Flaqué; +Cc: Ludovic Courtès, guile-user On Wed, Dec 19, 2018 at 1:16 PM Aleix Conchillo Flaqué <aconchillo@gmail.com> wrote: So, I'm really considering switching to alists for objects and vectors > for arrays. > I still favor the other way about: lists for arrays, avectors for objects, because arrays are typically varying in length and objects are mostly not. ;; Here are a few helpful (but untested) procedures ;; which are in the public domain de minimis (but I will sign ;; a contributor agreement if needed): (define (alist->avector alist) (let* ((len (length alist)) (vec (make-vector len))) (let loop ((i 0) (alist alist)) (when (not (null? alist)) (vector-set! vec i (car alist)) (loop (+ 1 i) (cdr alist))) vec))) (define (avector->alist avec) (let ((len (vector-length avec))) (let loop ((i 0) (alist '())) (if (= i len) (loop (+ i 1) (cons (vector-ref avec i) alist))) (reverse alist)))) (define vector-assoc (case-lambda ((key avec) (vector-assoc key avec equal?)) ((key avec pred) (let ((len (vector-length avec))) (let loop ((i 0)) (cond ((= i len) #f) ((pred key (car (vector-ref avec i))) (vector-ref avec i)) (else (loop (+ i 1))))))))) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-19 20:05 ` John Cowan @ 2018-12-19 21:13 ` Ludovic Courtès 0 siblings, 0 replies; 23+ messages in thread From: Ludovic Courtès @ 2018-12-19 21:13 UTC (permalink / raw) To: John Cowan; +Cc: guile-user Hi John, John Cowan <cowan@ccil.org> skribis: > On Wed, Dec 19, 2018 at 1:16 PM Aleix Conchillo Flaqué <aconchillo@gmail.com> wrote: > > So, I'm really considering switching to alists for objects and vectors > for arrays. > > I still favor the other way about: lists for arrays, avectors for objects, because arrays are typically varying in length and objects are mostly not. I’ve never seen avectors used anywhere and I’m not convinced it’s a good idea to introduce them here as it may be off-putting to many. Ludo’. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-19 18:14 ` Aleix Conchillo Flaqué 2018-12-19 19:17 ` rain1 2018-12-19 20:05 ` John Cowan @ 2018-12-20 9:34 ` Aleix Conchillo Flaqué 2018-12-20 10:59 ` Ludovic Courtès 2 siblings, 1 reply; 23+ messages in thread From: Aleix Conchillo Flaqué @ 2018-12-20 9:34 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-user On Wed, Dec 19, 2018 at 10:14 AM Aleix Conchillo Flaqué <aconchillo@gmail.com> wrote: > > My guess is that most of the time people build objects with JSON so it > seems logic to map them to the most convenient way to represent that > in Scheme which would be alists. > > So, I'm really considering switching to alists for objects and vectors > for arrays. > This would be it: https://github.com/aconchillo/guile-json/commits/switch-to-alist-and-vectors I'll write some tests and sleep on it more, but I already like it better than the current state. Aleix ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-20 9:34 ` Aleix Conchillo Flaqué @ 2018-12-20 10:59 ` Ludovic Courtès 2018-12-20 18:09 ` Aleix Conchillo Flaqué 0 siblings, 1 reply; 23+ messages in thread From: Ludovic Courtès @ 2018-12-20 10:59 UTC (permalink / raw) To: Aleix Conchillo Flaqué; +Cc: guile-user Aleix Conchillo Flaqué <aconchillo@gmail.com> skribis: > On Wed, Dec 19, 2018 at 10:14 AM Aleix Conchillo Flaqué > <aconchillo@gmail.com> wrote: >> >> My guess is that most of the time people build objects with JSON so it >> seems logic to map them to the most convenient way to represent that >> in Scheme which would be alists. >> >> So, I'm really considering switching to alists for objects and vectors >> for arrays. >> > > This would be it: > > https://github.com/aconchillo/guile-json/commits/switch-to-alist-and-vectors This seems to affect ‘scm->json’ (essentially returning to what we had in 1.x, except for arrays) but not ‘json->scm’ right? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-20 10:59 ` Ludovic Courtès @ 2018-12-20 18:09 ` Aleix Conchillo Flaqué 2018-12-29 23:51 ` Aleix Conchillo Flaqué 0 siblings, 1 reply; 23+ messages in thread From: Aleix Conchillo Flaqué @ 2018-12-20 18:09 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-user On Thu, Dec 20, 2018 at 2:59 AM Ludovic Courtès <ludo@gnu.org> wrote: > > Aleix Conchillo Flaqué <aconchillo@gmail.com> skribis: > > > On Wed, Dec 19, 2018 at 10:14 AM Aleix Conchillo Flaqué > > <aconchillo@gmail.com> wrote: > >> > >> My guess is that most of the time people build objects with JSON so it > >> seems logic to map them to the most convenient way to represent that > >> in Scheme which would be alists. > >> > >> So, I'm really considering switching to alists for objects and vectors > >> for arrays. > >> > > > > This would be it: > > > > https://github.com/aconchillo/guile-json/commits/switch-to-alist-and-vectors > > This seems to affect ‘scm->json’ (essentially returning to what we had > in 1.x, except for arrays) but not ‘json->scm’ right? > For scm->json yes, we go back to what we had before except for arrays (now you need vectors). For json->scm the change is that it does't return a hash-table for objects anymore but an alist. Also, for arrays it returns vectors instead of lists. That's probably the biggest change for the user, but should be very easy to port. Aleix ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-20 18:09 ` Aleix Conchillo Flaqué @ 2018-12-29 23:51 ` Aleix Conchillo Flaqué 0 siblings, 0 replies; 23+ messages in thread From: Aleix Conchillo Flaqué @ 2018-12-29 23:51 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-user On Thu, Dec 20, 2018 at 10:09 AM Aleix Conchillo Flaqué <aconchillo@gmail.com> wrote: > > On Thu, Dec 20, 2018 at 2:59 AM Ludovic Courtès <ludo@gnu.org> wrote: > > > > Aleix Conchillo Flaqué <aconchillo@gmail.com> skribis: > > > > > On Wed, Dec 19, 2018 at 10:14 AM Aleix Conchillo Flaqué > > > <aconchillo@gmail.com> wrote: > > >> > > >> My guess is that most of the time people build objects with JSON so it > > >> seems logic to map them to the most convenient way to represent that > > >> in Scheme which would be alists. > > >> > > >> So, I'm really considering switching to alists for objects and vectors > > >> for arrays. > > >> > > > > > > This would be it: > > > > > > https://github.com/aconchillo/guile-json/commits/switch-to-alist-and-vectors > > > > This seems to affect ‘scm->json’ (essentially returning to what we had > > in 1.x, except for arrays) but not ‘json->scm’ right? > > > > For scm->json yes, we go back to what we had before except for arrays > (now you need vectors). > > For json->scm the change is that it does't return a hash-table for > objects anymore but an alist. Also, for arrays it returns vectors > instead of lists. That's probably the biggest change for the user, but > should be very easy to port. > These changes are now ready here: https://github.com/aconchillo/guile-json/tree/switch-to-alist-and-vectors I'm planning to release guile-json 3.0.0 today or tomorrow unless someone has any other comment. Best, Aleix ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-18 16:45 ` Ludovic Courtès 2018-12-18 18:09 ` Aleix Conchillo Flaqué @ 2018-12-18 23:48 ` rain1 2018-12-19 15:18 ` Arne Babenhauserheide 1 sibling, 1 reply; 23+ messages in thread From: rain1 @ 2018-12-18 23:48 UTC (permalink / raw) To: guile-user On 2018-12-18 16:45, Ludovic Courtès wrote: > Hello! > > Thanks for the new release! > > Aleix Conchillo Flaqué <aconchillo@gmail.com> skribis: > >> I was also thinking to look at "reader macros" > > I’d recommend against that: reader macros are global, so they could > clash with unrelated bits of code, they are non-standard, and they > often > don’t buy you much. > > There are cases where having a shorthand, like #' or #~ in Guix makes a > real difference, but for a dictionary data type, you could do with a > regular macro. > > Ludo’. There is no need for a macro, just a regular function that turns a s-exp into a hash table. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: guile-json 2.0.0 released 2018-12-18 23:48 ` rain1 @ 2018-12-19 15:18 ` Arne Babenhauserheide 0 siblings, 0 replies; 23+ messages in thread From: Arne Babenhauserheide @ 2018-12-19 15:18 UTC (permalink / raw) To: rain1; +Cc: guile-user [-- Attachment #1: Type: text/plain, Size: 809 bytes --] rain1@airmail.cc writes: > On 2018-12-18 16:45, Ludovic Courtès wrote: >> Aleix Conchillo Flaqué <aconchillo@gmail.com> skribis: >>> I was also thinking to look at "reader macros" >> >> I’d recommend against that: reader macros are global, so they could >> clash with unrelated bits of code, they are non-standard, and they >> often don’t buy you much. > > There is no need for a macro, just a regular function that turns a > s-exp into a hash table. From my current experience with Scheme this can be generalized: The least powerful method which fulfills your need (without too much overhead) is typically the right one. I was very surprised to realize that with Java this is often different. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1076 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2018-12-29 23:51 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-12-13 5:18 guile-json 2.0.0 released Aleix Conchillo Flaqué 2018-12-13 14:30 ` Thompson, David 2018-12-13 16:35 ` John Cowan 2018-12-13 16:56 ` Thompson, David 2018-12-13 17:09 ` John Cowan 2018-12-13 17:33 ` Thompson, David 2018-12-13 18:28 ` John Cowan 2018-12-13 22:48 ` Aleix Conchillo Flaqué 2018-12-14 1:03 ` Aleix Conchillo Flaqué 2018-12-14 2:28 ` John Cowan 2018-12-18 16:45 ` Ludovic Courtès 2018-12-18 18:09 ` Aleix Conchillo Flaqué 2018-12-19 10:48 ` Ludovic Courtès 2018-12-19 18:14 ` Aleix Conchillo Flaqué 2018-12-19 19:17 ` rain1 2018-12-19 20:05 ` John Cowan 2018-12-19 21:13 ` Ludovic Courtès 2018-12-20 9:34 ` Aleix Conchillo Flaqué 2018-12-20 10:59 ` Ludovic Courtès 2018-12-20 18:09 ` Aleix Conchillo Flaqué 2018-12-29 23:51 ` Aleix Conchillo Flaqué 2018-12-18 23:48 ` rain1 2018-12-19 15:18 ` Arne Babenhauserheide
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).