Scheme language standardization process
-----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@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports