> This speeds up the common 'retrieve/modify/store'
> and 'if not present, create' idioms.
The second isn't true, since if the entry isn't in the hash table,
this version of the optimization doesn't do anything. I plan to
change it so that the case of a get on a non-present key followed
by a put is also cached.
There was a question on iRC about modifying keys used in hash
table lookups. This can cause nasal demons, so we're allowed
in the implementation to assume that it never happens.
Also, I use EQ for the keys. I assume that any hash table
test that we use has the property that (EQ x y) implies
(<hash table test> x y). This is true for all the standard
hash table tests (EQ, EQL, EQUAL, EQUALP). The converse need
not be true, but that's ok.