[Haskell-cafe] Re: (flawed?) benchmark : sort
Daniel Fischer
daniel.is.fischer at web.de
Mon Mar 10 17:48:59 EDT 2008
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
More information about the Haskell-Cafe
mailing list