eval-when [former subject evalhook, eval-when]

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

    Date: Fri, 6 Mar 1987  13:24 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

	Now for EVAL-WHEN. The problem here is that the concepts of COMPILE,
	LOAD, and EVAL phases don't apply in an incrementally compiled Lisp -

    Yes, there are major problems with the specification of EVAL-WHEN.
    The compiler cleanup committee is currently working on this, but we
    probably can't offer a great deal of help since the only proposal that
    deals with these problems advocates flushing EVAL-WHEN and replacing
    it with new special forms.

    Although Moon presumably knows the ancestral meaning of EVAL-WHEN, 

In fact I was working from your proposal for the semantics of compilation
when I said what I said (of course keeping the name EVAL-WHEN since we're
discussing Common Lisp as it is today, not as it might be after it's
cleaned up in various ways).  In other words, the distinctive thing about
COMPILE-FILE is early evaluation and late evaluation taking place in
different Lisp worlds, not anything about representation of programs as
executable machine instructions.

								       I
    don't agree with his interpretation of it on the basis of dumping to
    files.  The rules for evaluation should exist independently of any
    semantics of COMPILE-FILE.

In general that's true, but certainly the rules for evaluating EVAL-WHEN
are intimately connected with the semantics of COMPILE-FILE.

    My current opinion that there are only three EVAL-WHEN situation
    lists that can be used in portable code:
	 (compile load eval)
	 (load eval)
	 (compile eval)
    The reason for this restriction is that other situation lists allow
    programs to "tell the difference" between a compiled and an interpreted
    implementation.

    Given that only these situation lists are used, a compile-only system
    can entirely ignore the EVAL situation, and interpret COMPILE as "do
    it now" and LOAD as "do it eventually."  In any situation where the
    EVAL-WHEN body is not evaluated, the result of the EVAL-WHEN is NIL.

I agree with this, for a strong definition of "portable code" as code
that will execute identically in all implementations.  A somewhat
weaker, but still extremely useful, definition of "portable code" as
code that will execute correctly in all implementations allows for
other situation lists.  For example, (eval-when (compile) ...) is
a portable way to get a compile-time-only definition, in systems where
that concept is meaningful; programs that use this can be written in
such a way that they work correctly in all systems.