Re: new, improved defining macros proposal

[sandra@cs.utah.edu (Sandra J Loosemore)]

Sigh, this issue just won't go away.

What one would normally expect DEFCONSTANT to do is to setq the symbol
and then somehow mark it as being constant, so that it can't be setq'ed
again.  At compile-time, if the value-form is not evaluable, you
obviously can't setq it yet.  I agree it would be silly to specify
that the setq'ing happens at compile-time in some cases but not in
others, and that was certainly not what I had in mind.

The intention was that *if* the compiler does substitution of symbolic
constants with their values *and* it can determine the value of the
symbolic constant at compile-time, *then* the compiler can assume
that the value of the constant at run-time is the same as what it sees
at compile-time and go ahead and make a substitution for it.  I would
assume that if an implementation is sophisticated enough to do all of
this, it would be able to store the information about the constant value
using some other mechanism besides setq'ing the symbol at compile-time.

I can try rewording this part of the proposal yet again.  I think the
main points are:

(1) the compiler should know that the symbol is a constant so it will
not complain when it sees references to it as an unbound variable, and
possibly so it will complain when it sees attempts to setq or bind the
symbol.

(2) neither the evaluation of the value-form or the setq'ing of the
symbol may happen at compile-time (analagous to DEFVAR and DEFPARAMETER)

(3) if the value-form can be evaluated at compile-time, the compiler may
assume that the constant will have the same value at run-time.

-Sandra
-------