DEFCONSTANT, etc

[Kent M. Pitman <KMP @ MIT-MC>]

Please note that (shudder) even though the value of the constant
of FOO in (DEFCONSTANT FOO val) is not accessible except during
compilation, any side effects done during the computation of val,
eg, (DEFCONSTANT FOO (PUTPROP 'BAR '(BAZ) 'SOME-PROP)) will be
available if the decision is made to do compile-time evaluation,
so the problem on the LispM of side-effecting the runtime environment
is a real one.

I am still bothered that on the LispM, the compiler does a
side-effect to my compile-time environment when it sees DEFSETF,
for example. 

The issue of separation of runtime and compile time environments is
a big one and I would suggest that there is probably a more orderly
way of proceeding in this discussion rather than poking at the details
of DEFSETF. Maybe we could make this discussion more general and 
talk first about what the effect of a compilation is on the compilation
time environment.

Also, one of the choices on Moon's (I think) list of 4 options of what
to do with DEFCONSTANT said "DEFCONSTANTs are executed at compile time,
but the values are restored after the compilation completes."  I'm
surprised he posed this; maybe he doesn't believe it, or maybe he has a
better theory of this than I do, but in an environment as on the LispM
where incremental compilation is possible, the idea of a compilation
being "complete" and of persistence of assumptions is muddied
considerably.

In any case, if Common Lisp took a definite stand on generalizations about
how the compiler and interpreter relate to one another, it would probably
be easier to answer questions like the one about DEFCONSTANT.

Also, it would be easier to think about DEFCONSTANT if someone posed some
real examples of where they would want to use it. What its semantics should
be is intimately tied to how it is suggested it be used. I find it hard to
think usefully about scenarios of what (DEFCONSTANT FOO 3) should mean.
--kmp