(For some reason, I didn't receive Sebastian's message, so I read it
from the archive.)

Modifications that will:

(1) hash functions and moduli

I think I finally get the argument about the problems with hand-picked
modulus.  On the other hand, I still think the current interface is
cleaner than one that picks an arbitrary (albeit big) bound.
Consequently, I modified the reference implementation to use the better
way: using a previously fixed modulus and only wrapping to the requested
range upon output.  (I also fixed the default bound.)

(2) hash function for eq?

I realised that it makes a lot of sense to define a hash function that
is only acceptable for eq?, because it can be implemented very
efficiently -- I'm not talking about the efficiency of hash distribution
but about the efficiency of the operation itself.

The only problem is that I'm not sure which name would be proper for
this function.  I somewhat dislike naming hash functions by equality
functions.  Currently I call it "hash-by-identity", but proposals are
welcome.

(3) getting rid of compatibility names

As the SRFI seems to be drifting further away from any existing
implementation, I decided to heed the call of masses and wipe -put!,
-get and -remove! from the SRFI.  RIP.

Modifications that probably will not:

(4) order dependence of -keys and -values

If one wants to iterate over the mappings of a hash table, there is
ample support for doing so: -walk, -fold and ->alist.  Using -keys and
-values for iterating over mappings is bad because they provide many
ways of getting the results out of sync even when they are formally
guaranteed to be in sync: these include (unintentional) modification of
the hash table between the calls or simultaneously with the calls (in
the presence of threads).  Can somebody see some other reason for -keys
and -values to be in sync in addition to iterating over mappings?

One cannot prevent users from relying on implementation-specific stuff,
but IMO that's not a good reason for guaranteeing a particular behavior
for which one can't see a good use.

Panu

--
personal contact: xxxxxx@iki.fi, +35841 5323835, +3589 85619369
work contact: xxxxxx@ling.helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/