Re: constant folding/smashing

[goldman@vaxa.isi.edu]

Thanks for pointing out that paragraph on P.78 that explicitly
authorizing "collapsing" EQUAL constants to EQ.  That at least provided
a recorded justification for the compiler's action.  By the way, does
anyone know the rationale behind this authorization?  Is there a big
win in implementation, or is to discourage perceived misuse of EQ-based
discriminations by programmers?  It seems to me to rule out some sensible
programs (and transformations), as well as plenty of bad ones.

At any rate, as can be seen from the responses, CLtL still fails to make clear
what must be held constant about an object used as a constant in a program
(whether declared with DEFCONSTANT or appearing in a QUOTEd form).

One hypothesis of INTENT (although it does not necessarily follow from the
text) is:

   Let V1 be a "constant" value.  If V1 is an instance of any of the types
(listed below) for which "components" are considered in the definition
of EQUALity, then it is an ERROR for a program to modify any of those
particular components of V1.  In particular, they cannot even be
changed to an EQUAL "copy" of their value.

In other words, the "boundary" of constanthood is described by the
definition of EQUAL on P.80 -- it prohibits changing:
   the car or cdr of a CONS
   elements of STRINGs or BIT-VECTORs
   components "(host, device, and so on)" of pathnames
Within this boundary, the parts must remain EQ forever.   Allocating
these parts in read-only memory is therefore permissible.

I have two questions about this:
1) is the above clear enough that an implementor knows what is allowed and
   a programmer knows what he is saying?

2) Is it the right framework for an answer?
I believe that the best way to define constanthood for lisp is in terms of
the  boundary used by SOME equivalence predicate.  I think that within
that boundary, constants should be constrained to remain constant up to
EQness.  But it doesn't follow, and I don't advocate, authorizing
an implemenation to collapse constants, OR PORTIONS THEREOF (is there an
implication that one can collapse selective parts?),
that happen to satisfy that equivalence predicate.

3) Is EQUAL what we need?
Frankly, I fail to see what is so interesting about EQUAL that makes it
the "best" equivalence predicate to use.  Why not EQUALP?
I like EQUALP better, except for the fact that numbers of different type
can be EQUALP.  CommonLisp is full of generic sequence operations.  But
EQUAL is not one of them.  It behaves quite differently for lists and
vectors, and NEVER considers a list EQUAL to a vector.
[This is the source of one's natural surprise in the example pointed out
by Nick Gall -- that 
	(setf (elt '#(#\a #\b #\c) 0) #\x)
must be legal.]
Because of this, a transformation that changes representations between
lists and vectors runs into oddball semantic problems wherever
EQUAL is used and, given the current semantics, wherever 
constants need to be transformed.

Neil