From: taylanbayirli@gmail.com (Taylan Ulrich B.)
To: Panicz Maciej Godek <godek.maciek@gmail.com>
Cc: guile-user <guile-user@gnu.org>
Subject: Re: guile-json 0.2.0 released
Date: Thu, 04 Apr 2013 12:15:47 +0200 [thread overview]
Message-ID: <871uaqha98.fsf@taylan.dyndns.org> (raw)
In-Reply-To: <CAMFYt2aq_AgnqHj4p9iHYCc4pZ1wNkr348QeQ7rPg_CTFbr_Rg@mail.gmail.com> (Panicz Maciej Godek's message of "Thu, 4 Apr 2013 11:11:41 +0200")
Panicz Maciej Godek <godek.maciek@gmail.com> writes:
> - 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.
From json.org (which is official):
"An object is an unordered set of name/value pairs."
(Object means dictionary/map in JSON terminology.)
I think this is consistent with common expectations from a dictionary
data structure. At least in my experience. Should the ordering be
important, a supplementary key-vector (or list) could be used easily
enough in my opinion; bundling that functionality into hash-tables is
probably not worth it unless it is trivial to implement.
> - 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.
That is not what homoiconicity means. There are more data types that
lack a proper external representation; most notably procedures. For
transmission of data, converting to an alist and back is probably good
enough; this can also be used as a "hack" for having "literal"
dictionaries in code: (alist->dictionary '(...))
So again, this is probably nothing that needs be implemented urgently.
> - 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)
SRFI-105 is probably the preferable solution to this problem, since it's
an SRFI. Guile already supports it, but I don't know how many accessors
are built-in; it should be trivial to implement any you want though.
> - 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)))
I don't know how exactly hash-tables are implemented in Guile, but one
probably needs to walk through the whole structure to count the size;
then the most efficient simple implementation of `hash-size' is one
which walks through it only once:
(hash-fold (lambda (key value size) (1+ size)) 0 hash-table)
Other than that, the size could be kept in the internal representation
of the hash-table, but I'm not sure of the pay-offs.
Kind regards,
Taylan :)
next prev parent reply other threads:[~2013-04-04 10:15 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
2013-04-04 10:15 ` Taylan Ulrich B. [this message]
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=871uaqha98.fsf@taylan.dyndns.org \
--to=taylanbayirli@gmail.com \
--cc=godek.maciek@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).