guile-json 2.0.0 released

guile-json 2.0.0 released

[Aleix Conchillo Flaqué]

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

Re: guile-json 2.0.0 released

[Thompson, David]

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

Re: guile-json 2.0.0 released

[John Cowan]

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

Re: guile-json 2.0.0 released

[Thompson, David]

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

Re: guile-json 2.0.0 released

[John Cowan]

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
>

Re: guile-json 2.0.0 released

[Thompson, David]

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

Re: guile-json 2.0.0 released

[John Cowan]

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
>

Re: guile-json 2.0.0 released

[Aleix Conchillo Flaqué]

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

Re: guile-json 2.0.0 released

[Aleix Conchillo Flaqué]

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

Re: guile-json 2.0.0 released

[John Cowan]

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"

Re: guile-json 2.0.0 released

[Ludovic Courtès]

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’.

Re: guile-json 2.0.0 released

[Aleix Conchillo Flaqué]

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

Re: guile-json 2.0.0 released

[rain1]

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.

Re: guile-json 2.0.0 released

[Ludovic Courtès]

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’.

Re: guile-json 2.0.0 released

[Arne Babenhauserheide]

[-- 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 --]

Re: guile-json 2.0.0 released

[Aleix Conchillo Flaqué]

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

Re: guile-json 2.0.0 released

[rain1]

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.

Re: guile-json 2.0.0 released

[John Cowan]

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)))))))))

Re: guile-json 2.0.0 released

[Ludovic Courtès]

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’.

Re: guile-json 2.0.0 released

[Aleix Conchillo Flaqué]

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

Re: guile-json 2.0.0 released

[Ludovic Courtès]

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’.

Re: guile-json 2.0.0 released

[Aleix Conchillo Flaqué]

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

Re: guile-json 2.0.0 released

[Aleix Conchillo Flaqué]

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