[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: John Williams <johnw%cvaxa.sussex.ac.uk@CS.UCL.AC.UK>
- Subject: evalhook, eval-when
- From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
- Date: Fri, 06 Mar 1987 17:24:00 -0000
- Cc: common-lisp@SAIL.STANFORD.EDU
- In-reply-to: Msg of 4 Mar 1987 15:57-EST from John Williams <johnw%cvaxa.sussex.ac.uk at 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>
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)
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.
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.