John Cowan <xxxxxx@mercury.ccil.org> writes:

> Here's my current proposal.  Add two procedures `hash-bound` and
> `hash-salt` to the SRFI 125 and 126 APIs.  The first returns an upper
> bound on the result returned by a hash function; the second returns a
> salt value for the hash function to take into account.
>
> It is an error to call either procedure except from a hash function being
> invoked by a hash table operation.  However, hash functions are free not
> to call these procedures, or to ignore what they return.  Therefore there
> is no guarantee that the value returned by the hash function is either
> bounded or salted.  The framework guarantees that the procedures will
> return meaningful values in all cases.
>
> (Perhaps this means that `hash-bound` should be allowed to return #f if
> the framework has nothing to say about bounds.  Alternatively, it can
> just return some large fixnum.)

Hmm, that's an interesting idea, but I'm not sure if it solves the
problem.  If I have existing hash function H which does not call
hash-salt, and now a hash table library tries to derive H2 from it by
wrapping it in a 'parameterize' for hash-salt, that won't work very
well, or will it?  It would be better for the library to call H with the
extra salt argument and cause a fast failure when H doesn't accept it.

Taylan