[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

    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.

    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

    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.