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

*To*: COMMON-LISP@sail.stanford.edu*Subject*: Re: constant folding/smashing*From*: goldman@vaxa.isi.edu*Date*: Tue, 07 Jun 88 13:27:08 PDT*Cc*: miller@acorn.cs.rochester.edu, cperdue@sun.com, NGALL@g.bbn.com*Posted-date*: Tue, 07 Jun 88 13:27:08 PDT*Sender*: 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

- Prev by Date:
**Re: constant folding/smashing** - Next by Date:
**Re: constant folding/smashing** - Previous by thread:
**constant folding/smashing** - Next by thread:
**Re: constant folding/smashing** - Index(es):