Miguel Mitrofanov, please kindly stop pretending that you KNOW what is a number, and what is not.
Never said that. Sometimes it's debatable. But if you can't figure out a way to multiply things so that it would make some kind of sense - you haven't made them numbers (yet).
The numeric classes in standard Haskell are disgraceful, and the idea that if something can be added, it is a number is bad.
Which is kinda my point.
So, people call "numbers" what they wish, and it is *their* business.
I'm not sure what do you mean here. Of course, it's OK to call anything "numbers" provided that you stated explicitly what exactly you would mean by that. But then you have to drop all kind of stuff mathematicians developed for the usual notion of numbers. In the same way, you shouldn't use the "Num" class for your "numbers". On the other hand, people can (ab)use the "Num" class as they wish, and it's their business until they ask a question about it somewhere outside - which makes the business not only theirs.
Pairs (a,b) may be "numbers" in various contexts, for example (value,derivative) in automatic differentiation. Or (mainTerm,otherOrders) in some infinitesimal calculus. Or pairs (scalar, 3vector) for quaternions.
Or (real, imaginary) for complex numbers. That's right. All these notions are very different - which is why "pairs of numbers" are NOT numbers - but "complex numbers" are, as well as "value-derivative pairs". Isn't that what we have newtypes for?
There are plenty of examples where conversions from integers are legitimate, but no addition or (*)seem natural.
Certainly. I think it's commonplace that numerical classes in Haskell Prelude are not exactly an example of perfect design. Still, it doesn't make it good to abuse classes like "Num" just because we want a fancy plus sign.