[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Procedural equivalence: the last debate
- To: Alex Shinn <alexshinn@x>
- Subject: Re: [Scheme-reports] Procedural equivalence: the last debate
- From: taylanbayirli@x (Taylan Ulrich B.)
- Date: Thu, 06 Jun 2013 14:55:05 +0200
- Cc: John Cowan <cowan@x>, William D Clinger <will@x>, scheme-reports <scheme-reports@x>
- In-reply-to: <CAMMPzYNBc5hm4zgwKhOu+eyC=KCiDoCL80AEiN_J1ejChWfWCQ@mail.gmail.com> (Alex Shinn's message of "Thu, 6 Jun 2013 21:38:18 +0900")
- References: <14693978.2321981370479154000.JavaMail.root@zimbra> <4403747.2322031370479203487.JavaMail.root@zimbra> <CAMMPzYNBc5hm4zgwKhOu+eyC=KCiDoCL80AEiN_J1ejChWfWCQ@mail.gmail.com>
Alex Shinn <alexshinn@x> 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
Scheme-reports mailing list