evalhook, eval-when

[Rob MacLachlan <RAM@C.CS.CMU.EDU>]

    Date: Wednesday, 4 March 1987  15:57-EST
    From: John Williams <johnw%cvaxa.sussex.ac.uk at Cs.Ucl.AC.UK>
    To:   common-lisp at sail.stanford.edu
    Re:   evalhook, eval-when

    [...] I'm tempted to leave *EVALHOOK* and friends out of my Lisp
    (POPLOG Common Lisp) entirely, seeing as they are so obviously
    interpreter-oriented, but then people use them in software that's
    supposed to be portable, eg Portable Common Loops.

Since Common Lisp definitely allows compile-only implementations, it
is entirely within your rights to fail to support evalhook.  A strict
interpretation might require the variables and functions to be
defined, but they wouldn't have to do anything.  For this reason, I
think evalhook should be flushed from the language.  Programs that
require EVALHOOK are broken.

    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 -
    POPLOG operates a READ-COMPILE-EXECUTE-PRINT loop, not a READ-EVAL-PRINT
    loop. The only distinction that can be sensibly made is between having a
    form evaluated 'now' (ie at the time the EVAL-WHEN form is processed) or
    'in due course' (ie when it would have been executed in the normal
    course of events). 

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, 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.

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.

If you believe my EVAL-WHEN rules, then both of your examples are
incorrect, since the "eventual evaluation" of both EVAL-WHEN forms
will be NIL, not a number.

  Rob