On 2008-03-13, Ketil Malde wrote:

Aaron Denney writes:

...

Well, the way the report specifies that max's default definition is. I'd actually favor making that not an instance function at all, and instead have max and min be external functions.

If you permit a naïve question:

Prelude> :i Ord class (Eq a) => Ord a where compare :: a -> a -> Ordering (<) :: a -> a -> Bool (>=) :: a -> a -> Bool (>) :: a -> a -> Bool (<=) :: a -> a -> Bool max :: a -> a -> a min :: a -> a -> a

..while all functions could be easily derived from 'compare'. Or from the Eq instance's (==) and (<), say.

What is the reason for this? Efficiency? (Which couldn't be handled equally well by RULES?) Otherwise, it looks like an invitation for writing inconsistent instances.

My impression (which may not be entirely accurate) is not primarily for efficiency (though that is one reason), but for ease of implementation. It may be easier in some cases to think through the various cases of compare, or to just figure out what (<=) is. Either of these is sufficient (perhaps in combination with (==) from the superclass). You can write things so that any of (<), (<=), (>), or (>=) are sufficient, but for writing the default compare, it's easiest to know ahead of time which you are basing it on, so definitions don't get circular. max and min seem to have neither justification going for them, although I suppose it's technically possible to write compare in terms of them and (==). I don't think GHC's RULES were around when Haskell 98 was being formalized, nor is it clear that one compiler's method should let other efficiency concerns go by the wayside. Of course, it would be nice to be able to write (==) in terms of compare. While doable manually there's no way to default it to that "smartly". There are similar issues with Functor and Monad. ISTR some discussion about this on the list previously. -- Aaron Denney -><-