[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Poor SETF, revisited ["yea, me worry"]
- To: GJC at MIT-MC
- Subject: Poor SETF, revisited ["yea, me worry"]
- From: JONL at MIT-MC (Jon L White)
- Date: Wed, 29 Oct 80 19:01:00 GMT
- Cc: (BUG LISP) at MIT-MC
- Original-date: 29 OCT 1980 1401-EST
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
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.