Re: Scheme style auto-resizing hashtable (fwd)

[Maciej Stachowiak <mstachow@mit.edu>]

jglascoe@jay.giss.nasa.gov writes:
> primitive: make-dictionaryx [equality-predicate] [hasher-function]
> 
> "equality-predicate" defaults to 'equal?
> 
> as per your suggestion: if "equality-function" is one of 'equal?, 'eqv?,
> eq? then hasher-function defaults to 'my-hasher, 'my-hasherv, 'my-hasherq
> respectively.  Else, both "equality-function" and "hasher-function" must
> be provided.
> 
> One caveat: both arguments must be symbols bound to procedures or
> primitives available to the current scope.  So, e.g. 

This is evil for a number of reasons:

* Broken in the presense of a module system (a given symbol may have
different bindings in different modules).

* Confusing when you have a local binding shadowing a top-level
binding.

* Anonymous procudures with lexical scope are an essential compenent
of the usefulness of Scheme.

* Dereferencing symbols as variables is a distasteful thing to do in
Scheme; Scheme tries hard to avoid the tight relationship between
symbols and variables found in other Lisps.


I can see why you made the compromise - so that hashtables could
reasonably be readable and writable without any hackery. However, I
don't think this will work. It is perfectly valid for a hash function
to give different hash values at runtime for different invocations of
a guile process - in fact, for the eq? and eqv? cases this is almost
necessary to get useful hashing!

I would suggest that an alist be used as the conventional external
representation for dictionaries, i.e. have the user convert to and
from alists when reading and writing to and from disk or whatever.

 - Maciej