Re: Constant Smashing

[NGALL@G.BBN.COM]

    Date: Tue, 14 Jun 88 13:20 EDT
    From: ELIOT@cs.umass.edu
    
    ...
    Further supporting the idea that a general mechanism apart from QUOTE
    is required to properly support read-only data structures, if read
    only data becomes a Common Lisp concept.
    
Agreed.

    >	(defun foo ()
    >	    '(a b c))
    >	
    >	Really means
    >	
    >	(defun foo ()
    >	    G00047)
    >	(setq G00047 '(a b c))
    >
    I'm not sure the code expresses my point clearly.  Functions that return
    quoted constants are subject to *external* modification of their *internal*
    behavior.  Its likely that you can get accidentally self modifying code.
    I've seen this cause obscure bugs.  I don't think it is intuitive.
    The source code for the first definition of FOO makes it notationally
    "obvious" (incorrectly) that FOO always returns the list (A B C).
    The source code for the second definition makes it notationally clear
    that there is some global and mutable state involved.

I think the 2nd definition is MORE misleading.  Yes it does suggest
"that there is some global and mutable state involved", but it
suggests that the wrong thing is modifiable.  By using a special var,
it suggests that the reference is mutable.  But that is exactly what
is CONSTANT (and I claim the ONLY thing that is constant) in the 1st
def.  What IS mutable (which neither def. suggests strongly enough) is
the list itself.  Again this suggests a different notation for RO is
needed.
    
    >It is also the
    >semantics of all (?) CL interpreters.  QUOTE MUST have the same
    >behavior in the compiler and the interpreter.  To do otherwise is to
    >introduce a compiler/interpreter incompatibility as confusing and
    >error-prone as the SPECIAL variable incompatibility used to be.  Agreed?
    
No.  QUOTE must have the same *semantics* in the compiler and
interpreter.  I was unclear.  I meant that the compiler and
interpreter must BEHAVE identically.  My point is a pedagogical one:
people learn lisp in the interpreter.  Textbooks use (and motivate)
QUOTE as if ALL that it does it to prevent evaluation and interpreters
support this model.  I feel would not be sufficient for CLtL to merely
state that "it is an error" to modify the arg of QUOTE and enforce in
in the compiler but not the interpreter.  This is what leads to the
continual confusion of neophytes.

    In the case of QUOTE some errors might go undetected.  This is not good,
    but it is not as dangerous a flaw as the SPECIAL variable problem,
    which is characterized by different compiled/interpreted behavior
    where neither behavior draws attention to the actual source of the
    problem.  It is relatively straightforward to debug a problem that
    causes the debugger to freeze execution near the actual cause.

Three: 1) What if the the RO-ness of the object was the bug.
Finding the source of the object could be very difficult. 2) I have
heard from at least 2 lisp implementors (on stock harware) that they
will not enforce the RO-ness of a QUOTEd object until system build
time, not compile time!  It takes us over an hour to build our system.
What a debug cycle! :-) [Actually this brings up the general issue of
a third kind of "code": interpreted, compiled, and "built".] 3) Its
not the debugging difficulty alone that bothers me, it is mere
difference in behavior between the compiler and interpreter in a very
common case.
    
    To support this argument I must make one more claim.  I must claim that
    compiling a function produces a *new* function definition that is
    semantically equivalent to the old one, but it does not have to
    be composed of the 'same' forms.
Agreed.
    This is because of the definition of
    CONSTANTP on p.324 (CLtL) which (in my reading) implies (eq (foo) (foo))
    when FOO is defined as above.  [Because of (constantp (quote a b c))]

Disagree. CONSTANTP uses the vague expression "evaluate to the same
thing".  Which version of SAME is it talking about? EQ EQL or EQUAL
Can't be EQ since CONSTANTP is true of numbers.  I claim SAME means
EQUAL, because of CLtLs EQUAL constant collapsing which IN THEORY
allows QUOTE to cons an EQUAL copy of its argument each time the QUOTE
form is evaluated. (As my pseudo-definition of QUOTE stated in a
previous message.)
    
    Therefore:
	    (eq (foo) (foo)) => T
	    (setq x (foo))
	    (compile 'foo)
	    (eq x (foo)) => Ambiguous
	    (eq (foo) (foo)) => T

No. (eq (foo) (foo)) => Ambiguous. This is why I want to flush EQUAL
constant collapse from CLtL.  I want it to be T.
    
    And no identity holds accross the act of compilation.
    
    >If you want to suggest that the interpreter should be changed to make
    >QUOTE return a RO-EQUAL-copy of its arg when possible*** (as I think JonL
    >may have been suggesting?), then consider what a pain it will cause at
    >the top-level:
    >
    >> (setf foo '(1 2 3))
    >(1 2 3)
    >> (push 0 foo)
    >>>>>> Error ...
    
    Tsk, Tsk.  THAT won't cause an error.  You meant: (setf (car foo) 'one)?
Yes.  Sorry about that.  I really meant (push 0 (rest foo)).

-- Nick