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:09 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