Panicz Maciej Godek <[email protected]> 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 :)
