[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
- To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
- From: masinter.pa@Xerox.COM
- Date: 16 Sep 88 01:43 PDT
- Cc: CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Mon, 12 Sep 88 20:25 EDT
I have a note that there was some discussion on this issue, but I don't see it.
What I think is that this issue doesn't give us much clarification unless we can
pin down what a component is (e.g., "it is an error to modify a component of a
key" doesn't disallow changing the symbol-function of a symbol key, although it
might be considered a "component" of the KEY.
Given that EQUAL is transitive, the operation is that
if before the operation, there is a value B suchthat (EQUAL A B), but after the
operation on A, (EQUAL A B) is false, then you've changed something that GETHASH
cares about wrt EQUAL hash keys.
Should implementations really be free to signal an error or behave otherwise in
an undefined manner when you say (setf (car x) y) if x happens to be a key in a
EQUAL hash table?
I think we can and should be more precise than "is an error" when we can, and
this is such an opportunity. The value of GETHASH on B or A is unspecified after
A is modified if the value of A is a key in the hash table.