-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/13/2012 02:21 PM, John Cowan wrote:
> Ray Dillinger scripsit:
>
>> eq's behavior is strictly less specified than eqv?s behavior.
>> That means it is LESS discriminating, not more discriminating.
>
> It is more discriminating in the same sense that eqv? is more
> discriminating than equal?, namely that it can distinguish between
> a 2 and another 2, whereas eqv? cannot.

No.  It can't.  It is simply allowed to fail to detect that they
are operationally equivalent, even when they are in fact operationally
equivalent, and required to return #f rather than #t whenever it fails.

It provides no information in the strict Shannon sense
(meaning information as opposed to noise, not #f as opposed to #t),
that eqv? does not provide.

In fact (define eq? eqv?) is a standard-compliant implementation
of eq? and provides more, not less, information than eq? normally
provides.

> "Why, can you imagine what would happen if we named all the twos
> Henry or George or Robert or John or lots of other things? You'd
> have to say Robert plus John equals four, and if the four's name
> were Albert, things would be hopeless."  --The Magic Tollbooth

> That is exactly the distinction that eq? can make: it can
> distinguish between Robert and John even though they are both 2.

Such supposed 'distinctions,' as your quote pokes fun at, are
not useful for any purpose at all.  They should not be described
with words like "more discriminating" and "finer distinction" -
they should be described with words like "may fail to observe"
and "provides less information."

>> In fact, every instance of reliance on such a false "distinction"
>> (one made by eq? but not eqv?) is necessarily either a bug, or
>> implementation-dependent code.

> True.  However, if you know you are comparing eq?-safe types, you
> can use eq? and eliminate the type tests.

I suppose I could.  But why?  A typetag check and nonbranching
execution of a conditional branch is 2 machine code instructions,
which is just not worth thinking about. Besides if the system
does even elementary type analysis it'll eliminate even that
microscopic penalty from 90% of the uses of eqv? anyway - and
could approach 100% in cases where *we* know we're comparing
eq?-safe types.

The idea that human beings should waste sweat trying to save 2
instructions of machine code, once per ten comparisons, is just
ridiculous. Especially since we are more likely to get it wrong
and thereby introduce bugs, than that elementary type analysis.

The difference between eq? and eqv? is properly below human
notice.  It's tiny, it's constant, the optimization it represents
is automatable, and if we ever rely on that difference in
circumstances where the optimization cannot be automated, then
we are more probably creating a bug than legitimately saving
the tiny, constant, difference in speed.

				Bear

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQKbg8AAoJEAOzWkqOibfNqPcH/3IgWrOLNb3+Danh+uTpLYpp
bxt4IdeAP+bYgK3FthsQtZ25APmst21AAi452P4/xcOBEtPAX+fFM+7aTAhI1cvg
8s/Xb15blv6Cymjv6j5ju5w9509uob1nloza7H7rMQXUCAQQrvrj/uXJMbgWFEL4
YoHggNPKO0gBRovL1FMc6A5ZjuhhzE9YziB05cC0QZhGGrRfNNLX1nnpkgZVRTAt
eyp6uEclYRfzH83PMtgYqF+oei5dsecMKefqg0wIlcwleX5+/1yIhoXh97CgCZW+
DsTZmLbk4vIBABwcUaKIjZKjxKOQLTrK4WyUjww9FHrQC/bTNPajMlj+eKXfoy4=
=IMIU
-----END PGP SIGNATURE-----

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