[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp%su-ai@usc-ecl
- Subject: DEFCONSTANT
- From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
- Date: Tue, 07 Jun 1983 17:21:00 -0000
(Symbolics common-lisp-implementors may type D without reading: rephrase of Sat.'s flame.)
I am perturbed about DEFCONSTANT. According to the Laser manual,
DEFCONSTANT is just like DEFPARAMETER, but the compiler is free
to write the new value into object code.
While this sounds at first like an improvement, a more powerful
form of DEFPARAMETER, it is in fact a RESTRICTED form of
DEFPARAMETER. The issue of what-gets-put in the @i(initial-value)
slot is a subtle one. All well and good for
(defconstant foo 3),
but how about
(defconstant bar 6)
(defconstant foo (+ bar 6)),
which is legal, meaningful, common, useful, and non-problematic for
DEFPARAMETER? How is (+ bar 6) supposed to be evaluated at compile
time? (Note that DEFCONSTANT does this evaluation at load time, which
is what you "really" want). If the compiler were to use EVAL, does
that mean that bar was set at compile time by the first DEFCONSTANT,
so that this might be meaningful? If the binding were in some "compiler
temporary declaration", (such as the Lisp Machine compiler uses for
macros defined in a file being compiled) EVAL could not be used.
Compiling a file is NOT supposed to side-effect the environment.
The use of eval-when(compile) flags explicitly such attempts,
but does not make them harmless. Each such use has to be
deliberated very carefully, to prevent making impossible the
compilation of an incompatible version of the program.
Do you have to say
(eval-when (compile load eval) (defconstant bar 6))
(defconstant foo (+ bar 6))
to get meaningful results? Is this what we want? Should the
DEFCONSTANT documentation discuss and recommend this?
I will not even address the issue of
(defun f (x) ..)
(defconstant a (f 4))
but just throw it out for sport....
I think the use of DEFCONSTANT involves a tremendous amount of subtlety.
It may be reasonable to restrict the @i(initial-value) operand of
DEFCONSTANT to quoted or self-evaluating constants if the programmer
(and the compiler) are to have any hope of figuring out what is going