On 08/11/2012 11:43 PM, Ray Dillinger wrote:
> Conversely, I expect, if two variables are eqv? but not eq?, that
> mutation of one will not have a side effect of mutating the other,
> thus the two variables will not remain eqv?

I believe this is incorrect.  If two mutable values are 'eqv?', then
they must denote the same locations.  Can you provide an example of a
Scheme standard or major implementation that allows an exception this rule?

This rule is consistent with the R3RS definition of 'eqv?' as an
approximation to the operational equivalence relation.  Specifically,
the R3RS allows 'eqv?' to return #true only when the values are known to
be operationally equivalent.  In cases where operational equivalence
cannot be proved, it must return #false.

Two distinct mutable locations are never operationally equivalent,
regardless of what values they hold at a given time.

> I exclude from the above "intuitive" description of mutation on
> eq? values the case where the values are "immediate", a notion not
> defined in the standard but identifiable in the standard as the set of
> objects (including numbers and characters) on which the behavior of
> eq? itself is undefined.

Immediates cannot be mutable.  Also, 'eq?' is defined on booleans and
the empty list, which are usually implemented as immediates.  I suspect
the reason 'eq?' is not defined on numbers and characters is that
although a subset is often implemented as immediates, there is no
guarantee that all of them can be.

      Mark

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports