Num is such a fat and greedy class

The following observations are not new, insightful, or gracious, but I was lusting after the innocent +,-,* operators for my own evil ends and was mildly curious why... Num is such a fat and greedy class. If you want to marry Cinderella, you have to take her ugly stepsisters too. 1) Groups may only want to define addition. Why can't they use + (instead of <+>, >++++?&**+>, or other such perversion)? 2) Affine spaces have a (-) but no (+). Worse, the signature might be (-) :: Point -> Point -> Vector, which doesn't unify with (a -> a -> a). Wouldn't the following be more useful/general? class Subtraction a b | a -> b where (-) :: a -> a -> b Or would this require needless type annotation for the common subset of (a -> a -> a) instances? 3) Quaternions have no signum, unit quaternions have (*), (/) but no (+) or (-), abs would have a different signatures (Quaternion -> Double) which doesn't unify with (a -> a), and fields cannot be scaled with (*) as in (*) :: (Field f) => Double -> f -> f Would it not make sense to put each of these operators (division too) into their own individual superclasses that Num inherits? My (obviously naive) philosophy about type classes is that operations should be bundled only when they are mutually recursive (i.e. there is more than one useful minimal definition). If there is just one minimal set of operations, they can be in their own parent class too. Then again, I should get over my lust and stick with my own operators <+++++++++>, <---------------------->, and <*******>. Not too pretty, but they have a wonderful personality all their own! Dan

On Fri, Dec 08, 2006 at 12:06:05PM -0800, Dan Weston wrote:
Would it not make sense to put each of these operators (division too) into their own individual superclasses that Num inherits? My (obviously naive) philosophy about type classes is that operations should be bundled only when they are mutually recursive (i.e. there is more than one useful minimal definition). If there is just one minimal set of operations, they can be in their own parent class too.
In many ways, this would be nice. But on the other hand, in languages with free overloading of operators, code can get highly obfuscated as a result, since everything overloads +. I actually like how Haskell takes a somewhat more principled approach to the Num class, although it is limiting at times. On the other hand, of John Meacham's class synonyms proposal makes it into Haskell', maybe we'll see some dissolution of Num... -- David Roundy Department of Physics Oregon State University

On Fri, 8 Dec 2006, Dan Weston wrote:
1) Groups may only want to define addition. Why can't they use + (instead of <+>, >++++?&**+>, or other such perversion)?
http://darcs.haskell.org/numericprelude/src/Algebra/Monoid.hs
2) Affine spaces have a (-) but no (+). Worse, the signature might be (-) :: Point -> Point -> Vector, which doesn't unify with (a -> a -> a).
yet to come
3) Quaternions have no signum, unit quaternions have (*), (/) but no (+) or (-), abs would have a different signatures (Quaternion -> Double) which doesn't unify with (a -> a), and fields cannot be scaled with (*) as in (*) :: (Field f) => Double -> f -> f
http://darcs.haskell.org/numericprelude/src/Number/Quaternion.hs -> norm
participants (3)
-
Dan Weston
-
David Roundy
-
Henning Thielemann