[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I agree with the proposal in its treating the initial value form of
DEFCONSTANT just like those of DEFVAR and DEFPARAMETER in that that form
must not be evaluated at compile time.  (Of course, DEFCONSTANT, just like
the others, may macroexpand into code that evaluates at compile-time.)

However, to answer the concerns of compiler implementors not being able
to make certain optimizations, it's quite permissible for compilers to
"evaluate" constants, both literals such as 3.4 and expressions such as
(ASH 3 7) or even (ASH FOO BAR) if both FOO and BAR were previously
defined DEFCONSTANTS with constant values.  The point is that if the
constant value depends on its run-time environment in any way, the
compiler can't try to do "constant folding" too early unless it can prove
there won't be any difference.

There's a separate issue here regarding substitution of constants, I think,
in whether it's permissible for (DEFCONSTANT FOO "abc") and a later use of
FOO to "copy" the string value.  I'd change the wording about substitution
of constants to mention that that's a separate issue for clean-up.

BTW, in the next-to-last paragraph, using "#." is also the wrong time--
since read-time might well be too early.  It's best to recommend either
that or EVAL-WHEN as needed.