[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Common-Lisp@SU-AI.ARPA
- Subject: EVAL-WHEN
- From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
- Date: Thu, 3 Apr 86 18:23 -EST
- In-reply-to: The message of 1 Apr 86 09:14-EST from "BACH::GREEK" <email@example.com>
Date: 1 Apr 86 09:14:00 EST
From: "BACH::GREEK" <firstname.lastname@example.org>
Mr. Fry has begun our bimonthly discussion of EVAL-WHEN (on April 1,
no less). I think, however, that the case of (EVAL-WHEN (LOAD)
(DEFUN...)) is straightforward. When the book says that "the compiler
should arrange to evaluate the forms in the body when the compiled file
... is loaded", it means that the DEFUN should be evaluated to produce
its effect of stashing a function in the symbol's definition. I don't
think anyone meant to imply that the body of the DEFUN had to be
processed in any particular fashion (e.g., macroexpanding it at load
time). But I'll acknowledge that it's not precisely clear.
I agree with you. EVAL-WHEN is intended to control when the normal processing
of its body is done and is not intended to imply that that processing is done
by the function EVAL. The choice of name is perhaps poor.
If you do want the DEFUN to be processed as if it was entered at
top-level, you might do the following, which will produce an interpreted
(EVAL '(DEFUN ...))
EVAL of a quoted expression is the way I tell people to do it, however
I don't think the Common Lisp language guarantees that the compiler is
not smart enough to figure out what it thought you meant and compile the
defun anyway. In fact I know of no way that is guaranteed to produce an
interpreted definition. Perhaps this is good, since I believe there are
some implementations that don't have an interpreter, but simply compile
A related question is what to do with other sorts of top-level forms,
not DEFUNs or DEFMACROS. Some LISPs have a (perhaps secret) switch
which determines whether the compiler dumps anonymous compiled functions
or dumps the lists and interprets them at load time. There may be
demantic differences resulting from the choice.
A couple of other questions have been asked before and never really
answered. Are EVAL-WHENs allowed down in the guts of a function or
macro and what do they mean there?
The discussion on page 66 that everybody hates was intended to rule out
EVAL-WHEN inside the guts of a function or a macro. I cannot think of
a meaningful interpretation of EVAL-WHEN in this position.
Also, would it clarify things if we
acknowledged the fourth EVAL-WHEN situation, that of the compiler
digesting a definition without actually evaluating it? This occurs, for
example, when the compiler sees a DEFMACRO. It doesn't evaluate it per
se, but it does digest it enough to be able to expand future macro calls.
It's not sufficient to say that DEFMACRO is a special case and the
compiler always looks at it, because the compiler doesn't look if it's
wrapped in an (EVAL-WHEN (EVAL) ...). This implies that there is some
secret situation that has been left out of the list.
I don't think this is EVAL-WHEN. EVAL-WHEN controls when the normal processing
would happen. What you are asking for, and I think this is reasonable, is
a way to control what processing happens, rather than when it happens.
A new feature to do this could be wedged into EVAL-WHEN, since obviously
EVAL-WHEN was designed to be extensible, but I'm not sure that's the place
to put it that makes the most sense.
In summary, I see three issues here:
(1) The name of EVAL-WHEN leads to confusion since this special form is
not actually related to the EVAL function. Should this problem be attacked
by changing the name or by documenting it better?
(2) The specification needs to clarify in which positions EVAL-WHEN is
allowed, in which positions it is forbidden, and in which positions it
is up to the implementation. This relates to the issue about the
positions in which DEFUN is allowed.
(3) It would be useful to have a way to turn off the compiler's normal
processing of a form. Some discussion of exactly what this means may be
- From: Guy Steele <gls@THINK-AQUINAS.ARPA>