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]

Re: Scheme style auto-resizing hashtable



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