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