[Haskell-cafe] Re: (flawed?) benchmark : sort
Adrian Hey
ahey at iee.org
Thu Mar 13 19:26:28 EDT 2008
ajb at spamcop.net wrote:
>> What's disputed is whether or not this law should hold:
>> (a == b) = True implies a = b
>
> Apart from possibly your good self, I don't think this is disputed.
If that's supposed it imply you think I'm in a minority of one I
don't think you've been following this thread very well. Even the
report uses the word "equality" in the prose. And as I pointed
out in another post, even the standard library maximum function
appears to ambiguous if the law doesn't hold.
It can be disambiguated if Aarons "max law" holds:
(a == b) = True implies max x y = y
But this is only true for the *default* max implementation. One of
the few explicit things the report does say on these matters is
that the default methods should *not* be regarded as definitive.
Besides there are good pragmatic safety and performance reasons
why Haskell should provide at least one class that offers
strong guarantees regarding equality and the (==) operator. If
that class isn't Eq, then where is it?
The (==) law holds for:
1- All "standard" Eq instances
2- All wholly derived Eq instances
3- Most hand defined instances I suspect.
..and has almost certainly been implicitly assumed by heaven knows
what extant code (some of it in the standard libraries I suspect).
So I think that we should recognise that this was the original
intent for the Eq class and this should be made "official", albeit
retrospectively.
If there's a need for a similar class where the (==) law doesn't
hold that's fine. But please don't insist that class must be Eq.
Regards
--
Adrian Hey
More information about the Haskell-Cafe
mailing list