Re: eval-when

[Alan Bawden <ALAN at MIT-MC>]

    Date: 14 August 1980 19:06-EDT
    From: Daniel L. Weinreb <DLW at MIT-AI>

        (eval-when (load)
          (eval-when (eval load compile)
            <stuff>))

        Should it evaluate <stuff> at compile time?  

    If this evaluates <stuff> at compile time, I would be very confused.

Well, COMPLR currently DOES evaluate <stuff> at compile time, and my
first reaction was that this is a bug.  It seemed, at first, that the
right thing was for <stuff> to be "evaluted" at those times that were
in the intersection of the times specified by all surrounding
eval-whens.  But consider:

(eval-when (compile)
  (eval-when (eval)
    <stuff>))

When COMPLR sees the outer eval-when, it calls EVAL to process the
rest of the stuff.  Then EVAL sees the inner eval-when and, sure
enough, it's now EVAL-time so <stuff> gets evaluated!  This has
nothing to do with the intersection of anything, and it seems to be
the correct behavior, since the name of the thing is "EVAL-when"!  (It
also does the correct thing with respect to macrology that might
expand into an (eval-when ...).  The macrology wants to know if the
stuff is going to be run interpreted or compiled, and the surrounding
(eval-when (compile) ...) is there to cause the stuff to be run
interpreted (in the compiler).)

The problem with (eval-when (load) ...) is that it in effect says (to
the compiler): "continue to process the stuff in here, just as you
would normally".  Where what you sometimes want to do is turn off
inner (eval-when (compile) ...)s.  For example, suppose you had a
macro that expanded into a bunch of putprops all wrapped up in a
(eval-when (eval compile load) ...).  If, for some reason, you decided
that in just this one case you wanted different properties at compile
and load time, then you might call the macro in two different places,
once surrounded by an (eval-when (compile) ...) and once surrounded by
an (eval-when (load) ...).  But if you write them in that order, the
wrong thing will happen, because the putprops in the
(eval-when (load) ...) will happen at compile time anyway!

Oh well, I guess that in the days when we did all this stuff with
(declare (eval (read))) and such hacks, we could never have even been
able to concieved of such subtleties!