Email list hosting service & mailing list manager

hash functions should not be required to accept two arguments William D Clinger (09 Nov 2015 17:42 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 William D Clinger (10 Nov 2015 13:50 UTC)
Re: hash functions should not be required to accept two arguments taylanbayirli@xxxxxx (10 Nov 2015 14:27 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 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