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

Re: constant folding/smashing

    Date: Tue, 7 Jun 88 10:24:20 PDT
    From: cperdue@Sun.COM (Cris Perdue)
    > It is this aspect of `constant'ly returning the same (EQ) object that
    > is meant in the sentence on pg. 86: "[QUOTE] allows any Lisp object to
    > be written as a constant value in a program."  It is the value of the
    > (QUOTE ...) form that is held constant, not the object itself.  The
    > same (EQ) object will always be referenced, but that object may be
    > modified over time (if it is a composite object).
    The problem with this conclusion is that if the storage for constants
    is "collapsed" together, it is impossible to know how many constants
    are changing if you change a constant.  A constant in someone
    else's code, even system code, may be changed by your side effect.
    This is an intolerable situation, so side-effects on constants
    are an error.
I don't believe the following form is in error
even though X is wrapped by (QUOTE ...) and is therefore being
"written as a constant value in a program." (See above) The reason
this ISN'T an "intolerable situation" is that in the case of a symbol,
EQUAL is the same as EQ, so you don't get UNEXPECTED side-effects.

What WOULD be intolerable would be to follow your rule ("side-effects
on constants are in error") and say that the above form is in error.
That would force people to write such things as

My point is that in the form
the quoted object is no more or less "constant" than in the form
   (SETF (FIRST (QUOTE (A B C))) 1)
So why does QUOTE make the components of the list (1 2 3)
unmodifiable but not the components of X?

What causes the UNEXPECTED side effects in the latter form is the
folding of EQ but not EQUAL objects into one object.  I am currently
thinking of a way to use DEFCONSTANT to limit such CONSTANT folding in
a CLtL compatible way (i.e., don't constant fold the values of

-- Nick