compile-time actions & top-level forms (long)

[Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>]

    Date: Thu, 8 Oct 87 11:27:49 MDT
    From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
This is pretty good.  I have a general comment, and a few specifics.

General comment:  Those forms which affect the compilation environment
should not be *required* to leave that effect behind when the compilation
is finished.  That is, it should be legal for a compiler, when finished
compiling a file or set of files, to leave your environment exactly as
it was before starting.

The tricky part is "set of files"; there is a concept of scoping possible
for a single compilation over multiple files.  This is particularly useful
if you defer warnings about undefined functions that are defined in later
files.  But as far as the language standard is concerned, I think it is
best if the compilation is not defined to affect the environment, and you
should be required to load the file before compiling the next if you want
macro definitions to be visible in the next file, portably.

Systems which are used for weeks at a time without booting shouldn't be
polluted by compiling, say, a file of macros with incompatible changes.

Specific comments:  [I agree 200% with everything I've deleted.]

    DEFVAR, DEFPARAMETER.  The compiler must recognize that the variables
    have been proclaimed special.  It is probably not a good idea to evaluate
    the initial-value form.

It should be definitely illegal to evaluate it at load time.

    DEFCONSTANT.  If this "normally" stores any information that is used by
    the compiler (for example, to warn about assignment to or rebinding of
    the variable), then this information should also be stored at compile time.
    It's probably acceptable to evaluate the initial-value form in this case.

Yes, this should be *required* to be evaluatable at compile time.
If there were such a thing as "evaluatable-p", it could be deferred
if not, but if the compiler is going to make use of this, it has
to know it can evaluate it.

    DEFSETF.  The SETF method should be available during the expansion of
    calls to SETF later on in the file.  (Does anybody care about
    DEFINE-SETF-METHOD and DEFINE-MODIFY-MACRO?)
Yes, both of those as well.


    DEFSTRUCT.  The structure type name must be recognized as a valid type
    name in declarations (as in the DEFTYPE example above).  In addition,
    further DEFSTRUCT definitions should be able to :include a structure
    type defined earlier in the file being compiled.  The functions which
    DEFSTRUCT generates may or may not be available at compile time.

But the accessors must be made available to SETF.