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 [email protected] you'd get cooks very confused. --RMS _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
