hash functions should not be required to accept two arguments William D Clinger 09 Nov 2015 17:25 UTC
Re: hash functions should not be required to accept two arguments John Cowan 09 Nov 2015 22:35 UTC
Re: hash functions should not be required to accept two arguments Alex Shinn 10 Nov 2015 02:44 UTC
Re: hash functions should not be required to accept two arguments John Cowan 10 Nov 2015 05:43 UTC
Re: hash functions should not be required to accept two arguments William D Clinger 10 Nov 2015 12:02 UTC
Re: hash functions should not be required to accept two arguments taylanbayirli@xxxxxx 10 Nov 2015 13:00 UTC
Re: hash functions should not be required to accept two arguments John Cowan 10 Nov 2015 13:58 UTC
Re: hash functions should not be required to accept two arguments William D Clinger 10 Nov 2015 13:50 UTC
Re: hash functions should not be required to accept two arguments Alex Shinn 10 Nov 2015 14:15 UTC
Re: hash functions should not be required to accept two arguments taylanbayirli@xxxxxx 10 Nov 2015 14:26 UTC
Hash salt John Cowan 10 Nov 2015 06:37 UTC
Re: Hash salt taylanbayirli@xxxxxx 10 Nov 2015 10:00 UTC
Re: Hash salt John Cowan 11 Nov 2015 05:21 UTC
Re: Hash salt Shiro Kawai 11 Nov 2015 05:59 UTC
Re: Hash salt John Cowan 11 Nov 2015 06:22 UTC
Re: Hash salt taylanbayirli@xxxxxx 11 Nov 2015 07:54 UTC
Re: hash functions should not be required to accept two arguments taylanbayirli@xxxxxx 10 Nov 2015 09:58 UTC
Re: hash functions should not be required to accept two arguments John Cowan 11 Nov 2015 05:53 UTC

Re: Hash salt taylanbayirli@xxxxxx 11 Nov 2015 07:54 UTC

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