Henning Thielemann wrote:
On Wed, 13 Sep 2006, Lennart Augustsson wrote:
I don't think Haskell really has the mechanisms for setting up an algebraic class hierarchy the right way. Consider some classes we might want to build: SemiGroup Monoid AbelianMonoid Group AbelianGroup SemiRing Ring ...
The problem is that going from, say, AbelianMonoid to SemiRing you want to add a new Monoid (the multiplicative) to the class. So SemiRing is a subclass of Monoid in two different way, both for + and for *. I don't know of any nice way to express this is Haskell.
Thanks for confirming what I wrote. :-)
If the above is equivalent to saying "Monoid is a *superclass* of SemiRing in two different ways", then can someone explain why this approach would not work (posted earlier): data Multiply = Multiply data Add = Add class Group c e where group :: c -> e -> e -> e identity :: c -> e inverse :: c -> e -> e instance Group Multiply Rational where group Multiply x y = ... identity Multiply = 1 inverse Multiply x = ... instance Group Add Rational where group Add x y = ... identity Add = 0 inverse Add x = ... (+) :: Group Add a => a -> a -> a (+) = group Add (*) = group Multiply class (Group Multiply a, Group Add a) => Field a where ... If the objection is just that you can't make something a subclass in two different ways, the above is surely a counterexample. Of course I made the above example more fixed than it should be ie: class (Group mult a, Group add a) => Field mult add a where ... and only considered the relationship between groups and fields - obviously other classes would be needed before and in-between, but perhaps the problem is that even with extra parameters (to represent *all* the parameters in the corresponding tuples used in maths), there is no way to get a hierarchy? Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com