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

[Jerzy Karczmarczuk]

"Ch. A. Herrmann" answers my questions:

>     Jerzy> What 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.

Aha. But I would never call this a DEFINITION of this operator.
This is just the type, isn't it?
A misunderstanding, I presume.

> Jerzy> Forbid what?
> A definition like (a trivial example, instead of matrix/vector)
>    class NewClass a where
>      (*) :: a->[a]->a
> leads to an error 

OK, OK. Actually my only point was to suggest that the type for (*)
as above should be constrained oinly by an *appropriate class*, not
by this horrible Num which contains additive operators as well. So
this is not the answer I expected, concerning the "overloading of
a predefined operator".


BTW.

In Clean (*) constitutes a class by itself, that is this simplicity
I appreciate, although I am far from saying that they have an ideal
type system for a working mathemaniac.

> ... 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?

Aaa, here we might, although need not disagree. I would like to see some
rational constraints, preventing the user from inventing a completely
insane semantics for this multiplication, mainly to discourage writing
of programs impossible to understand.



Jerzy Karczmarczuk
Caen, France