[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue MACRO-CACHING, version 2
- To: firstname.lastname@example.org
- Subject: issue MACRO-CACHING, version 2
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 14 Mar 89 19:57 EST
- Cc: email@example.com
- In-reply-to: <8903131647.AA02151@defun.utah.edu>
I support MACRO-CACHING:DISALLOW. I'd like to point out that the
"correct" way to do macro caching is not mentioned anywhere in this
writeup. Perhaps that was justified because there is no portable way to
do it (an implementation can do it, but a user cannot), however I think
omitting it leaves a false impression.
The "correct" way to do macro caching is via a table inside the lexical
environment structure, which has very different properties from a table
keyed by the lexical environment structure, mentioned in the writeup.
I think a shorter writeup might be better. It could simply say that
there is no correct portable way to use *MACROEXPANSION-HOOK* to cache
macro expansions, and that there is no requirement that an implementation
call the macro expansion function more than once for a given form
and lexical environment. This prohibits the incorrect user code discussed
at some length in the existing writeup, leaves implementations license
to do macro caching correctly, and avoids a lot of unnecessary detail.