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 16 Oct 2015 14:01 UTC

John Cowan <xxxxxx@mercury.ccil.org> writes:

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> I just don't see much of an improvement in changing hash function
>> signatures to something entirely novel, when '(obj, [bound]) -> int'
>> works perfectly fine and is familiar for programmers and more compatible
>> with existing implementations.
>
> Even this is problematic, though.  For example, the Larceny implementation
> of SRFI 125 (and R6RS and SRFI 69) does not pass a "bound" argument to a
> hash function.  If one is written to demand such an argument, it will break.
> This is what I mean about a fixed protocol.  If (I say again) the framework
> were able to ask the hash function what arguments it accepts, no problems
> with "bound" or "salt" arguments would arise.

The bound argument is optional in SRFI-126, as explained in the "hash
functions" section.  I think I should clarify that in the specification
of 'make-hashtable' as well though.

Taylan