Proposal #8: Clarifications to DEFCONSTANT

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 21 Jul 1986  21:46 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Proposal #8:  Clarifications to DEFCONSTANT

    Clarify that using DEFCONSTANT to redefine any constant described in the
    Common Lisp specification is an error.

Non-controversial.

    Clarify that if the user defines a constant, compiles code that refers
    to that constant, and then redefines the constant, then behavior of the
    compiled code may be unpredictable.  It is an error to execute such
    code.

Non-controversial, and "is an error" seems clearly the right level, rather
than "signals an error."

    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.

    [That last clarification has not been discussed previously, as far as I
    know, but seems to be needed for reloading certain compiled code files,
    etc.]

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.  Consider that many Lisp dialects consider EQUAL
constants equivalent and coalesce them into EQ objects.  Of course EQUAL
isn't exactly the right test either, since (equal #(1 2 3) #(1 2 3)) is nil.
The appropriate test would be one that compares all elements of structured
objects and compares atoms with EQL, which doesn't exist as a predefined
function in Common Lisp.  Equality was one of the areas where we decided
to punt in the interests of getting a language specification out in a
finite time, since there wasn't complete agreement on what to do.

Perhaps parts 2 and 3 of this proposal properly belong to the system
environment, rather than to the programming language, especially when
you start talking about such concepts as "compiled code files".