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

evalhook, eval-when



Can anyone help me with how *EVALHOOK* and EVAL-WHEN should operate in
an incrementally compiled Common Lisp ?

ClTl, p321

    "The evaluator is typically implemented as an interpreter that
    traverses the given form recursively; performing each step of the
    computation as it goes. An interpretive implementation is not
    required, however. A permissible alternative approach is for the
    evaluator first to completely compile the form into machine-
    executable code and then invoke the resulting code. This technique
    virtually eliminates incomptibilities between interpreted and
    compiled code, but also renders the `evalhook' mechanism relatively
    useless."

It would be ludicrous to compile a run-time check on the value of
*EVALHOOK* along with every form processed by the compiler. Perhaps one
could have a new declaration, COMPILE-HOOKS, to force this. 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.

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). So POPLOG makes

    (let ((x 1) (y 2))
        (compiler-let ((x 100) (y 200))
        (* (eval-when (compile) (+ x y)) 2)))

produce 600, and

    (let ((x 1) (y 2))
        (compiler-let ((x 100) (y 200))
        (* (eval-when (eval) (+ x y)) 2)))

produce 6.

However, while this interpretation of EVAL-HOOK seems sensible to me, it
may not be what someone who had written the above code would have
expected. Again, PCL gives me grief in this respect - the way it uses
EVAL-WHEN doesn't seem to fit this interpretation.


John Williams,
    University of Sussex, Cognitive Sciences, Brighton, BN1 9QN, England
    Tel - (0273) 606755
    UUCP:     ...mcvax!ukc!cvaxa!johnw
    ARPANET : johnw%uk.ac.sussex.cvaxa@cs.ucl.ac.uk
    JANET     johnw@cvaxa.sussex.ac.uk