new, improved defining macros proposal

[gz@spt.entity.com (Gail Zacharias)]

I just started receiving this mailing list, so my apologies if this has been
discussed before.

   DEFCONSTANT: 	...			(If the initial
   value is a constant, however, an implementation is allowed to
   substitute the constant value for references to the named constant
   during subsequent compilation.)

I have a problem with this.  The compiler shouldn't have licence to substitute
for the variable without fully implementing the semantics of DEFCONSTANT.
In particular, under this proposal, would the DEFCONSTANT's with constant
initial values be "evaluable at compile time" in the sense used in the
description of DEFMACRO?  I.e. would the following work?
   	(DEFCONSTANT FOO 'FOO)
	(DEFMACRO FOO () `',FOO)
	(DEFVAR *FOO* (FOO))
In addition, the distinction between constant/non-constant initial value is
artificial and potentially ambiguous in the face of differing constant-folding
capabilities.  Consider
	(DEFCONSTANT FOO 17)
	(DEFCONSTANT BAR (ASH 1 FOO))
Are compilers allowed to substitute for BAR?

I think toplevel DEFCONSTANT should either be treated like DEFMACRO (i.e.
implicitly compile-time: initial value "must be evaluable at compile time" and
the binding must be made available to other compile-time code) or like
DEFVAR/DEFPARAMETER (implicitly load-time: compiler recognizes the variable as
special, but it is not allowed to substitute the value).  I don't have a
strong preference either way (since you can always get "the other" semantics
via eval-when), but I don't like the proposed mixture of the two.