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 John Cowan 10 Nov 2015 13:58 UTC

Taylan Ulrich Bayırlı/Kammer scripsit:

> 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.

I'm going with that too for SRFI 128.  The sample implementation
assumes that reducing mod 2^20 is better than taking the risk of
overflow into a flonum, but that's only one possible way to do it.

> SRFI-126 hash functions are now fully equivalent to R6RS hash functions
> again, unless I'm forgetting something.

Right.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
You're a brave man! Go and break through the lines, and remember while
you're out there risking life and limb through shot and shell,
we'll be in here thinking what a sucker you are!    --Rufus T. Firefly