Alex Shinn <alexshinn@gmail.com> writes:

> I propose we restore the semantics of eqv? and eq? on
> procedures to IEEE/R5RS as the WG had intended.

Well, R3RS/R4RS/IEEE have separate semantics from R5RS, the latter being
the only one that ties eq? to eqv?.

> ----
> The eqv? procedure returns #t if:
>
> * obj1 and obj2 are procedures whose location tags are
> equal (section 4.1.4).
>
> The eqv? procedure returns #f if
>
> * obj1 and obj2 are procedures that would behave
> differently (return different values or have different side
> effects) for some arguments.
>
> ...
>
> On symbols, booleans, the empty list, pairs, records, and
> non-empty strings, vectors, and bytevectors, eq? and eqv? are
> guaranteed to have the same behavior. On procedures eq? returns
> true if the arguments' location tags are equal, and returns false
> if the arguments would behave differently for some arguments. On
> numbers and characters, eq?'s behavior is
> implementation-dependent, but it will always return either true
> or false, and will return true only when eqv? would also return
> true. On empty strings, empty vectors, and empty bytevectors, eq?
> may also behave differently from eqv?.
> ----

I would constrain the returning-false condition via eqv?, indicating
that eqv? is always compatible and sometimes more capable:

    On symbols, booleans, the empty list, pairs, records, and non-empty
    strings, vectors, and bytevectors, eq? and eqv? are guaranteed to
    have the same behavior. On procedures eq? returns true if the
    arguments' location tags are equal, and returns false at least when
    eqv? also does. On numbers and characters, eq?'s behavior is
    implementation-dependent, but it will always return either true or
    false, and will return true only when eqv? would also return
    true. On empty strings, empty vectors, and empty bytevectors, eq?
    may also behave differently from eqv?.

This raises for me the question though, may eq? return #t for empty
strings, empty vectors, or empty bytevectors, where eqv? returns #f?
The introduction to eq? leads me to think that it may not, because only
"in some cases it is capable of discerning distinctions finer than those
detectable by eqv?," but not equivalences finer than those detectable by
eqv?.  If this is the case, we could as well put the constraint of only
returning #t when eqv? also does into a separate sentence.  The
following is a slightly bigger change in wording, although I believe it
explains the same semantics in a cleaner way:

    Eq? is similar to eqv? except that in some cases it is capable of
    discerning distinctions finer than those detectable by eqv?, meaning
    that it must always return #f when eqv? also would, but may return
    #f in some cases where eqv? would return #t.

    On symbols, booleans, the empty list, pairs, records, and non-empty
    strings, vectors, and bytevectors, eq? and eqv? are guaranteed to
    have the same behavior. On procedures eq? must return true if the
    arguments' location tags are equal. On numbers, characters, and
    empty strings, vectors, and bytevectors, eq?'s behavior is
    implementation-dependent, but it will always return either true or
    false.

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