[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: LOAD-TIME-EVAL, Sub-Issue: Displacing macros
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue: LOAD-TIME-EVAL, Sub-Issue: Displacing macros
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Thu, 26 Jan 89 10:26:31 CST
- Cc: CL-Compiler@SAIL.Stanford.EDU
- In-reply-to: Msg of Thu, 26 Jan 89 08:54 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Sender: GRAY@Kelvin.csc.ti.com
> That leaves only system displacement. And I've always felt displacement was
> so controversial that no user base would put up with it simply being dumped
> on them. Rel6 of Symbolics Genera decided to displace just a few forms [LET,
> LAMBDA, DO, ...] and it caused massive outcries from customers because it
> broke all kinds of code. Symbolics withdrew the `feature' in Rel7.
> The only way I can imagine people living with it is if they grew up with it,
> but since it's a given that people in other environments didn't grow up with
> it, then most portable code [I suspect] is not ready to deal with it.
We inherited an implementation that uses displacing macros, and it has
caused some problems for a few users, but there haven't been "massive
outcries". I can see, though, that this is probably not the best way to
> But this whole sub-issue aside, all we're really saying is that LOAD-TIME-VALUE
> should not be done by displacing.
But other things can be? I think we should be consistent -- either
displacement is a valid implementation technique or it isn't. I don't see
how the case of evaluating the expression in a LOAD-TIME-VALUE form is
fundamentally different from the more important question of when and how
many times a macro expander is invoked. If your interpreter
implementation does a pre-pass, then you want to do both during the
pre-pass, while a displacing macro implementation would want to use the
same displacement mechanism for both.