Re: guile-json 0.2.0 released

[taylanbayirli@gmail.com (Taylan Ulrich B.)]

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