Re: Issue: QUOTE-SEMANTICS, or QUOTE-MAY-COPY (Version 4)

[cperdue@Sun.COM (Cris Perdue)]

> Suppose an implementation has an EVAL which doesn't _guarantee_ that 
> any two successive calls on a function similar to:
> 
> 	(DEFUN FOO () (QUOTE <frob>))
> 
> will return EQ things [unless, of course, the equivalence class of 
> coalescings of <frob> has only one element in it; this is true of 
> symbols and most implementations of fixnums].  In that implementation,
> COMPILE should be permitted to "copy" constants, right?

Let us hope there are no such implementations.  I do not buy the
subsequent argument that some implementations need to be this way.
In fact, let us rule out such implementations.

I'm not sure how the following is intended to relate, but let
me reiterate a point I have made before, in case it isn't already
110% clear:

> However the final killer, I believe, in this scenario, is not EVAL 
> followed by COMPILE, but rather EVAL followed by reading in a new 
> definition followed by EVAL.  Even though QUOTE didn't copy anything, 
> and even though EVAL didn't copy anything, the output of the newly
> defined constant-returning fuction is no longer EQL to what it was 
> before.   And we do want to facilitate redefining functions on
> the fly, don't we?

(None of the following contradicts JonL's paragraph just above.)  Note the
invocation of READ in this scenario.  READ performed twice, LOAD
performed twice, PRINT followed by READ, PRINT followed by COMPILE-FILE
followed by LOAD, etc., all have effects *similar to* copying of Lisp
objects.  To be more precise, they each result in certain objects being
equivalent (EQUAL or similar as constants), but not EQ.

We must all realize that this phenomenon is separate from any
possible copying done by QUOTE.

As JonL has mentioned, we may also wish to allow a copy of some
sort to be made between the time a list structure is made into
a function and the time of completion of the first evaluation
of a (quoted or self-evaluating) constant in a function.  That
would not affect this scenario.