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