[Haskell-cafe] Justification for Ord inheriting from Eq?
brianh at metamilk.com
Thu Apr 6 17:52:52 EDT 2006
John Meacham wrote:
> On Thu, Apr 06, 2006 at 09:31:24PM +0100, Brian Hulley wrote:
>> I've been wondering for a long time if there is a reason why Ord
>> should inherit from Eq and not vice versa, or whether in fact there
>> is any justification for making either Ord or Eq inherit from the
>> other one.
> The problem is that having an order implies you have equality, so
> deriving Eq from Ord won't actually mean anything.
Thanks, I didn't think of it that way.
> in haskell classes _do_ define interfaces, not concrete
> representations so the problems with inherentence of non-abstract
> classes in OO languages don't apply.
What I was trying to argue was that inheritance of classes in Haskell is not
needed because the only "good" use (IMO) of inheritance in other languages
is already dealt with in Haskell by the class/instance distinction: the
classes defining the interfaces and the instances defining the concrete
The problem of allowing classes (in Haskell) to inherit is that you end up
with heirarchies which fix the design according to some criteria which may
later turn out to be invalid, whereas if there were no hierarchies then you
could just use the particular classes that are needed for the particular
function, eg explicitly supplying Eq and Ord instead of just Ord etc (though
for a sort function Ord by itself would be sufficient).
For example the re-organisation of numeric classes might not have been
necessary if there were no inheritance relationships between them (though I
don't know enough details to take this example further).
More information about the Haskell-Cafe