-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/09/2012 02:45 PM, Noah Lavine wrote:

> One goal of my definition was to specify what eqv? had to do in
> implementations that might have extensions to R7RS. That is why I
> said "the implementation cannot tell them apart". I was also hoping
> to write a definition that would apply to all objects, not just
> numbers, because it would say what eqv? is meant to do.
>
> However, I would not claim that my definition got that right.
> Maybe Emmanuel's is better, if it's worded like this:
>
> Two objects are eqv? if either they are the same location (i.e.
> they are eq?), or they are different locations but a) contain the
> same value and b) could never be mutated to contain different
> values.
>
> What do you think?
>
> Noah

I think that this proposal would lose the distinction between eqv?
and eq? .  Further, I believe that that distinction is valuable and
ought not be lost.

I expect, if two variables are eq? , that mutation of one has as a
side effect mutation of the other; thus the two variables remain
eq?

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 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.

This "undefined" behavior allows but does not require eq? to be
implemented as a simple bitpattern comparison whether the bitpattern
is a pointer or an immediate value. Those implementors who prefer eq?
as an indication that aliasing mutation will occur will want eq? to
return #f in the case of immediate values, and those who prefer a very
fast implementation of eq? will prefer the bitpattern comparison even
though doing so causes eq? to return "wrong" results (#t even though
no aliasing mutation will happen) if interpreted as an indicator of
aliasing mutation.

I exclude two corner cases from the above "intuitive" description
of mutation on eqv? values: the case of a "no-op" mutation changing
the value to the same value, and the case of a mutation which causes
the eqv? values to become eq? (and therefore also to remain eqv?).

Scheme does not directly allow us to "see" memory locations, although
most people interpret eq? to mean identical pointers and many though
not all implementations do it that way.  It is at least possible, and
in some cases advantageous, (eg, long strings) for an implementation
to "intern" eqv? values (causing them to occupy the same memory
location) with copy-on-write semantics breaking the memory-sharing
when one or the other is mutated (and thereby avoiding mutating the
other).

Therefore, I do not advocate anything in the standard describing eq?
or eqv? in terms of shared memory locations, because that could
mislead an implementor who is interning eqv?-but-not-eq? variables
into doing the wrong thing.

				Bear

Things that look different should act different.  Things that look
the same should act the same.  -- Larry Marine
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQJyZxAAoJEAOzWkqOibfNcg4IAL2IzlKrs7BaqkCcEDcIJ9hj
T2tKUt5mZ4a/Bz/q6zYrwT+5uJeRf38lcLA68fiigSJfirKwLvN7nj/sURrMrZ6h
JC8P6+L2cT9ebMPcLwNrXTZbXqwXTDEsb5YPZz4JcSC1aHBs69g3ISt6oGJXGyii
1OrS33mNANaNEEhuQn+EuobTMPjqN6ThPm89R9jwOCEypbYKtjAh7vrH2zlEyKou
z3feiCovVFgnHzoL7NLCDJk4etPEhIqSCKCQkLS7LJnAGr/bIfqEfkucOMlNeWux
sAgs1GOVJ73jshLUaD8dfptVzg1MbhWiAlTWLezdjIfseJDRITb4+V7kSASWs8o=
=cnrT
-----END PGP SIGNATURE-----

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