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

**Jerzy Karczmarczuk
**
karczma@info.unicaen.fr

*Wed, 07 Feb 2001 17:12:24 +0000*

"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