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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
