Revamping the numeric classes

[Jerzy Karczmarczuk]

First, a general remark which has nothing to do with Num.

PLEASE WATCH YOUR DESTINATION ADDRESSES
People send regularly their postings to haskell-cafe with
several private receiver addresses, which is a bit annoying
when you click "reply all"...


Brian Boutel after Dylan Thurston:

> > Why doesn't your argument show that all types should by instances of
> > Eq and Show?  Why are numeric types special?
> 
> Why do you think it does? I certainly don't think so.
> 
> The point about Eq was that a objection was raised to Num being a
> subclass of Eq because, for some numeric types, equality is undecidable.
> I suggested that Haskell equality could be undecidable, so (==) on those
> types could reflect the real situation. One would expect that it could
> do so in a natural way, producing a value of True or False when
> possible, and diverging otherwise. Thus no convincing argument has been
> given for removing Eq as a superclass of Num.
> 
> In general, if you fine-grain the Class heirarchy too much, the picture
> gets very complicated. If you need to define separate subclases of Num
> for those types which have both Eq and Show, those that only Have Eq,
> those than only have Show and those that have neither, not to mention
> those that have Ord as well as Eq and those that don't, and then for all
> the other distinctions that will be suggested, my guess is that Haskell
> will become the preserve of a few mathematicians and everyone else will
> give up in disgust. Then the likely result is that no-one will be
> interested in maintaining and developing Haskell and it will die.

Strange, but from the objectives mentioned in the last part of this 
posting (even if a little demagogic [insert smiley here if you wish])
I draw opposite conclusions.

The fact that the number of cases is quite large suggests that Eq, Show
and arithmetic should be treated as *orthogonal* issues, and treated
independently. 

If somebody needs Show for his favourite data type, he is free to
arrange
this himself. I repeat what I have already said: I work with functional
objects as mathematical entities. I want to add parametric surfaces, to
rotate trajectories. Also, to handle gracefully and legibly for those
simpletons who call themselves 'theoretical physicists', the arithmetic
of un-truncated lazy streams representing power series, or infinitely
dimensional differential algebra elements. Perhaps those are not 
convincing arguments for Brian Boutel. They are certainly so for me.

Num, with this forced marriage of (+) and (*) violates the principle
of orthogonality. Eq and Show constraints make it worse.

===

And, last, but very high on my check-list:

The implicit coercion of numeric constants: 3.14 -=->>  (fromDouble
3.14)
etc. is sick. (Or was; I still didn't install the last version of GHC,
and with Hugs it is bad). The decision is taken by the compiler
internally,
and it doesn't care at all about the fact that in my prelude 
I have eliminated the Num class and redefined fromDouble, fromInt, etc. 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Dylan Thurston terminates his previous posting about Num with:

> Footnotes:
> [1]  Except for the lack of abs and signum, which should be in some
> other class.  I have to think about their semantics before I can say
> where they belong.

Now, signum and abs seem to be quite distincts beasts. Signum seem to
require Ord (and a generic zero...).

Abs from the mathematical point of view constitutes a *norm*. Now,
frankly, I haven't the slightest idea how to cast this concept into
Haskell class hierarchy in a sufficiently general way...

I'll tell you anyway that if you try to "sanitize" the numeric
classes, if you separate additive structures and the multiplication,
if you finally define abstract Vectors over some field of scalars,
and if you demand the existence of a generic normalization for your
vectors, than *most probably* you will need multiparametric classes
with dependencies. 


Jerzy Karczmarczuk
Caen, France