John Cowan <cowan@mercury.ccil.org> writes:

> I am now prepared to make a recommendation to WG1 on procedural
> equivalence.  I recommend that we return to R5RS semantics by
> rescinding both tickets #125 and #467.  This means that `eqv?` must
> return true on procedures with the same location tags, must return
> false on procedures that behave differently, may return either on all
> other pairs of procedures, and `eq?` must always return the same as
> `eqv?` on procedures.

I believe the R3RS/R4RS/IEEE semantics are both superior and more
intuitive.

> I recognize that this means that Will's three optimizations (`eq?` is
> a pointer comparison, `eqv?` compares procedures by looking at the
> code pointer and the environment pointer rather than the closure
> pointer, and delayed boxing of procedures is permitted) are not all
> possible in the same implementation.  However, I am persuaded that it
> is simply too dangerous to silently break existing R5RS code that
> relies on using `eq?` to compare procedures.
>
> The traditional approach to standards-violating assumptions in Scheme
> is to either allow them with a switch or declaration of some sort, or
> simply to allow them by default and restore the standard behavior by a
> switch or declaration.  As far as I know, no existing implementation
> as of today has such a switch.  (R6RS implementations don't count for
> this purpose, as they require of `eqv?` only that it return false on
> procedures that behave differently, and still require that `eq?` and
> `eqv?` return the same in all cases.)
>
> At the moment, we have only two other silent breaking changes in R7RS:
> string comparison is no longer required to be a lexicographic
> extension of character comparison, and _ can no longer be used as a
> syntax variable.  Neither of these is as subtle or as potentially
> pervasive as Will's proposed change to `eq?`.

Note that the R4RS semantics will only break R5RS code that is obscure
enough to rely on eq? and eqv? behaving the same for procedures.

> It turns out, furthermore, that #467 was interpreted different ways by
> different voters.  I thought it was equivalent to Will's point 4.
> However, Alex and Alexey interpreted it to mean that although the
> situations in which `eq?` and `eqv?` must return true or false would
> remain the same, the link between them would be broken, so that in
> cases where the standard did not prescribe anything (that is, where
> the location tags are different but the procedures do the same thing),
> `eq?` might return false and `eqv?` true.  So although all but one of
> the WG members voted for #467, we were voting for different things.
>
> Alex at least agrees with me that with #125 gone, #467 has no
> practical value, though he said he doesn't care about its outcome.  I
> think that on his and Alexey's reading, it is a pointless change to
> R5RS that effectively reverts to the R4RS/IEEE version of `eq?` (which
> does not mention procedures).  So I say the hell with it.  Let's go
> with the R5RS definitions of both `eq?` and `eqv?`, which though not
> perfect, at least are more or less understood now.  If we have
> definite evidence in future that breaking `eq?` is a win (or for that
> matter that breaking `eqv?` is a win), we can introduce declarations
> to do so.

I wouldn't say that breaking the tie between eq? and eqv? could be said
to be breaking either of them.  Regarding being well-understood, in my
opinion it doesn't get any simpler than "pointer-comparison
vs. operational equivalence" with no additional constraints, and while
that explanation is informal, we already have the notion of the
conceptual location tags to support a formal explanation.  Before this
discussion it never even occurred to me that eq? and eqv? were tied
together for procedures in such a way that either eq? must be as complex
as eqv?, or eqv? as primitive as eq? (barring for specific optimization
strategies that detect the operational equivalence of procedures at
compile-time and arrange them to be represented by the same pointer).

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