another nit

[Jonathan A Rees <JAR@MC.LCS.MIT.EDU>]

Now I'm trying to explain that QUOTE is allowed to return immutable
structured objects, and that particular implementations may have other
ways to create immutable data.  One thing that implementations can do as
a result of this is "coalesce" immutable structured objects the same way
that symbols are always coalesced and numbers sometimes are.  So it may
be the case that (EQV? '(A) '(A)) returns true.  So far so good.

I'm trying to describe EQV? and EQ? in terms of a "operational
equivalence", for which I think Ihave a fairly elegant definition.  I
was ready to say that EQV? is the procedure which determines operational
equivalence [with a proviso allowing it to make an approximate judgement
in the case of procedures and continuations, as discussed previously],
and then realized that my documentation would imply that (EQV? '(A)
'(A)) would be REQUIRED to return true in those implementations which
disallowed SET-CAR! on quoted lists.

Questions:

1. Should we say that the (SET-CAR! '(A) 'B) is an error, rather than
that it is unspecified?  [If some of you say it should never be an
error, I think you'll get into an argument.]

2. Should we require (EQV? '(A) '(A)) to return true in implementations
which forbid clobbering quoted structure (that would be all
implementations, if the answer to 1. is yes)?  I like this because it
simplifies the documentation; I don't need to say anything about
immutable data.

It would be a shame to require implementations to be able to distinguish
mutable from immutable data AND require them to create immutable data.
That has serious implementation implications; I don't want to propose
that.

N. I have noticed that the manual isn't careful about distinguishing "is
an error" from "unspecified".  Do people want me to try to make a clear
distinction between them, or is an unclear distinction sufficient?

Maybe talking about mutability is a bad idea if there aren't MUTABLE?
and IMMUTABLE? predicates.

If you think I'm totally confused and that there's a better way to think
about this, you're probably right.  Tell me how.

Jonathan