[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: common-lisp@SU-AI.ARPA*Subject*: (setf (not x) y) => (setf x (not y))*From*: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>*Date*: Sun, 20 Jul 86 13:59 EDT

NOT is not one of the special things recognized by SETF (CLtL pg 95++). One theory says that if Y is not NIL, then X must be NIL and the right semantics hold, but if Y is NIL, X could be anything that is not NIL, whereas (not Y) will be T. I claim this is OK, since NOT is for boolean purposes. Anybody could do this via the escape clause on page 97: "Any form for which a defsetf or define-setf-method declaration has been made." However, I believe the spirit of the escape clause is for user forms, not CLtL supplied forms, such as NOT. [Randomness notch goes up. I hope this doesn't detract from the above, which I think is quite reasonable.] In theory the same could be applied to ZEROP. That is, (setf (zerop x) y) => (setf x (if y 0 -1)) This is on the grounds that zerop is trying to test for all bits off and therefore the inverse is all bits one. This, of course, assumes two's complement arithmetic. Section 12.7, page 220, assumes this for the logical operations. Maybe the correct expression for "all bits off" is (not (logtest x -1)), and many people are potentially misusing ZEROP? (BTW, ZEROP isn't in the index.) I'll stop the randomness at this point and not mention 1+. Please consider the first two paragraphs seriously. We can consider the rest seriously only if we adopt the convention for SETF of NOT.

- Prev by Date:
**No need to optimize tail recursion, use infinite virtual stack!** - Next by Date:
**(setf (not x) y) => (setf x (not y))** - Previous by thread:
**get-setf-method takes optional environment argument** - Next by thread:
**(setf (not x) y) => (setf x (not y))** - Index(es):