Revamping the numeric classes

[Ketil Malde]

"Ch. A. Herrmann" <herrmann@infosun.fmi.uni-passau.de> writes:

> moved to haskell-cafe

No, but *now* it is. (Does haskell@ strip Reply-To? Bad list!  Bad!)

> the problem is that the --majority, I suppose?-- of mathematicians
> tend to overload operators. They use "*" for matrix-matrix
> multiplication as well as for matrix-vector multiplication etc.

Yes, obviously.  On the other hand, I think you could get far by
defining (+) as an operator in a Group, (*) in a Ring, and so forth.

Another problem is that the mathematical constructs include properties
not easily encoded in Haskell, like commutativity, associativity, etc.

> I don't think that it is acceptable for a language like Haskell
> to permit the user to overload predefined operators, like "*".

Depends on your definition of overloading.  Is there a difference
between overloading and instantiating a class? :-)

> A cheap solution could be to define a type MathObject and operators like 
>    :*: MathObject -> MathObject -> MathObject
> Then, the user can implement:

> a :*: b = case (a,b) of
>              (Matrix x, Matrix y) -> foo
>              (Matrix x, Vector y) -> bar

Yes.  If it is useful to have a fine granularity of classes, you can
imagine doing:

        class Multiplicative a b c where
                (*) :: a -> b -> c

now I can do

        instance Multiplicative (Vector a) (Vector a) (Vector a) where
                x * y = ...

but also scalar multiplication

        instance Multiplicative a  (Vector a) (Vector a) where
                a * x = ....


Also, I think I can define Group a to be

        Additive a a a => class Group a where
                -- inherits plus from "Additive"
                zero :: a

        instance Group Int where
                (+) = built_in_int_addition
                zero = 0::Int

Long qualifier lists might be countered by having Classes -- Num, say
-- that just serve to include other classes in reasonable collections.
Funny mathematical names would - at least to some extent - be avoided
by having simple names for the classes actually defining the
operators, so that errors will warn you about missing "Multiplicative"
rather than Field or Ring or what have you.

From experience, I guess there are probably issues that haven't
crossed my mind.   :-)

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants