Show, Eq not necessary for Num [Was: Revamping the numeric classes]

[Ch. A. Herrmann]

Hi Haskellers,

>>>>> "Jerzy" == Jerzy Karczmarczuk <karczma@info.unicaen.fr> writes:
    Jerzy> "Ch. A. Herrmann" wrote:

    >> 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.
    >> 
    >> Therefore, a quick solution that implements groups, monoids,
    >> Abelian groups, rings, Euclidean rings, fields, etc. will not be
    >> sufficient.
    >> 
    >> I don't think that it is acceptable for a language like Haskell
    >> to permit the user to overload predefined operators, like "*".

    Jerzy> Wha do you mean "predefined" operators? Predefined where? 

In hugs, ":t (*)" tells you:
   (*) :: Num a => a -> a -> a
which is an intended property of Haskell, I suppose.

Jerzy> Forbid what?
A definition like (a trivial example, instead of matrix/vector)
   class NewClass a where
     (*) :: a->[a]->a
leads to an error since (*) is already defined on top level, e.g.
    Repeated definition for member function "*"
in hugs, although I didn't specify that I wanted to use (*) in
the context of the Num class.
However, such things work in local definitions:
   Prelude> let (*) a b = a++(show b) in "Number " * 5      
   "Number 5"
but you certainly don't want it to use (*) only locally.

    Jerzy> Using the standard notation even to multiply
    Jerzy> rationals or complexes?
No, that's OK since they belong to the Num class. But as
soon as you want to multiply a rational with a complex
you'll get a type error. Personally, I've nothing against
this strong typing discipline, since it'll catch some
errors.

    Jerzy> And leave this possibility open to C++ programmers who can
    Jerzy> overload anything without respecting mathematical congruity?
    Jerzy> Why?
If mathematics is to be respected, we really have to discuss a lot of
things, e.g., whether it is legal to define comparison for floating point
numbers, but that won't help much. Also, the programming language should
not prescribe that the "standard" mathematics is the right mathematics
and the only the user is allowed to deal with. If the user likes to
multiply two strings, like "ten" * "six" (= "sixty"), and he/she has a
semantics for that, why not?

    Jerzy> A serious mathematician who sees the signature 
    Jerzy> (*) :: a -> a -> a 
    Jerzy> won't try to use it for multiplying a matrix by a
    Jerzy> vector.
A good thing would be to allow the signature 
   (*) :: a -> b -> c
as well as multi-parameter type classes (a, b and c)
and static overloading, as Joe Waldmann suggested. 

    Jerzy> No need to "lift" or "promote"
    Jerzy> scalars into vectors/matrices, etc.
You're right, there is no "need". We can live with
    a :*: b
for matrix multiplication, and with
    a <*> b
for matrix/vector multiplication, etc. It's a matter of style.

If anyone has experiences with defining operators in unicode
and editing them without problems, please tell me. Unicode
will provide enough characters for a distinction, I suppose.

Bye 
-- 
 Christoph Herrmann
 E-mail:  herrmann@fmi.uni-passau.de
 WWW:     http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html