EVAL-WHEN

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: 1 Apr 86 09:14:00 EST
    From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>

    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 
    definition:

    (EVAL-WHEN (LOAD)
    (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
everything.

    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.

See below.

    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
in order.