compiler enviornment

[Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>]

We have some experience with the compiler environment, based on
our UCI Lisp implementations.  In our second-generation
UCI Lisp (called ELISP), we decided to separate the environment
of the compiler from that of the current core image.  We carefully
kept all macros defined in a compiled file on separate properties
from the normal macro property, and did other related things.
We found that this confused users no end.  For simple programs, none
of this mattered.  For complex systems, we found that users would
normally supply macros, structure declarations, and functions that
were used to expand both the macros and structure declarations.
They would get very confused when macro compilation blew up because
it couldn't get to functions that they had defined in their core image.
I am sure that all of this could be solved by appropriate use of
EVAL-WHEN, and appropriate care in implementation.  But I suspect
that most users would find it easier just to let the compiler use
the current Lisp environment.  I don't think Lisp-level copy on write
is really needed.  Most of our users are capable of writing 
initialization files that load in all of the pieces of their system
that are needed for compilation.  Then they have the choice of
compiling in their current core image, or getting a new one,
loading in the necessary initialization file, and compiling there.
I suspect it would be handy to have a way of making it easy to do
that in a subfork.  A function like 
  (COMPILE-IN-SUBFORK files-to-load files-to-compile)
with some way to keep the subfork around for later compilations.
Unless I hear some proposal more convincing than those so far, I don't
think these mechanisms are ready for standardization yet.
-------