Poor SETF, revisited ["yea, me worry"]

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

Uh, George, the problem just can't be laid at the feet of SETF, no
matter what system facilities it uses.
    Date: 29 October 1980 13:25-EST
    From: George J. Carrette <GJC at MIT-MC>
    Subject:  MACROEXPANDED not working with SETF (??)
    .  .  .
    In fact, it is exactly the correct characterization of THE PROBLEM.
    .  . .  SETF is not a user
    defined macro, therefore, why should it be his responsiblity
    to make up for its deficiencies with respect to the attempt
    at memoization? 
That the problem is still more general should have been evident from
the FIND-PROJECTION example, but to help visualize it again, just
imagine redefining the function LAST.  How does one know which of his
many macros might have used such a thing?  Your proposal re SETF -- 
that of never memoizing -- would be a narrow (and very costly!) solution.   
    But you didn't comment on my two suggestions, which would work for 
a rather wide variety of environment changes;  did you understand them?  
Basically they would have the user specify a general "cache" 
invalidation whenever something "dangerous" is done 
  (1) set MACRO-EXPANSION-USE to MACROMEMO, and invalidate via RPLACD
  (2) (MAPTAOMS <invalidate-particular-name>)
Some of the "dangerous" operations can even be mechanically detected, such 
as the case of a defmacro which redefines an existing macro.