# [Haskell-cafe] Re: Numeric type classes

Lennart Augustsson lennart at augustsson.net
Wed Sep 13 08:36:15 EDT 2006

```The sum function really only needs the argument list to be a monoid.
And the same is true for the product function, but with 1 and * as
the monoid operators.  Sum and product are really the same function. :)

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.

-- Lennart

On Sep 13, 2006, at 03:26 , ajb at spamcop.net wrote:

> G'day all.
>
> Quoting Jason Dagit <dagit at eecs.oregonstate.edu>:
>
>> I was making an embedded domain specific language for excel
>> spreadsheet formulas recently and found that making my formula
>> datatype an instance of Num had huge pay offs.
>
> Just so you know, what we're talking about here is a way to make that
> even _more_ useful by dicing up Num.
>
>> I can even use things like Prelude.sum to
>
> Ah, but the sum function only needs 0 and (+), so it doesn't need
> the full power of Num.  It'd be even _more_ useful if it worked on
> all data types which supported 0 and (+), but not necessarily (*):
>
>     sum :: (AdditiveAbelianMonoid a) => [a] -> a
>
>     product :: (MultiplicativeAbelianMonoid a) => [a] -> a
>
> Those are bad typeclass names, but you get the idea.
>
> Right now, to reuse sum, people have to come up with fake
> implementations for Num operations that simply don't make sense on
> their data type, like signum on Complex numbers.
>
>>  All I really needed was to define Show and Num
>> correctly,  neither of which took much mental effort or coding
>> tricks.
>
> You also needed to derive Eq, which gives you, in your case,
> structural
> equality rather than semantic equality (which is probably
> undecidable for