unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Panicz Maciej Godek <godek.maciek@gmail.com>
To: "Aleix Conchillo Flaqué" <aconchillo@gmail.com>
Cc: guile-user <guile-user@gnu.org>
Subject: Re: guile-json 0.2.0 released
Date: Thu, 4 Apr 2013 11:11:41 +0200	[thread overview]
Message-ID: <CAMFYt2aq_AgnqHj4p9iHYCc4pZ1wNkr348QeQ7rPg_CTFbr_Rg@mail.gmail.com> (raw)
In-Reply-To: <CA+XASoXvcVNDFzgKWX+t0biedyDNLji0nHqzkVRumr5TPBBT-Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]

Hi!
I'm glad that you've made a great piece of work to integrate guile with the
rest of the world. I see you implemed it using guile's hash tables and
lists, which seems sound.
The problem lies within the way guile deals with hash tables. Actually,
there are several problems that need to be addressed:

- firstly, guile's hash tables are maps, not dictionaries, so they are
insensitive to order. This behaviour is desired if we want to use them to
represent sets or maps; however, PHP arrays, and -- as I presume --
JavaScript objects -- store the information about the order of their
elements. Lisp-style sollution would be to store them as assoc lists, which
in turn have linear access time.

- secondly, there is no default notation to create hash tables nor sets;
using them forces
a programmer to drop homoiconicity, as their default print representation
is #<hash-table 1c8a940 1/31> or something even uglier. I think that this
is done properly in Clojure.

- thirdly, refering to hashes (as well as assoc lists, goops' object slots,
vector/array elements) is truly cumbersome. I once wrote a
hash-read-extension that allowed to refer to hashes/arrays/slots... using
uniform notation #[object key], and to allow for nested references like #[
... #[#[object key1] key2 ] ... ] using simpified notation #[object : key1
: key2 : ... ]. The implementation is rather inefficient when it comes to
performance, but makes coding much more efficient, and it can be found
here, if anyone's interested:
https://bitbucket.org/panicz/slayer/src/33cf0116da95dea6928ab1011994569b5a5181ad/extra/ref.scm?at=goose-3d
One could ask: why can't vectors, arrays, objects and hashes simply be
applicable? (Of course, it is possible to implement applicable collections
even now, but at a cost of loosing their print representation)

I think the issue with applicable goops objects emerged before, when
someone wanted to implement python in guile, and wanted to provide a
__call__ metod.

- lastly, guile's support for hash tables is limited -- there ain't even a
built-in function that would return the size of a hash-table. My
implementation is inefficient (linear time), and it looks like this:
(define (hash-size hash-map)
  (length (hash-values hash-map)))

Some time ago I saw here someone who was using the print representation of
a hash-table to read the number of its elements, but it seems like a nasty
hack, and it stopped working once the print representation changed.

Sorry if I was a little off topic :)
Be the avant-garde!
M.

[-- Attachment #2: Type: text/html, Size: 3147 bytes --]

  reply	other threads:[~2013-04-04  9:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-02  7:08 guile-json 0.2.0 released Aleix Conchillo Flaqué
2013-04-04  9:11 ` Panicz Maciej Godek [this message]
2013-04-04 10:15   ` Taylan Ulrich B.
2013-04-04 12:06     ` Panicz Maciej Godek
2013-04-04 22:21       ` Taylan Ulrich B.
2013-04-04 22:59         ` Aleix Conchillo Flaqué
2013-04-05  7:35           ` Panicz Maciej Godek
2013-04-04 23:39         ` Daniel Hartwig
2013-04-07 11:40         ` Panicz Maciej Godek
2013-04-07 20:38           ` Taylan Ulrich B.
2013-04-08  1:51             ` Daniel Hartwig
2013-04-08  2:11           ` Daniel Hartwig
2013-04-05  0:17       ` Daniel Hartwig
2013-04-05  2:47         ` Noah Lavine
2013-04-05  9:35           ` Daniel Hartwig
2013-04-05 13:18             ` Noah Lavine
2013-04-05  9:41         ` Panicz Maciej Godek
     [not found]     ` <CAPjoZodAaHLfPGb+XiUhoMJD7J4_kYrjRmYP+p1S5w5yuPgLEg@mail.gmail.com>
     [not found]       ` <CAPjoZoc12W4usGnkwSZG2zNqe8xF6C4hWWZgq+-Nc8HMg_Xw4Q@mail.gmail.com>
2013-04-04 15:11         ` Nala Ginrut

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=CAMFYt2aq_AgnqHj4p9iHYCc4pZ1wNkr348QeQ7rPg_CTFbr_Rg@mail.gmail.com \
    --to=godek.maciek@gmail.com \
    --cc=aconchillo@gmail.com \
    --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).