[Haskell-cafe] Re: Numeric type classes

[Jacques Carette]

Your solution would imply[1] that all Rational are multiplicatively 
invertible -- which they are not.

The Rationals are not a multiplicative group -- although the _positive_ 
Rationals are.  You can't express this in Haskell's type system AFAIK.

Your basic point is correct: if you are willing to use a tag (like 
Multiply and Add), then you can indeed have a domain be seen as matching 
an interface in 2 different ways.  Obviously, this can be extended to n 
different ways with appropriate interfaces. 

Jacques

[1] imply in the sense of intensional semantics, since we all know that 
Haskell's type system is not powerful enough to enforce axioms.

PS: if you stick to 2 Monoidal structures, you'll be on safer grounds.

Brian Hulley 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.