Show, Eq not necessary for Num [Was: Revamping the numeric classes]
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".
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.