Expected behavior of "deriving Ord"?

Christian Maeder 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 mailing list