time of evaluation

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

    In what Lisp environment is compile-file defined to compile the file?
    There are two possibilities: (1) it should use the present Lisp
    environment; (2) it should use an empty initial Lisp environment.  CLtL
    doesn't say, but it needs to, because the two are significantly
    semantically different.

I agree that it would be worthwhile to nail this down.

    If (1), then the techniques of spawning a separate Lisp process, or
    using a new package, won't work, unless you try to cleverly copy state
    from one place another or something.  If (2), then you can't break your
    program into a "defs" file that defines a bunch of macros, which you
    then load before you compile other files.  It means that every time you
    do a compile-file, you start with a bare Lisp and have to load up all
    the files with all the macros and other things that you plan to use.
    Even if you're compiling twenty files in a row and they all use the same
    defs files, you have to load the defs files over and over again.  This
    kind of "batch" operation is highly undesirable.

Your objection to interpretation 1 depends totally on what sort of
system you're thinking about.  On Unix, you can create a clone of the
current process with a simple fork.  Then if you're the new copy, you do
the compile and commit suicide.  Nothing clever required.

Your objection to 2 also depends on the assumptions you are making about
the system environment.  In the previous message, I was careful to say
"when you compile ONE OR MORE files".  If you spawn a virgin Lisp
process in which to compile, you just tell it to compile all 20 files
(including some defs files) in a lump, preserving state between
compiles; then commit suicide.  Or you could keep the compiler process
and its associated state around indefinitely and give the user a
REVIRGINIZE-COMPILER call which kills off the now-polluted compiler
process and creates a new fresh one.

On the 3600, either of these solutions presents a problem, I guess.
Since there's only one huge Lisp process (address space) to play with,
and since it is very expensive to save a copy of this huge thing on
disk, you don't have the option of compiling in one copy of an address
space while running in a second copy that is not polluted by the
compile.  The right solution is to catch up with Unix and other modern
operating systems by putting in true multiple processes (sorry, couldn't
resist), but if that is not possible, 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.

-- Scott