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. -- Alex
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
