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 14:26 UTC

Alex Shinn <xxxxxx@gmail.com> writes:

>     > The keys could be fixnums. Since we can use negative fixnums
>     > we already have more possible keys than the maximum number
>     > of buckets.
>
>     That's a consequence of SRFI 126's arbitrary restriction of hash
>     values to non-negative integers.
>
> This is the same restriction in R6RS, libraries section 13.1:
>
> Hash-function should accept a key as an argument and
> should return a non-negative exact integer object.

Oh, so it wasn't my mistake after all.  (It's a pain having hash
functions defined in three separate places in the specification...)

Now I'm conflicted on whether to lift that limitation in SRFI-126.  What
does everyone think?

It sort of breaks backwards compatibility since code written for R6RS
might rely on equal-hash/etc. returning a non-negative integer.  I'll
add the limitation back into SRFI-126 for now.

If anyone has a strong opinion on that the limitation should be lifted,
please say.

Taylan