Expected behavior of "deriving Ord"?
Christian.Maeder at dfki.de
Mon Mar 31 04:34:25 EDT 2008
Christian Maeder wrote:
> Conal Elliott wrote:
>> The type argument I ran into trouble with represents a value as a list
>> of increasing lower bounds, ending in the exact value. min produces
>> lower bounds from lower bounds and so is immediately productive before
>> even knowing which argument is the lesser one.
> Is this only a matter of efficiency? Can it be compared with a faster
> equality check that does not need to evaluate terms always, because it
> compares the internal pointers first (and returns True for equal ones)?
Because min returns one of its arguments, "<=" could be defined in terms
of "min" and equality.
a <= b = min a b == a
"==" would cause further evaluations, but if an equality could look up
pointers (to unevaluated thunks) no further evaluation might be
necessary, so that min and <= do basically the same.
> Cheers Christian
> P.S. Maybe it is still a good idea to have a separate user defined class
> Min for your purpose, because then you don't have to hand-write compare
> functions, but then I don't know the nesting of your data types, though
> a generic instance Ord a => Min a may help.
More information about the Glasgow-haskell-users