On Sat, Dec 26, 2015 at 11:12 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote:

I'm going to claim that bounds aren't really necessary for hash functions;
a hash function should simply strive to return a number in the range from
0 to the largest conceivable number of elements in a data structure,
which is what SRFI 69 says hash functions should do if they don't have
a bound argument.  Obviously, that's implementation-dependent, and
so I suggest that it be made available as the value of the function
(hash-default-bound).  This eliminates any need to pass it to an
individual hash function.

Performance matters, so make this syntax.  A likely idiom
for performance conscious 3rd-party hash functions might

  (define my-hash
    (if (fixnum? (hash-default-bound))
        (lambda (obj) ... hash w/ fixnum arith ...)
        (lambda (obj) ... hash w/ general arith ...)))

Regarding using the sign of an optional bound argument as
a semantic toggle, I agree with Taylan.  We should be removing
warts, not adding new ones.  Not even in the core language did
we do anything so strange in the name of backwards compatibility.
Why the sudden obsession with compatibility at the expense of
clean design just for hash tables?