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