Quoted structure not necessarily constant in my opinion, fix CLtL

[Robert Elton Maas <REM%IMSSS@SU-AI.ARPA>]

<F> Date: Tue, 6 Jan 1987  19:29 EST
<F> From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
<F> Subject: Destructive operations

<F> In my view, when a constant appears in code, the compiler is free to
<F> store this in read-only space or do other strange things that depend on
<F> the constantness of the constant.

This discussion isn't about constants, but about quoted structure. How
does a compiler determine whether quoted structure is intended to be
constant or merely initial (default) value? Where quoted structure
appears as second argument to MEMQ or MEMBER or as either argument to
EQ or EQUAL et al, it is obviously not changeable hence constant. But
where quoted structure appears as second argument to SETQ at toplevel
(not inside body of any function) it is often just an initial value.
(Where it appears as second argument to SETQ within a function that
might be loaded once but executed multiple times, it is probably poor
programming practice and should be flagged by compiler, since on the
one hand it can't be proved unchangeable, yet if it is ever
destructively changed the semantics of the function are changed out
from under it.) Perhaps only unambiguous cases should be accepted by
the language spec, that is global SETQs are assumed to be
default/initial values wile places that can't possibly be changed are
assmed to be constant, and all other use should "be an error".

<F> ...  I found nothing about other constants, such as '(a b c), that
<F> might appear in the body of the code. Still, I think that we must
<F> allow the compiler to assume that these things will not be altered
<F> destructively.

I think assuming '(a b c) is a constant is wrong, except in special
cases such as I outlined above.

<F> You can always store the list in a variable if you want
<F> it to be malleable.

Variables don't "hold" lists the way they do in, say, FORTRAN.
Variables hold pointers to the list, which may be shared among several
pointers. In the case above of '(a b c) somewhere, copying the pointer
to a variable doesn't solve the problem if the original data and hence
the pointed-at data is in readonly memory. You must actually copy the
whole data structure recursively by COPY or COPY-WHOLE or somesuch
function, but then you end up with the original data sitting in
readonly memory inaccessible yet permanently occupying memory. The
compiler should arrange that the original of the data gets loaded into
the heap (collectable memory) in the first place to avoid occupying
readonly space with data that won't ever be referenced after loading
the file.

<F> A subcommittee of X3J13 has been set up to formulate recommendations
<F> on how to fix this.  This is one of the issues that they should address.

I hope my points about readonly (constant) vs. initial-value will be
raised by somebody attending.

<EB> Date: Tue, 6 Jan 87 16:49:13 pst
<EB> From: edsel!babel!eb@navajo.stanford.edu (Eric Benson)
<EB> Subject: Destructive operations

<EB> On p.78 of CLtL, in the description of the function EQ, is the
<EB> following paragraph:
<EB> ``An additional problem with EQ is that the implementation is permitted
<EB> to "collapse" constants (or portions thereof) appearing in code to be
<EB> compiled if they are EQUAL.  An object is considered to be a constant
<EB> in code to be compiled if it is a self-evaluating form or is contained
<EB> in a QUOTE form.

I believe strongly this is a design mistake, innerds of QUOTE form can
be initial values as well as constants, depending on context, as per
my remarks earlier. Is it too late to fix this in the spec? But if
something is truly constant, then I agree any EQUAL parts should be
foldable with each other within a single constant such as '(A (B) C (B) B)
or between constants.

<EB> Because the compiler is permitted to share structure with constants in
<EB> compiled code, it follows that modifying such a constant is illegal.

If they are modified, then perhaps they weren't supposed to be
constants in the first place, the compiler jumped to a false conclusion.

<EB> Date: Wed, 7 Jan 87 11:38:23 pst
<EB> From: edsel!babel!eb@navajo.stanford.edu (Eric Benson)
<EB> Subject: Destructive operations

<EB> Right you are.  I was assuming too much.  Just because something may
<EB> have horrible consequences doesn't necessarily make it illegal.
<EB> Modifying constants in compiled code has the same legal status as
<EB> modifying the SYMBOL-NAME string of a symbol.  ``It is an extremely
<EB> bad idea to modify'' a constant in compiled code.

It's also an extremely bad idea for a compiler designer to assume
anyone who quotes any structure intends it to be readonly (constant),
unless the programmer also declares it to be constant somehow, or it
is obvious from the code it must be constant (but then the question is
moot).

<EB> For similar reasons, it is a bad idea to modify any object which is
<EB> used as a key in an EQUAL hash table (this problem is unfortunately
<EB> not mentioned in CLtL).

Putting a key in an EQUAL hash table is an obvious case where the
programmer is stamping the structure readonly, and compiler is
warranted in optimizing accordingly. I agree CLtL should warn about this.