Issue: CONSTANT-SIDE-EFFECTS

[Masinter.pa@Xerox.COM]

This issue is mentioned by Rob's Compiler Proposal, although subsequent
mail on that topic shows that the wording is tricky. 

Since I had it on my list of issues, I'll keep it there, mark it as
Pending Compiler Proposal. If there isn't a compiler proposal by the
next X3J13 meeting from the compiler subcommittee, we may have to take
it on ourselves.

 - CONSTANT-SIDE-EFFECTS (not yet submitted)
   (It is an error to do destructive operations on constants in code,
    defconstant.)


Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79Date: Wed,
25 Feb 87 23:05 EST
 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Rob's Compiler Cleanup Proposal
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12281173600.BABYL@C.CS.CMU.EDU>
Message-ID: <870225230554.7.MOON@EUPHRATES.SCRC.Symbolics.COM>


. . .

  "It is an error to destructively modify any part of a Lisp data
structure that
  has been promoted to a program."

Does this mean that it is illegal to do things like
  (DEFVAR *FOO* '(1 2 3))
  (SETF (CDR *FOO*) NIL)
  (SETQ A '(1 3 4))
  (SETF (SECOND A) 2)
even when interacting with the read-eval-print loop?  This needs to be
more clearly defined.  Also, if users have to copy any quoted data
structures
they plan to modify, Common Lisp's lack of a really general copying
primitive
(for good reasons, defining the semantics is hard) becomes more glaring.

RAM:

I would say that it would be legal for an implementation to bum out
when you do this, but users might reasonably consider this to be
unreasonable behavior.  There currently is a note about it being
unreasonable for the system do strange things to constants typed in at
top level.  Perhaps this should be expanded on in a discussion of
top-level philosophy, but I don't think this is really very important
for the standard, since people will be porting programs rather than
transcripts of top-level sessions.


MOON:

  "When the system promotes a data structure to a program, it may
  non-destructively replace any part of the program with any
structurally
  equivalent data structure that is known to be unmodifiable."
  
How can you "non-destructively replace" something?  I think I know
what this means but it should be stated more clearly.  And if there are
good reasons to forbid destructive replacement they should be clearly
stated too.

RAM:
Well, I think it would pretty strange for EVAL to destructively modify
its argument.  I guess "non-destructive replace any part" means that
the system is free to do something equivalent to building a new
structurally equivalent form that may contain old structures as parts.


 From Issue file:

(*) 56, 68  Clarify that using DEFCONSTANT to redefine any constant
described in the Common Lisp specification is an error.  Clarify that if
the user defines a constant, compiles code that refers to that constant,
and then redefines the constant, then behavior of the compiled code may
be unpredictable.  (Perhaps it ``is an error'' to execute such code.)


Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 3 Sep 85  21:11:22
PDT
Received: by su-navajo.arpa with TCP; Tue, 3 Sep 85 21:10:23 pdt
Received: by edsel.uucp (2.0/SMI-2.0)
	id AA16018; Tue, 3 Sep 85 20:07:30 pdt
Date: Tue, 3 Sep 85 20:07:30 pdt
 From: edsel!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8509040307.AA16018@edsel.uucp>
To: navajo!Common-Lisp@SAIL
Subject: Modifying constants in programs

Here is a paragraph from CLtL which has some bearing on the discussion
of modifying constants in code:

''An additional problem with EQ is that the implementation is permitted
to "collapse" constants (or portions thereof) appearing in code to be
compiled if they are EQUAL.  An object is considered to be a constant in
code to be compiled if it is a self-evaluating form or is contained in a
QUOTE form.  This is why (EQ "Foo" "Foo") might be true or false; in
interpreted code it would normally be false, because reading in the form
(EQ "Foo" "Foo") would construct distinct strings for the two arguments
to EQ, but the compiler might choose to use the same identical string or
two distinct copies as the two arguments in the call to EQ.  Similarly,
(EQ '(A . B) '(A . B)) might be true or false, depending on whether the
constant conses appearing in the QUOTE forms were collapsed by the
compiler.  However, (EQ (CONS 'A 'B) (CONS 'A 'B)) is always false,
because every distinct call to the CONS function necessarily produces a
new and distinct cons.''

This implies that it is illegal to modify a constant in compiled code,
since the compiler is licensed to share all or part of that constant
with other compiled code.

For the particular example of COMPUTE-ONCE, it is not necessary to use a
special variable to hold the computed value.  A lexical variable will
suffice.  The scope of the lexical variable must include the entire
function in which it is referenced.  This is similar to an OWN variable
in Algol 60.

!