time of evaluation

[Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>]

    Date: Wed, 15 Jan 1986  20:27 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

					  I guess this business of stashing
    the compiler's state changes in funny undoable places is about the best
    you can do.  I wouldn't like to see this solution cast in concrete for
    everyone, though.

There's no reason that this solution, or any other internal
implementation technique used in a Lisp system, should be cast in
concrete for everyone.  It's important to distinguish between the
defined semantics of Common Lisp, and implementation techniques.

The semantic question is what compile-file does vis a vis the Lisp
environment in which compile-file is called.  Revising my earlier
twofold choice in light of something Moon said, there are three
possibilities:

(1) The files being compiled see an empty Lisp environment when the
compilation starts.  The Lisp environment that called compile-file is
untouched.

(2) The files being compiled see a Lisp environment identical to the one
from which compile-file was called.  The Lisp environment that called
compile-file is untouched.

(3) The files being compiled see a Lisp environment identical to the one
from which compile-file was called.  The Lisp environment that called
compile-file is modified by side-effects performed on the Lisp
environment during the compilation.

Personally, I would find style (1) to be painful and inconvenient even
if my machine could switch to a new Lisp environment in two nanoseconds,
because I want the compilation to see the state in my Lisp environment.
Think of people who define their favorite macros in their init files,
who would then have to create some sort of "compiler init file" to set
up the compilation environment for all of their programs, as a simple
example.  I admit that this is a matter of philosophy of programming
environment that other people could validly disagree with.  I think that
(2) is what I want, although I can see some benefits in (3) under some
circumstances.

Do we have to make a decision on this?  If we feel that this behavior
must be made consistent from one Common Lisp to the next in order to
allow portability, that would mean that we have to make a decision.
Otherwise we can just say "Common Lisp doesn't specify it."  But let's
make sure that we're not introducing a new way to make porting not work.