Re: [Scheme-reports] Procedural equivalence: the last debate

[John Cowan <cowan@x>]

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

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.

-- 
A rose by any other name                            John Cowan
may smell as sweet,                                 http://www.ccil.org/~cowan
but if you called it an onion                       cowan@x
you'd get cooks very confused.          --RMS

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