[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal #8: Clarifications to DEFCONSTANT
- To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Subject: Proposal #8: Clarifications to DEFCONSTANT
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Wed, 30 Jul 1986 01:53:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of 28 Jul 1986 20:57-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
- Sender: FAHLMAN@C.CS.CMU.EDU
Clarify that it is not an error to issue a second DEFCONSTANT command
for an existing constant iff the new value is EQL to the old one.
Do you mean EQL or EQUAL? Consider the example
(defconstant error-message-69 "Le *terminal-io* n'est pas une pipe.")
I don't see any good justification for reading and evaluating that form
twice to be an error.
Well, we prohibit compilers from replacing a constant reference with
inline code that is merely EQUAL to the constant; it must be EQL. This
was so that you could do things like
(defconstant terminator '(nil))
and then do EQL testing for instances of TERMINATOR. Perhaps this is
bogus, but if we keep that, we can't allow users to redefine constants
to other values that are merely EQUAL, because it will break such code.
I am not sure if it is safe to detect that the new constant value is
EQUAL to the old one and, if so, to leave the old one in place.
-- Scott