[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] [scheme-reports-wg1] Digest for scheme-reports-wg1@x - 13 Messages in 5 Topics

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

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

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.


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


Scheme-reports mailing list