[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flush COMPILER-LET?
- To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
- Subject: Re: Flush COMPILER-LET?
- From: email@example.com (Sandra J Loosemore)
- Date: Tue, 27 Sep 88 13:04:38 MDT
- Cc: firstname.lastname@example.org, KMP@stony-brook.scrc.symbolics.com, email@example.com, CL-Compiler@sail.stanford.edu
- In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 27 Sep 88 12:15 EDT
> Date: Tue, 27 Sep 88 12:15 EDT
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> Also, the MACROLET version doesn't deal with the issue of
> side-effects. Offhand I see now way to use MACROLET to simulate a
> situation which uses COMPILER-LET and where a compiler-let variable is
> re-assigned (by SETQ) in a contained macro call. The kind of macro
> where you'd do that would be
> (+ (MY-THE FIXNUM X) (MY-SQRT X)))
> where MY-THE might be like THE, but it could push onto a list of
> declarations maintained by WITH-MY-STICKY-DECLARATIONS so that MY-SQRT
> could be a macro that knew X was a FIXNUM.
This may or may not work anyway, even if COMPILER-LET is used. Our
proposal for DEFINING-MACROS-NON-TOP-LEVEL explicitly states that you
can't depend on subforms being processed in the same order they appear
textually. (This is to allow the compiler to perform certain kinds of
source-to-source transformations.) You can't rely on the MY-THE being
expanded before the MY-SQRT unless you have WITH-MY-STICKY-DECLARATIONS
do its own code walk.