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 09 Nov 2015 22:35 UTC

William D Clinger scripsit:

> SRFI 126 removes one prominent flaw in SRFI 69 (exposure of hash
> functions compatible with the eq? and eqv? procedures) but preserves
> an even more prominent flaw: the requirement that all hash functions
> accept a second optional argument.

The preceding discussion, plus your message, made me go back and examine
the question more closely.  In fact, SRFI 69 does *not* require this,
except of the four exposed and implementation-provided functions `hash`,
`string-hash`, `ci-hash`, and `hash-by-identity`.  User hash functions
are constrained only by the definition of "hashing" given in the section
of the same name.

What is a vexatious interoperability problem is that the *reference
implementation* insists on passing two arguments to all hash functions,
by whomever written.  So any user of SRFI 69 on Chicken or Chibi or
MIT Scheme (which may or may not use the reference implementation, but
in this respect does the same thing) who has written a hash function,
necessarily has written it to accept a second argument.  I'm not sure
how large a body of practice this is, but it's not zero.  Other SRFI 69
implementations don't seem to do this, fortunately.

(more later, hopefully)

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
A poetical purist named Cowan                   [that's me]
Once put the rest of us dowan.                  [on xml-dev]
"Your verse would be sweeter / If it only had metre
And rhymes that didn't force me to frowan."     [overpacked line!] --Michael Kay