Re: hash table question

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 24 Nov 86 17:31:28 MST
    From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)

	Date: Mon, 24 Nov 86 18:39 EST
	From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>

	No, it doesn't always return true.  sxhash is an "equal" hash, returning
	the same value for equal structures, even if they're not eq.

    Fine.  So what happens if the cons I just clobbered was being used as a
    key in an "eq" hash table?  Certainly the original cons is still "eq" to 
    itself after it's been clobbered.  Does this mean that an "eq" hash table
    *can't* look at the contents of an object to compute a hash index?

    (Actually, I can't think of any reason why one would *want* to perform
    destructive operations on an object that is being used as a hash key, and 
    would be happy to see this made "an error".)

Suppose you're doing object-oriented programming, and you're an old-line
Lisp type who didn't make it past chapter 16 of CLtL, so you're
implementing your objects as conses.  Suppose the car of each cons is the
class, while the cdr of each cons is a property-list containing the local
state.  Then it would be quite reasonable to simultaneously use these
objects as :test 'eq hash-table keys and to perform destructive operations
on them.  The hashing, with :test 'eq, is using the object's identity as
the key, not using the object's contents as the key.

Thus I think the answer is that an "eq" hash table must not look at the
contents of an object when it hashes.  This could all be explained a whole
lot better in the manual (although the language on p.282, distinguishing
tables that hash on objects from tables that hash on tree structure, was
probably intended to be the explanation of this.)