[Haskell-cafe] Justification for Ord inheriting from Eq?

John Meacham john at repetae.net
Thu Apr 6 18:44:22 EDT 2006


On Thu, Apr 06, 2006 at 10:52:52PM +0100, Brian Hulley wrote:
> >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 implementations.
> 
> 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).

well, there are a few reasons you would want to use inheritance in
haskell, some good, some bad.

1. one really does logically derive from the other, Eq and Ord are like
this, the rules of Eq says it must be an equivalance relation and that
Ord defines a total order over that equivalance relation. this is a good
thing, as it lets you write code that depends on these properties.

2. it is more efficient on dictionary passing implementations of
typeclasses. (does not apply to typecase based implementations like jhc)

3. it is simpler to declare instances for, the default methods of Ord
can depend on Eq.


1 is a very good reason.
2 not so much, but not irrelevant.
3 should not be a very good reason at all.

the inflexability of the class hierarchy was my motivation for the class
aliases proposal.

http://repetae.net/john/recent/out/classalias.html 


        John


-- 
John Meacham - ⑆repetae.net⑆john⑈


More information about the Haskell-Cafe mailing list