I'm afraid I do not have the wherewithal to weigh in on the technical merits of Will Clinger's proposal (as opposed to reversion to R5RS status quo). The practical effect of the proposal is permitting an optimization, whose value I cannot evaluate; at the cost of programmers moving more comparisons to eqv? instead of eq?, the performance hit of which I also cannot evaluate.
Philosophically, I see the situation as follows: In Scheme as it now stands, eqv? is the custodian of identity. eq? is an approximation to eqv?, which gains performance at the cost of exposing the fact that numbers and characters may be implemented with a complicated selection of underlying representations. The philosophical essence of Will Clinger's proposal, as I understand it, is to admit that procedures may also be implemented with a complicated selection of underlying representations. This is certainly true now, but perhaps wasn't as obvious, in the early days, as the situation with numbers. Therefore, I do not object to this proposal on technical grounds, but for procedural reasons I am hesitant to endorse it. In particular, I believe that Working Group 1 would be overstepping its bounds in implementing this proposal now, without specific direction to that effect from the community or from the Steering Committee.[*] Alex Shinn's proposal, on the other hand, is harmless both technically and procedurally. On the latter point, in fact, it is ambiguous whether "R5RS status quo" or "Alex Shinn's proposal" is the correct interpretation of the combination of WG1's voting record with the decision to restore R5RS semantics for eqv? on procedures. $0.02, ~Alexey [*] This is an opinion of the author, and does not represent the official position of WG1, the SC, the NSF, the NIH, MIT, or any other person or entity whatsoever, whether acronymical or otherwise. On Sat, Jun 8, 2013 at 9:36 PM, Alex Shinn <[email protected]> wrote: > It was pointed out that my counter to Will's proposal may > not have been clear. > > I propose we restore the semantics of eqv? and eq? on > procedures to IEEE/R5RS as the WG had intended. > > From this we make only one change, which is what the > WG voted on in ballot item #467, which is that eqv? may > make a broader distinction than eq?. However, this is > in the context of retaining the R5RS semantics for eq? > on procedures, so effectively we will duplicate the > same semantics for eqv? and eq? on procedures. > > The change is largely ideological, and would make it > easier should a future standard wish to make eq? > unspecified on procedures. It would only break R5RS > programs in very pathological cases, and only in > implementations which as yet do not exist. > > Unfortunately, not using eqv? to define eq? on > procedures becomes clumsy. A potential specification > is as follows, though I'm open to suggestions for > improvement: > > ---- > 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?. > ---- > > Finally, in addition to this, WG2 will include a declare > syntax to specify various standard optimizations. > This is of great practical use, and is likely the best way > to provide R6RS-style safety guarantees. Among the > declarations provided will be one which allows for eq? > to be unspecified on procedures. > > -- > Alex > > > _______________________________________________ > Scheme-reports mailing list > [email protected] > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports > _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
