[Haskell] Num is such a fat and greedy class

Lennart Augustsson lennart at augustsson.net
Fri Dec 8 20:05:54 EST 2006


Oh, come on.  It's not that bad.  Just start every module with
   import Prelude()
   import MyPrelude
that's what I do.  There's nothing sacred about the Prelude (except a  
few things used for special syntax).  It just happens to be in scope.

	-- Lennart

On Dec 8, 2006, at 15:04 , Dan Weston wrote:

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



More information about the Haskell mailing list