William D Clinger scripsit:

> There is no reason for clients or implementors of SRFI 126 to think
> (h x 0) has anything to do with (h x 1), and so on.

This reminds me that I'd like you to weigh in on the subject of
hash-function clients being able to supply salt to hash functions to
discourage DoS attacks based on the known behavior of standard hash
functions.  The salt helps to populate the initial state of the hash
algorithm, and is supplied by the framework on a per-process-instance
basis, or more fine grainedly if desired (such as a per-hashtable basis).

This salt could be supplied as yet another argument to the hash function,
or by a parameter that the hash function is free to inspect but not to
mutate (R7RS parameters can't be mutated anyway).  It would be an error
to even inspect this parameter outside a hash function.

Note that user-written hashes need access to the salt too, for we can
often assume that the bad guy has the source of the program.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
If I have seen farther than others, it is because I was looking through a
spyglass with my one good eye, with a parrot standing on my shoulder. --"Y"