Alex Shinn <alexshinn@gmail.com> 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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports