[Haskell-cafe] Re: (flawed?) benchmark : sort

[Adrian Hey]

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