Am Montag, 10. März 2008 21:34 schrieb Neil Mitchell:
Hi
But antisymmetry means that (x <= y) && (y <= x) ==> x = y, where '=' means identity. Now what does (should) 'identity' mean?
I think you are using the word identity when the right would would be equality. Hence, the answer is, without a doubt, (==). If you define equality, then you are defining equality.
Okay, bad choice of words. Of course I expect compare x y == EQ <==> x == y for any Ord instance. And for f :: (Eq a, Eq b) => a -> b I expect (x == y) ==> (f x == f y).
In short, I would consider code where for some x, y and a function f we have (x <= y) && (y <= x) [or, equivalently, compare x y == EQ] but f x /= f y broken indeed.
I would consider it slightly bad code too. But not broken code. I
Perhaps 'broken' is a stronger word than I thought. I wouldn't say there can never be a reason for such. It would not necessarily be *badly* broken, though at the moment I can't see a case where such behaviour (in an exported function) would be reasonable. Of course, internal fuctions are a different matter.
think Ord functions can assume that Ord is a total ordering, nothing more. Nothing to do with the existence (or otherwise) of entirely unrelated code.
Consider the following implementation of Data.Set, which *does* meet all the invariants in Data.Set:
data Set a = Set [a] insert x (Set xs) = Set $ x : filter (/= x) xs elems (Set xs) = xs
i.e. there is real code in the base libraries which breaks this notion of respecting classes etc. Is the interface to Data.Set broken? I would say it isn't.
I would say, if we have x = Set [1,2], y = Set [2,1] and an Eq instance where x == y, then elems shouldn't be exported.
Thanks
Neil
Cheers, Daniel