DEFCONSTANT

[Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>]

    Date:  8 June 1983 1147-EDT (Wednesday)
    From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
    Indeed, I have occasionally had problems with the compiler environment
    getting altered undesirably; DEFMACRO has the same effects you describe.
    Unlike what you say in (2), I believe that macros do get put into the
    compiler's environment. So the potential problems with DEFCONSTANT as I
    saw them are no different. In any case, I had hoped packages would
    help avoid confusion when compiling the compiler or the lisp system.
Indeed.  The Lisp Machine's compiler DOES NOT evaluate macro definitions
at compile time, but effectively remembers them as local declarations,
local to the file being compiled.  They are saved in a place where 
MACROEXPAND knows how to find them.  So on the Lisp Machine, the non-existent
sins of DEFMACRO are not an excuse for similar behavior by DEFCONSTANT.

Liber Laserum says only "the macro is added to the compilation environment",
which is noncommital.

The direct parent of Lisp Machine Lisp, MacLisp, indeed solved these
problems via packages.  Programs being compiled were compiled in a package
(one of two) where none of the compiler's internal symbols were accessible.
You could compile incompatible compilers with all the eval-when's you wanted,
without any fear of breaking the compiler.  The Lisp Machine (and Common Lisp)
package systems, although far more general, do not enjoy this feature.  This
is the reason at the root of why we don't eval-when(compile) macros.

eval-when(compile) is not an object for trepidation in an environment
where the program being compiled lives in its own namespace, or in a
batch compilation environment (the compiler is a separate program that you
invoke from operating system command level), which is effectively the same thing.

Even the Lisp Machine has two paradigms of compilation that are diametrically
opposed on the issue of compilation side effects.  When we compile files,
we do so in such a way as to minimize side effect.  When we compile
editor buffers or pieces of editor buffers, we do so in such a way as to
maximize side effect.  Specifically, we "load" each top-level form 
immediately after we have compiled it.  In this latter scenario, ALL
of my supposedly problematic DEFCONSTANT examples do the "right thing".

I tend to agree with KMP that the language spec needs work in the area of
compile/load interactions, compilation environment mungs, etc.  I think 
the language should  either define behavior precisely or state what freedom
of choice is open to the implementation.  Defining precise behavior might 
mean that somebody has to turn their implementation inside out, while 
permitting enough freedom so that nobody has to turn their implementation
inside out might, for instance, make DEFCONSTANT unspecifiable and/or
unimplementable.