[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
constant folding/smashing
Date: Thu, 9 Jun 88 14:59:16 PDT
From: Jon L White <edsel!jonl at labrea.stanford.edu>
To: NGALL at g.bbn.com
cc: goldman at vaxa.isi.edu, cperdue at sun.com,
common-lisp at sail.stanford.edu
Re: constant folding/smashing
re: My point is that in the form
(SETF (SYMBOL-VALUE (QUOTE X)) 1)
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?
Because the semantic model of symbols doesn't consider them to have
modifiable components; they are "atomic". In fact, several implementations
Wrong reason. (As has been pointed out in other discussion).
(SETF (SYMBOL-VALUE 'X) 1)
is the same as
(SETQ X 1), for X being special.
The X in either piece of code is a REFERENCE to a non-constant object,
shared between occurrances of read. It is a PUBLIC structure published
by INTERN. Modifications to its value cell are modifications to the global
variable environment. They're already EQified as much as makes sense.
The list structure in '(A B C) is a private structure not obtainable
by any other call to READ. EQification makes sense.
Where this breaks down, of course, is macros. Symbols, obviously, are
always (potentially) a shared resource (if interned). Lists are provably
private if they came from READ, but not from macroexpansion. As you point
out, EQification is part of the semantics of QUOTE. To clean this up, we
have to be more explicit in the semantics of QUOTE. In fact, let me assert
that one special form cannot accomplish all the variations of what behaviour
you'd like to see. You'd like to be able to establish explicit control
over what things are shared & read-only in a datastructure, presumably by
providing your own function. QUOTE should follow simple rules (the rules
it now follows, I claim, because it discourages self-modifying programs).