Alex Shinn wrote: > You seem intent that eq? and eqv? on procedures should > not be tied to each other. This is already so in the 9th draft, > and no one is trying to revert this (I had earlier queried if it > was really needed but immediately dropped the issue when > I found there was opposition).
I appreciate that. The R5RS and R6RS requirements that eq? and eqv? behave the same on procedures were, in my opinion, mistakes. > The proposed workaround for the broken code of renaming > the library imports is clumsy and loses all eq? comparisons > (not just for procedures). Unless I'm mistaken again, every Scheme standard has allowed eq? to be exactly the same as eqv?, so there's no way for portable code to rely on eq? being different from eqv?. > What I'm struggling to come up with on the other hand are > the pros of this change. There is as yet no evidence that > the alternate implementations allowed by this semantics > can actually produce faster code. There is actual evidence, but knowledge of that evidence is pretty much limited to compiler writers who are familiar with the history of optimizations based on eta conversion. In the Scheme community today, knowledge of that evidence is pretty much limited to compiler writers who are all too aware of the inefficient code being produced by their compilers because they haven't been allowed to implement strategy ABC. I may be the only person in that category who's been participating in this discussion. > I'd like to make a counter-proposal. We keep the separation > of eq? and eqv? on procedures as in the 9th draft. Thank you. > In WG2 we provide a declare syntax which can be used for declaring > common optimizations, such as fixnum-only, or various levels > of safety. We can then provide a standard declaration such as > > (declare procedures-have-no-location) > > or similar, which will allow all the implementation strategies > being discussed. This will then be able to stand on its own > merit - if the implementation techniques are worthwhile, they > will be implemented, users will make the declaration, and > not only will the code run faster but we'll have real-world > evidence of it. Moreover this will be useful as a way to > automatically test for broken code. In the meantime, code > and implementations continue to work as they always have > without slowing down. That's reasonable if WG2 decides declarations of that general form are desirable for other reasons. I don't think this particular class of optimizations is important enough by itself to justify the effort of designing that declaration syntax. Historically, many compiled implementations of Scheme have gone ahead and implemented optimizations that, in theory, violate one or more requirements of the relevant Scheme standard. The most obvious example is inlining of procedures such as eq? and car without any provision for undoing that inlining if those procedures are redefined. Most compiler writers have provided a way to turn off these non-conforming optimizations, but most Scheme programmers have been happy to use the default optimizations because speed usually matters more than conforming to a theoretical ideal. That particular example becomes obsolete with the R6RS and R7RS library systems, but it serves as a reminder that implementors are capable of judging for themselves which requirements are best honored in the breach, and programmers are capable of judging for themselves which implementations offer the most practical blends of conformance and performance. Libraries and interoperability are often more important than either, which is one reason we need to come to a conclusion here and move on. On the other hand, I'm glad we've been able to put this discussion on the record. Will _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
