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