MACROEXPANDED not working with SETF (??)

[JONL at MIT-MC (Jon L White)]

The subject line of this note is not the right characterization of the 
problem -- what's going wrong here is that any macro-expansion which
has been "memoized" one way or other may need to be invalidated
by operations other than that of merely redefining the macro.
Thus I think, George, your sense of despair needn't be taken so badly:
    Date: 28 October 1980 18:25-EDT
    From: George J. Carrette <GJC at MIT-MC>
    . . .
    ; Might as well not bother with the MACROMEMO scheme and just have
    ; all macros displace if it isn't going to work in the one of
    ; the most common cases, SETF.
If you had, in fact, been using the MACROMEMO scheme instead of the
MACROEXPANDED scheme, then there would have been a  trivial way to win.  
But more importantly, one has to be able to recognize when a condition has 
occurred which *may concievably* invalidate some macor expansion.   For 
example, consider
   (DEFMACRO PROJECT-IT (X) `(FIND-PROJECTION ,x MAIN-AXIS))
What happens if the value of the global-variable MAIN-AXIS is
changed?  Well, one could just say (|forget-macromemos/|| 'PROJECT-IT),
but in general he may not know what all macros will be affected.
    If MACRO-EXPANSION-USE is set to MACROMEMO, then on can easily and
simply invalidate all "memoized" expansions of all macros  by merely
doing (RPLACD MACROMEMO () ).  The problem is more complex when one is 
using the MACROEXPANDED scheme and doesn't wish to change over to the 
MACROMEMO scheme;  but still he could do 
    (MAPATOMS '(LAMBDA (X) (REMPROP X 'MACROEXPANDED)))
Both of these tactics are somewhat akin to doing (SSTATUS UUOLI),
and I'm sure that if someone wanted to spend a few weeks researching
how to be more selecitve in the unsnapping, it could be done.
   But as Alfred E. Neuman used to say, "Not to worry . . ."