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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
