This page is part of the web mail archives of SRFI 69 from before July 7th, 2015. The new archives for SRFI 69 contain all messages, not just those from before July 7th, 2015.
(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: atehwa@xxxxxx, +35841 5323835, +3589 85619369 work contact: pkalliok@xxxxxxxxxxxxxxxx, +35850 3678003 kotisivu (henkkoht): http://www.iki.fi/atehwa/ homepage (technical): http://sange.fi/~atehwa/