Am Montag, 10. März 2008 20:12 schrieb Neil Mitchell:
> > "The Ord class is used for totally ordered datatypes."
> > This *requires* that it be absolutely impossible in valid code to
> > distinguish equivalent (in the EQ sense, not the == sense) things via
> > the functions of Ord. The intended interpretation of these functions is
> > clear and can be taken as normative:
> > forall f . (compare x y == EQ and (f x or f y is defined))
> > ==> f x == f y)
> Are you sure? I would have read this as the ordering must be
> reflexive, antisymetric and transitive - the standard restrictions on
> any ordering. See http://en.wikipedia.org/wiki/Total_ordering
But antisymmetry means that (x <= y) && (y <= x) ==> x = y, where '=' means
identity. Now what does (should) 'identity' mean?
Depends on the type, I dare say. For e.g. Int, it should mean 'identical bit
pattern', shouldn't it? For IntSet it should mean 'x and y contain exactly
the same elements', the internal tree-structure being irrelevant. But that
means IntSet shouldn't export functions that allow to distinguish (other than
by performance) between x and 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
data Foo = Foo Int (Int -> Int),
an Ord instance via compare (Foo a _) (Foo b _) = compare a b
is okay if Foo is an abstract datatype and outside the defining module it's
compare (Foo a f) (Foo b g) == EQ implies (forall n. f n == g n), but not if
the data-constructor Foo is exported.
Haskell-Cafe mailing list