Re: hash functions should not be required to accept two arguments taylanbayirli@xxxxxx 10 Nov 2015 13:00 UTC
William D Clinger <xxxxxx@ccs.neu.edu> writes: > [...] SRFI 126's arbitrary restriction of hash values to non-negative > integers [...] Oops, I don't think that was ever intended. Thanks for spotting it. >> I haven't run any benchmarks, but I think a simple lookup in a >> hash table should not cons. > > I've run the benchmarks. In Larceny, a simple hash table lookup > costs about 100 times as much as allocating a bignum whose lifetime > is limited to the duration of the lookup. > > You're repeating an ancient mantra that became obsolete with the > advent of generational garbage collection. > > You may say your reasoning still applies to systems that don't > use generational garbage collection, but why would someone who > needs extreme performance (approaching 100% of the address space) > be using a low-performance system? OK, in any case SRFI-126 is now agnostic to the maximum value a hash function can return. User-defined hash functions may return any exact integer, and an implementation may do what it wants for its standard equal-hash and string-hash functions. SRFI-126 hash functions are now fully equivalent to R6RS hash functions again, unless I'm forgetting something. Taylan