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

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> Returns a global and constant salt value for use in hash functions.
>> This is a random value for every run of the program,
>
> This forbids a particularly paranoid implementation from using a
> distinct salt for each hash table and storing it with the hash table.
> I've made several tries at rewording to allow this use case, but I
> can't think how to put it.

Hash-salt is for authors of custom hash functions.  An implementation
can do what it wants for its standard hash functions and hash tables.
An author of custom hash functions can also use their own salting
strategy instead of using hash-salt, though they should obey
SRFI_126_HASH_SEED if they don't want to annoy their users.

I think it's really unnecessary to define a protocol between hash tables
and custom hash functions so that a custom hash function can be used
with salts passed by the hash table, for all the reasons that were
already discussed in length.

>> except when the environment variable `SRFI_126_HASH_SEED` is set to
>> a non-empty string before program startup.
>
> I think this part should be left up to implementations.  In any case,
> it's not clear what its force is: does this make the salt constant,
> or the result of converting to the string to an exact integer, or what?

Think of hash-salt as a utility procedure that saves custom hash
function authors from repeating something like

  (let ((seed (get-environment-variable "SRFI_126_HASH_SEED")))
    (if (and seed (not (string=? "" seed)))
        (string-hash seed)
        (random)))

every time to get a SRFI_126_HASH_SEED obeying salt.

Taylan