Re: evalhook, eval-when

[Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>]

    Date: Wednesday, 4 March 1987  15:57-EST
    From: John Williams <johnw%cvaxa.sussex.ac.uk at Cs.Ucl.AC.UK>

    [...] 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.

A key question here is whether Common Lisp requires that the environment
obtained via the &ENV parameter of a macro can meaningfully be passed to
EVALHOOK and vice-versa.  This seems to be what's going on in things like
PCL.  If this is allowed, then EVALHOOK still has a use of sorts even if
hook functions per se are never called.  Of course, we might also ask
whether this *should* be allowed.

In any case, POPLOG Common Lisp might still have some use for hook
functions.  While it would probably be going too far to compile a
check along with each form, it might make sense to check on function
calls.  In some call implementations, this check could be in the
"link" routine and hence wouldn't mean compiling extra code.  As
a user of POPLOG Common Lisp, I often wish there was a single stepper
of some sort, even if it didn't see forms "smaller than function calls".

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

Naively, I would expect the following interpretations of EVAL-WHEN
"times" in a "compiling EVAL" Common Lisp:
	EVAL -- when a source file is being loaded.
	LOAD -- when a compiled file is being loaded.
	COMPILE -- when a file is being COMPILE-FILE'd
That is, the compilation that goes on whenever EVAL is called doesn't in
itself count as COMPILE-time.  I think this means I agree with Moon --
this interpretation is the same as that for an "interpreting EVAL".

So, in addition to the distinction between 'now' and 'in due course', we
can distinguish between "'due course' means 'now'" (EVAL), and "'due
course' means 'later'" (LOAD/COMPILE).

   From: Rob MacLachlan <RAM@edu.cmu.cs.c>
   The rules for evaluation should exist independently of any
   semantics of COMPILE-FILE.

While this seems right in general, the semantics of EVAL-WHEN might
well be considered part of the semantics of COMPILE-FILE.

The existence of COMPILER-LET, however, may cast doubt on the view that
"evaluation times" make sense in a "compiling EVAL" system (or, as a
consequence, in Common Lisp).  If loading a source file is supposed to
obtain the interpreter-like interpretation (sorry for this word over-
loading), it seems that functions defined in this way and containing
calls to COMPILER-LET would have to have the binding of the special
variables in the COMPILER-LET put into their compiled code (as well
as being bound during their compilation) while this should not happen
if the functions were COMPILE-FILE'd.

-- Jeff