hash function bounds summarized
Alex Shinn
(25 Nov 2015 23:16 UTC)
|
Re: hash function bounds summarized taylanbayirli@xxxxxx (26 Nov 2015 09:30 UTC)
|
Re: hash function bounds summarized
John Cowan
(27 Nov 2015 08:01 UTC)
|
Re: hash function bounds summarized
Alex Shinn
(30 Nov 2015 23:38 UTC)
|
Re: hash function bounds summarized
John Cowan
(30 Nov 2015 04:26 UTC)
|
Re: hash function bounds summarized
Shiro Kawai
(30 Nov 2015 04:52 UTC)
|
Re: hash function bounds summarized
Alex Shinn
(30 Nov 2015 23:45 UTC)
|
Re: hash function bounds summarized
Alex Shinn
(30 Nov 2015 23:23 UTC)
|
Re: hash function bounds summarized taylanbayirli@xxxxxx 26 Nov 2015 09:30 UTC
Alex Shinn <xxxxxx@gmail.com> writes: > tl;dr: Let's remove the bounds argument, specify the > full range of fixnums (including negative), and also > include a seed argument. I'm pondering on whether allowing negative return values from hash functions would realistically break backwards compatibility or cause other issues. So far I think, since the return value is normally passed to 'modulo' anyway, a negative return value won't break anything. Are there implementations (of e.g. R6RS hashtables) where this isn't the case? Can anyone think of any not-only-theoretical issues? Re. seed arguments, I wonder if they can be specified separately in a backwards compatible way with R6RS/SRFI-126, without SRFI-126 needing to even mention them. SRFI-126 promises only that: 1. it will call hash functions given to its API with only one argument, and 2. the standard hash functions defined by it accept one argument. However, 1. nobody's stopping one from giving it functions that accept additional optional arguments, and 2. (unlike in R6RS) the standard hash functions aren't mandated to signal an error if given more arguments. So I believe it should be possible for a future standard to mandate the standard hash functions to accept additional optional arguments, and specify an API where hash functions are mandated to accept more than one argument, but if all but the first argument are made optional then those functions can be passed to the SRFI-126 API just as well. Would this work? Am I missing something? My intent is to keep SRFI-126 simple, similar to R6RS, corresponding to existing implementation practice, and so on. If a future standard can specify extensions to it without burdening all SRFI-126 implementors, some of which might not care about those extensions, then I think that would be ideal. Taylan