seeds Alex Shinn (08 Oct 2015 05:03 UTC)
Re: seeds taylanbayirli@xxxxxx (08 Oct 2015 07:55 UTC)
Re: seeds Arthur A. Gleckler (08 Oct 2015 17:46 UTC)
Re: seeds taylanbayirli@xxxxxx (08 Oct 2015 19:38 UTC)
Re: seeds Arthur A. Gleckler (08 Oct 2015 21:47 UTC)
Re: seeds taylanbayirli@xxxxxx (09 Oct 2015 08:09 UTC)
Re: seeds Kevin Wortman (09 Oct 2015 17:18 UTC)
Re: seeds taylanbayirli@xxxxxx (09 Oct 2015 18:33 UTC)
Re: seeds Kevin Wortman (13 Oct 2015 17:36 UTC)
Re: seeds taylanbayirli@xxxxxx (13 Oct 2015 18:28 UTC)
Re: seeds Alex Shinn (14 Oct 2015 01:59 UTC)
Re: seeds taylanbayirli@xxxxxx (14 Oct 2015 09:17 UTC)
Re: seeds taylanbayirli@xxxxxx (14 Oct 2015 10:06 UTC)
Re: seeds Alex Shinn (16 Oct 2015 01:23 UTC)
Re: seeds taylanbayirli@xxxxxx (16 Oct 2015 13:34 UTC)
Re: seeds Alex Shinn (16 Oct 2015 23:48 UTC)
Re: seeds taylanbayirli@xxxxxx (17 Oct 2015 12:08 UTC)
Re: seeds Alex Shinn (17 Oct 2015 13:12 UTC)
Re: seeds taylanbayirli@xxxxxx (17 Oct 2015 14:09 UTC)
What SRFIs are for John Cowan (17 Oct 2015 14:41 UTC)
Re: What SRFIs are for taylanbayirli@xxxxxx (17 Oct 2015 15:56 UTC)
Re: What SRFIs are for John Cowan (17 Oct 2015 16:55 UTC)
Re: What SRFIs are for taylanbayirli@xxxxxx (17 Oct 2015 18:08 UTC)
Re: What SRFIs are for John Cowan (17 Oct 2015 18:51 UTC)
Re: seeds John Cowan (15 Oct 2015 17:49 UTC)
Re: seeds Alex Shinn (09 Oct 2015 02:54 UTC)
Re: seeds taylanbayirli@xxxxxx (09 Oct 2015 07:59 UTC)
Re: seeds John Cowan (15 Oct 2015 17:51 UTC)
Re: seeds taylanbayirli@xxxxxx (15 Oct 2015 23:08 UTC)
Re: seeds John Cowan (16 Oct 2015 13:09 UTC)
Re: seeds taylanbayirli@xxxxxx (16 Oct 2015 14:01 UTC)

Re: seeds taylanbayirli@xxxxxx 14 Oct 2015 10:06 UTC

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