[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Macro-Cache'ing a pure cell?
- To: RWK at MIT-MC
- Subject: Macro-Cache'ing a pure cell?
- From: JONL at MIT-MC (Jon L White)
- Date: Sat, 10 Jan 81 11:29:00 GMT
- Cc: (BUG LISP) at MIT-MC
- Original-date: 10 JAN 1981 0629-EST
Date: 9 January 1981 04:00-EST
From: Robert W. Kerns <RWK at MIT-MC>
. . . I changed the case you ignored to conform to the way you
changed the case I ignored. . . . I decided that MACROFETCH looking
at the state of MACRO-EXPANSION-USE is really the wrong thing . . .
There isn't any efficiency lost by doing this, since the check for the
CDR of MACROMEMO being NIL is fast.
Well, (apart from the incredible semantics of the 'changed' sentence!)
your changes had (NOT (WRITEABLEP ...)) where you wanted merely
(WRITEABLEP ...), so I changed that; also, my prior (less desirable)
code there used PUREP (i.e., STATIC-AREAP) which had an AUTOLOAD
property, but WRITEABLEP doesn't, so I've added that too.
But more to the point, I disagree completely with your assumption above,
that MACROFETCH should not look at the MACRO-EXPANSION-USE switch -- that's
precisely why such a switch was invented. If one is in the MACROEXPANDED
mode, then a non-writeable cell simply can't be cached this way, and there's
no reason to switch modes automatically on the user; perhaps giving him a
warning msg would be of interest, so that he could switch to MACROMEMO mode
manually. Really, how important is it to optimize the rare case
of MACROEXPANDED mode and non-writeable call cell? (remember, if
a loser has lots of pure EXPR code, he must know what he is doing,
and will be using MACROMEMO mode).
In short, there's verrrry little, if anything, to be gained by
trying to mix modes.