unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: "Thompson, David" <dthompson2@worcester.edu>
To: John Cowan <cowan@ccil.org>
Cc: Guile User <guile-user@gnu.org>
Subject: Re: guile-json 2.0.0 released
Date: Thu, 13 Dec 2018 11:56:07 -0500	[thread overview]
Message-ID: <CAJ=Rwfb9fhfampsvyQvfEOW8SowYCsT3XknCCVe66tV4vYpouQ@mail.gmail.com> (raw)
In-Reply-To: <CAD2gp_RySU8xCYferq9WGmFmRXDjn6YVjTEASk2eP+jtAvzX-g@mail.gmail.com>

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



  reply	other threads:[~2018-12-13 16:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ=Rwfb9fhfampsvyQvfEOW8SowYCsT3XknCCVe66tV4vYpouQ@mail.gmail.com' \
    --to=dthompson2@worcester.edu \
    --cc=cowan@ccil.org \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).