time of evaluation

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

I agree pretty much with Weinreb's analysis of the problem.  It seems to
me that defstructs and deftypes should be handled the same way macros
are when compiling a file.  In older Lisps of the Maclisp generation, I
think that it was always the case that such things were simply evaluated
in the Lisp in which the compiler is running, altering that environment
permanently.  This didn't bother people too much, since typically you
fired up a special Lisp/Compiler job that was only used for compiling
one or more files.  I think that this scheme is permitted in Common
Lisp, but I haven't gone back to check the fine print; I'm sure that
many implementations do it this way.

In newer Lisps, people would like to be able to call Compile-File, have
the compiler do its thing on one or more files, and then go on to do
other things in that Lisp.  The process of compiling one or more files
should ideally not have any permanent effects on the Lisp in which
Compile-File is called.  One way to do this is to have Compile-File
spawn a separate Lisp process to do the compilation(s) in, perhaps a
virgin Lisp or perhaps a clone of the calling Lisp.  (Which is
preferable?  Should a file being compiled be able to depend on macros
that happen to be defined in the calling Lisp?)

That solution is not attractive in systems like the Lisp Machine, where
there is only one big Lisp address space and where people like to live
in that for days or weeks on end without polluting it.  Such systems do
indeed need to create some sort of quarantined environment within their
single Lisp.  One suggestion made some time ago was that when a file did
not specify any particular package, it should not be compiled in the
calling Lisp's current package, but rather in
SPECIAL-COMPILER-TEMPORARY-PACKAGE.  The thing that dumps out the FASL
file (or whatever) would arrange that symbols interned in this specific
package would be loaded into whatever package is current when the FASL
file is read in.  On the other hand, if the file specifies package FOO,
you read the stuff into package FOO.  It seems to me that this would
solve the problem in many cases, since if the user defined a macro,
structure-name, or type name, the symbol naming that thing would be
quarantined.  However, you still could get conflicts in some odd cases,
or when the user compiles a file with a specified package from a Lisp
that has that package loaded.

-- Scott