hash functions should not be required to accept two arguments William D Clinger 09 Nov 2015 17:25 UTC
Re: hash functions should not be required to accept two arguments John Cowan 09 Nov 2015 22:35 UTC
Re: hash functions should not be required to accept two arguments Alex Shinn 10 Nov 2015 02:44 UTC
Re: hash functions should not be required to accept two arguments John Cowan 10 Nov 2015 05:43 UTC
Re: hash functions should not be required to accept two arguments William D Clinger 10 Nov 2015 12:02 UTC
Re: hash functions should not be required to accept two arguments taylanbayirli@xxxxxx 10 Nov 2015 13:00 UTC
Re: hash functions should not be required to accept two arguments John Cowan 10 Nov 2015 13:58 UTC
Re: hash functions should not be required to accept two arguments William D Clinger 10 Nov 2015 13:50 UTC
Re: hash functions should not be required to accept two arguments Alex Shinn 10 Nov 2015 14:15 UTC
Re: hash functions should not be required to accept two arguments taylanbayirli@xxxxxx 10 Nov 2015 14:26 UTC
Hash salt John Cowan 10 Nov 2015 06:37 UTC
Re: Hash salt taylanbayirli@xxxxxx 10 Nov 2015 10:00 UTC
Re: Hash salt John Cowan 11 Nov 2015 05:21 UTC
Re: Hash salt Shiro Kawai 11 Nov 2015 05:59 UTC
Re: Hash salt John Cowan 11 Nov 2015 06:22 UTC
Re: Hash salt taylanbayirli@xxxxxx 11 Nov 2015 07:54 UTC
Re: hash functions should not be required to accept two arguments taylanbayirli@xxxxxx 10 Nov 2015 09:58 UTC
Re: hash functions should not be required to accept two arguments John Cowan 11 Nov 2015 05:53 UTC

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