Issue EVAL-WHEN-NON-TOP-LEVEL, v2

[Jon L White <jonl@lucid.com>]

Sandra, I'm still confused by the comments in your msg of Jan 3:

    Seriously, I think it would be an extremely bad idea to make
    EVAL-WHEN's notion of when to perform compile-time magic different
    than the standard notion of top-level-ness.  Besides it being
    confusing, one wouldn't be able to use EVAL-WHEN to implement the
    magical compile-time behavior of the various defining macros.  I
    suppose that if we made the defining macros behave the same way, it
    would be somewhat more reasonable, but in that case why not just
    change the definition of top-level?

I don't see what you are getting at w.r.t. "defining macros".

This was (I think) in response to my suggestion to revive the working
implementation of EVAL-WHEN that did a MACROLET of EVAL-WHEN in order
to make nested, innner EVAL-WHEN's with the COMPILE situation work
correctly (i.e., not to evaluate such forms 2â??<n-1> times where n
is the level of nesting).  This "working definition" has the virtue
of consistency with CLtL's prescriptions (on page 70) such that
    1. The COMPILE situation "inherits"  -- namely, the following
       form will cause (blast-off) to be executed in the compiler
       environment, even though it is wrapped in eval-when(load):
             (eval-when (eval compile load)
               (eval-when (load)
                  (blast-foo)))
    2. Each form evaluated in "compile-time-too" mode is evaluated
       only once.

I was tempted to agree with Bacher's counter example on altering the
notion of toplevel.  It would be a counterexample if there are *any*
other operations that discriminate between toplevel and non-toplevel.
Currently the evaluation of defining forms and of the "7-extremely
randoms" seems to be it.  In short, he has found a flaw in the design
if there are any such operations; and if there aren't any such operations,
then the entire issue is moot except for the double-evaluation problem
in EVAL-WHEN.  So why not just let EVAL-WHEN take the brunt of the
extra definitional complexity?


-- JonL --