tl;dr: Let's remove the bounds argument, specify the

full range of fixnums (including negative), and also

include a seed argument.

SRFI 69 provided optional and ill-specified bounds

arguments to hash functions.  R6RS removed these

entirely, with the argument that you could never create

a hash table which needed more than non-negative

fixnum buckets.

This assumption is plainly wrong as it depends on the

actual range of fixnums.  To be clear, any implementation

will have various limits, which is fine.  What makes

hash functions special is that they form a contract

interacting with the hash table size limit, a contract

which is exposed to third parties who can write their

own hash functions.  The concern then is that we could

inadvertently make it _impossible_ to write a hash table

implementation which supported certain hash tables

which would otherwise be possible, i.e. we could be

forcing an artificial upper bound.

Hash tables are closely tied to the core Scheme runtime

since we provide eq?-tables, so right away we can

assume some freedom in tagging size.  Arguably 1 bit

tags are not practical in many cases, but a majority of

Schemes use 2 bits, so let's take that as a minimum,

despite the fact that some non-toy implementations use

3 bits (contrary to my previous claim that these 3-bit

implementations mattered).  We then calculate, using

open-addressing and immediate objects for both keys

and values that we've consumed all memory, leaving

no room for the program, much less the runtime.

This is still not the end of the story.  Hash functions

have a wide variety of uses in and of themselves,

outside of hash tables, and if we're specifying them

at all we should do it right.  Pretty much all of these

uses are well addressed by my (separate) proposal

to provide seeds as arguments to the hash functions.

This lets us turn a hash function into a family of hash

functions.  For simple cases like distributed and

disk-based hash tables which want for double or

quadruple the addressing space, it lets us combine

2 or 4 hashes to get a larger value.

There is one very simple other case, though, which

is the hash set.  For this case we need store only

keys, so we exceed the non-neg fixnum range with

1/2 of memory left to spare.  Chaining hash functions

for this is clumsy, but we can fix this again by removing

the restriction that hash functions return non-negative

values.  Note this is consistent with Java hash functions

which also return negative values (though Java is

crippled by the fact that the values (and all indices)

are 32 bits, even on 64 bit systems).

Similar to hash sets we can consider optimistic

homogeneous typing, i.e. if all values fit in a u8 or

u16, we can store them in more compact uniform

vectors.  Again, using non-negative fixnums solves

this problem.

64-bit systems and beyond actually make this less

of a problem, since the number of bits used for tagging

remain the same, but the amount of space needed to

store the keys increases.  Going in the other direction,

16-bit systems _would_ have a hard limit well below

they ran out of memory, but that's already a specialized

environment these days.

But I'm serious about the seed arguments.

-- 

Alex