[firstname.lastname@example.org: Re: [GHC] #1218: Add sortNub and sortNubBy to
lennart at augustsson.net
Tue Mar 20 18:48:01 EDT 2007
I have certainly used Eq and Ord similar to the ones in my example.
I know under what circumstances I can call what library functions,
but the compiler doesn't. It should not make any unprovable assumptions
about my code; I'd be very perturbed if it did.
On Mar 19, 2007, at 23:05 , Duncan Coutts wrote:
> On Mon, 2007-03-19 at 19:43 +0000, Lennart Augustsson wrote:
>> As I pointed out in the GHC trac report, this rule is wrong. E.g.,
>> data T = T Int Int deriving (Ord, Show)
>> instance Eq T where
>> T x _ == T y _ = x == y
>> ts = [T 1 1, T 1 undefined]
> So the problem in that example is that if we nub first then we get
> [T 1 1] and sorting that is presumably fine, however if we sort we
> compare both fields.
> My grumble here is that your Eq and Ord instances are not in agreement
> with each other. If you can claim that they're equal by only comparing
> the first components then surely you must for Ord too.
> Isn't some law being violated here:
> T 1 0 < T 1 1
> and yet T 1 0 == T 1 1
> but shouldn't a < b imply that a != b
> H98 requires that Eq and Ord be equality classes and total orders,
> it say nothing about any relationship between the two, that they be in
> any way consistent?
> So one could say that we can't really rely on any laws that should go
> along with type class instances, but that's clearly not right since
> we cannot sort!
> If we cannot rely on Ord then the current Data.List.sort
> is wrong because it gives different answers from the H98 spec sort
> the Ord instance is not a total order (this is easiest to see with
More information about the Libraries