Alex Shinn <[email protected]> writes: > Thank you Will for the detailed history and explanation of > the implementation strategies. > > 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). > > We're still in the situation where we have to decide if it's > worth breaking the IEEE Scheme rule for eq? on procedures. > This has the following disadvantages: > > 1. It breaks a large amount of code as discussed previously. > 2. It slows down code that wants to work with procedure identity > by requiring the use of eqv? instead of eq?. > 3. It is yet another special equivalence case, which is thus > more difficult for users to learn and understand. > 4. It's a completely new semantics thrown in at the last minute. > You yourself argued how dangerous this is. > > The proposed workaround for the broken code of renaming > the library imports is clumsy and loses all eq? comparisons > (not just for procedures). > > 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. I trust your intuition for > this much more than my own, but we shouldn't be breaking > code and idioms based on intuition. > > I'd like to make a counter-proposal. We keep the separation > of eq? and eqv? on procedures as in the 9th draft. 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.
Thank you for this nice summary, and the sensible proposal; sounds good to me. _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
