This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
hjstein@bfr.co.il writes: > Russ McManus <russell.mcmanus@gs.com> writes: > > > Maciej Stachowiak <mstachow@mit.edu> writes: > > > > > russell.mcmanus@gs.com writes: > > > > Why not an arbitrary equality test? > > > > <snip> > > > > I guess we have to support arbitrary equality tests, _and_ a user > > supplied hash function ;^) > > That's what STk does. > Maybe it would be a good thing to copy the STk API if it is good (and/or look at other implementations that provide hash tables). One thought to ponder on API differences: is it useful to have the same hash table accessible using different (hash function, equivalence predicate) pairs per access? The current Guile API allows that, but I am not sure it is particularly more useful than setting these at creation time like many other hashtable implementations do. Not supporting this would make it possible to add special fast paths for eq?/eqv?/equal? hashing if that is needed to retain competitive performance. Then it would be possible to write up an RFI on this along with a sample implementation re-back-ported to Scheme. The only parts you'd need that couldn't be written in portable Scheme would be the hashers (actually probably only the eq? and eqv? ones would need help). One thing that concerns me about this, though, is that it might slow down the common cases of eq? and equal? hashing (I imagine someone who cares about hashing by bignums might be using eqv? hashing too). - Maciej Stachowiak