Alex Shinn wrote:

> 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).

I appreciate that.  The R5RS and R6RS requirements that eq? and
eqv? behave the same on procedures were, in my opinion, mistakes.

> The proposed workaround for the broken code of renaming
> the library imports is clumsy and loses all eq? comparisons
> (not just for procedures).

Unless I'm mistaken again, every Scheme standard has allowed
eq? to be exactly the same as eqv?, so there's no way for
portable code to rely on eq? being different from eqv?.

> 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.

There is actual evidence, but knowledge of that evidence is
pretty much limited to compiler writers who are familiar with
the history of optimizations based on eta conversion.  In the
Scheme community today, knowledge of that evidence is pretty
much limited to compiler writers who are all too aware of the
inefficient code being produced by their compilers because
they haven't been allowed to implement strategy ABC.  I may
be the only person in that category who's been participating
in this discussion.

> I'd like to make a counter-proposal.  We keep the separation
> of eq? and eqv? on procedures as in the 9th draft.

Thank you.

> 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.

That's reasonable if WG2 decides declarations of that general form
are desirable for other reasons.  I don't think this particular
class of optimizations is important enough by itself to justify
the effort of designing that declaration syntax.

Historically, many compiled implementations of Scheme have gone
ahead and implemented optimizations that, in theory, violate one
or more requirements of the relevant Scheme standard.  The most
obvious example is inlining of procedures such as eq? and car
without any provision for undoing that inlining if those procedures
are redefined.  Most compiler writers have provided a way to turn
off these non-conforming optimizations, but most Scheme programmers
have been happy to use the default optimizations because speed
usually matters more than conforming to a theoretical ideal.

That particular example becomes obsolete with the R6RS and R7RS
library systems, but it serves as a reminder that implementors
are capable of judging for themselves which requirements are best
honored in the breach, and programmers are capable of judging for
themselves which implementations offer the most practical blends
of conformance and performance.

Libraries and interoperability are often more important than
either, which is one reason we need to come to a conclusion here
and move on.  On the other hand, I'm glad we've been able to put
this discussion on the record.

Will

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports