xxxxxx@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> It's not that existing implementations of hash functions don't take seed
> arguments.  It's that existing implementations of hash tables don't pass
> seed arguments to hash functions.
>
> There is no lazy "surface-only" fix to that, AFAICT; it will require
> changes to the core of an implementation's hash table implementation,
> e.g. scm_hash_fn_get_handle in hashtab.c of libguile.
>
> Compare that to my SRFI-126 implementation for Guile which is purely a
> Scheme module.

(s/seed/salt/ on that.)

Actually, I figure the Scheme glue layer may handle the salting, passing
salts to hash functions given to the SRFI-126 API, and stripping them
away again in the SRFI-126 built-in hash functions before calling the
native hash functions.

So it should at least be possible to implement a conformant SRFI-126
implementation, although it won't cooperate as well with a Scheme
implementation's native hash salting strategy.  Using the hash functions
of such an SRFI-126 implementation may make the fact that they ignore
the given salt become apparent to the user.  I haven't thought much
about this yet but I worry it might lead to weird problems.

I prefer to stick with the risk-free and more conventional strategy for
now.

Taylan