[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile-json 0.2.0 released
Taylan Ulrich B.
Re: guile-json 0.2.0 released
Thu, 04 Apr 2013 12:15:47 +0200
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (berkeley-unix)
Panicz Maciej Godek <address@hidden> 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 --
> 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:
> 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
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
> (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.