John Cowan <[email protected]> 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
