[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(setf (not x) y) => (setf x (not y))
Date: Sun, 20 Jul 1986 15:16 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
OK, I considered those suggestions as seriously as I could, and to me
they look utterly worthless and needlessly confusing. Unless you can
demonstrate some good use for these constructs that could not be done
much perspicuously and clearly using existing mechanisms, I suggest we
drop this.
Some of this may be tainted by the Symbolics environment, which has
DEFSUBST, which can easily be done in CLtL using PROCLAIM using INLINE
(that's what it actually does), and that SETF "happens to know" that it
should expand inline forms. This makes life a LOT easier, and probably
isn't considered portable CL. Doing it with inline functions is
prefereable to macros, as we shall see. With that as background,
consider this
(defstruct direction
up-p
left-p
front-p)
There are at least two ways to express the inverses. One is to build
them into the defstruct, and the other is to write abstractions that use
the existing slots. If macros were used, we would get
(defmacro direction-down-p (dir) `(not (direction-up-p ,dir)))
If SETF of NOT were to be adopted, it would automatically be possible to
SETF DIRECTION-DOWN-P. As it is, I have to
(defsetf direction-down-p (dir) (down-p)
`(setf (direction-up-p ,dir) (not ,down-p)))
and I have to do that for all of the others.
The reason inline functions are preferable for the standard reason: you
can't funcall macros. Since our substs are effectively macros to the
compiler (with hair to preserve order of evaluation if necessary), SETF
sees them as valid things to macroexpand.
The language should let me easily capture a concept (DIRECTION-DOWN-P)
and shouldn't burden me with a lot of tedious "junk" (DEFSETF of same)
in order to make effective use of it.