"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