[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: LOAD-TIME-EVAL (Version 8)
- To: David N Gray <Gray@DSG.csc.ti.com>, Sandra J Loosemore <sandra%defun@cs.utah.edu>, KMP@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: Issue: LOAD-TIME-EVAL (Version 8)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 27 Jan 89 22:03 EST
- Cc: CL-Compiler@SAIL.STANFORD.EDU
- In-reply-to: <2810748378-9770893@Kelvin>
Date: Wed, 25 Jan 89 13:26:18 CST
From: David N Gray <Gray@DSG.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.
No. This is where the discussion went off the rails. The proposal
already says that interpreters are allowed to multiply evaluate a single
LOAD-TIME-VALUE form. The issue being discussed here is whether interpreters
are required to recognize two LOAD-TIME-VALUE forms as distinct and evaluate
each one separately. A pre-pass is irrelevant to that. For example,
(defmacro load-time-value (form) (list 'quote (eval form))) would be
a valid implementation that always evaluated distinct forms separately.
I just noticed that version 8 directly contradicts itself. It says "in
interpreted code, there is no guarantee as to when evaluation of <form>
will take place" (which I take to mean that it is valid never to
evaluate <form> at all unless a data dependency requires the value of
<form> to be used), but it also says "Implementations must guarantee
that each reference to a LOAD-TIME-VALUE form results in at least one
evaluation of its nested <form>" (which I take to mean that it is
invalid never to evaluate <form> at all).
By the way, although I said that displacing macros never work in Common
Lisp, no one should I imagine that I think displacing LOAD-TIME-VALUE
does not work. LOAD-TIME-VALUE is a special form, not a macro, and
furthermore its action does not depend on the lexical environment.
I prefer to think of the evaluation of LOAD-TIME-VALUE as being similar
to macroexpansion. The only rules for macroexpansion are that a
macroexpansion required by data dependency happens at least once, and
that when COMPILE-FILE is used there aren't any macroexpansions left
over after LOAD time. There is no rule against doing the same
macroexpansion more than once, and there is no rule against caching
macroexpansions.
I don't have time to come up with a precise formulation of the above
idea, but my intuition is that you will find that direction more
fruitful than the direction in version 8 of the proposal, which I think
is trying to constrain the behavior more than is possible within current
Common Lisp implementation techniques.