My feeling is still ambivalent, but since there's not much discussion, I'll jump in.

I think John's suggestion is a clever workaround; there's no reason that salt should be a 
positive integer, so let's set it in a range that doesn't conflict existing srfis---makes sense.

On the other hand, it does look like a huge wart that I wish I wouldn't have to see.

How many Scheme implementations are there actually using bound argument?  I mean,
Gauche does support srfi-69, but Gauche's native hashtables don't use bound arg; it always
calls the hash function with one argument.  Our srfi-69 module exports srfi-69 compatible
hash function that does accept optional bound arg, which is just a wrapper of native
hash function.  

If salt is adopted, I'll make use of it in internal hash table, and I'll put wrapper
around hash functions passed to srfi-69 hashtable creation api, that is, 
srfi-69's (make-hash-table equal-fn srfi-69-hash-fn) would wrap srfi-69-hash-fn by 
(lambda (obj salt) (srfi-69-hash-fn obj)) --ignores salt and doesn't pass bound.
It affects performance, but I don't care much; it's just to run libs that uses srfi-69,
but I count on that future libraries uses the newer srfis (that we're discussing)
and I'd rather tune for it instead of caring to-be-obsoleted srfi.   In short, I'd rather
expect a clean API for the new srfis.  (This is only my personal view; I understand
that some would value backward compatibility more, especially if they have large
existing libs that relies on srfi-69 hash api.   I honestly don't know how much such
code are there.)

On Sun, Jan 3, 2016 at 12:26 PM, John Cowan <> wrote:
Alex Shinn scripsit:

> Performance matters, so make this syntax.

I think it's fine for it to be part of trivial compile-time folding.

> A likely idiom
> for performance conscious 3rd-party hash functions might
> become:
>   (define my-hash
>     (if (fixnum? (hash-default-bound))
>         (lambda (obj) ... hash w/ fixnum arith ...)
>         (lambda (obj) ... hash w/ general arith ...)))

Yes, that's plausible.

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

R7RS-small was all about compatibility.  I'm trying to keep the
number of backward incompatible changes for R7RS-large as
small as possible too.

Hash tables are a can of worms, but they have to be opened and
served up somehow.

John Cowan
I must confess that I have very little notion of what [s. 4 of the British
Trade Marks Act, 1938] is intended to convey, and particularly the sentence
of 253 words, as I make them, which constitutes sub-section 1.  I doubt if
the entire statute book could be successfully searched for a sentence of
equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940
To unsubscribe from this list please goto