[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: LOAD-TIME-EVAL (Version 8)
- To: email@example.com (Sandra J Loosemore)
- Subject: Re: Issue: LOAD-TIME-EVAL (Version 8)
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Wed, 25 Jan 89 13:26:18 CST
- Cc: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>, CL-Compiler@SAIL.STANFORD.EDU
- In-reply-to: Msg of Tue, 24 Jan 89 20:38:14 MST from firstname.lastname@example.org (Sandra J Loosemore)
- Sender: GRAY@Kelvin.csc.ti.com
> > guess that the most likely route to a solution will involve defining
> > some sort of "tree walk" through the source code, defining the identity
> > of a form as the path taken through the tree to reach that form. I'm
> > guessing that the intuition that the proposal intended to capture is the
> > same thing that this tree walk does.
> Yes, that is pretty much what I had in mind, but I agree it is not
> formally stated. Perhaps a more formal statement would be that you do
> a code walk to expand all macros, then do a COPY-TREE on the resulting
> code, then all the LOAD-TIME-VALUE expressions you end up with would have
> the right uniqueness properties.
In other words, the interpreter would be required to do a pre-pass over the
code. In discussions in other contexts, it seemed that the consensus was
that we did not want to require a pre-pass implementation approach or to rule
out a displacing macros approach. I don't think we want to reverse that
position just to satisfy the fine print in this one feature.
> > Alternatively, you might abandon the intuition and think about the
> > consequences of just using EQ of the LOAD-TIME-VALUE expression. Would
> > it be so bad?
> That's pretty much the alternative I mentioned above, I guess.
This looks like the only viable answer to me.