[Haskell-cafe] [Haskell] Defining Cg, HLSL style vectors in Haskell

Brian Hulley brianh at metamilk.com
Tue Nov 28 14:25:35 EST 2006

Slavomir Kaslev wrote:
> I have to define a couple of float2, float3, float4 Cg, HLSL style
> vectors in Haskell. At first I was tempted to make them instances of
> Num, Floating, RealFrac, etc. but some of the functions defined in
> those classes have no sense for vectors.

I'd suggest that this implies that these classes are not suitable for 

> One such example is signum from class Num.
> There are several workarounds for this. One may come up with some
> meaning for vectors of such functions, for example:
> instance Num Float3 where
>    .....
>    signum a | a == Float3 0 0 0 = 0
>                  | otherwise = 1

This looks a bit unnatural. Also, testing equality of Floats is not 
generally recommended.

> [snip]
> I know that I can scrap all those Num, Floating, RealFrac, etc.
> classes and define class Vector from scratch, but I really don't want
> to come up and use different names for +, -, etc. that will bloat the
> code.

While it may be tempting to want to use symbolic operators like + and -, 
these quickly become very confusing when more distinctions need to be made 
(eg between cross product, dot product, and scaling, or between transforming 
a position versus transforming a direction) so I'd argue that for 
readability descriptive names are better than symbols:

    class Num a => Vector v a where
        plus :: v a -> v a -> v a
        minus :: v a -> v a -> v a
        cross :: v a -> v a -> v a
        dot :: v a -> v a -> a
        scale :: a -> v a -> v a
        magSquared :: v a -> a

    class Num a => Transform mat vec a where
        transformPosition :: mat a -> vec a -> vec a
        transformDirection :: mat a -> vec a -> vec a

    instance Num a => Transform Mat44 Vec4 a where
        -- ...

If you're doing matrix transformations, you might also like to consider 
using separate PositionN and DirectionN types instead of VecN to make use of 
the type system to catch some math bugs but I haven't looked into this 
myself yet so I don't know whether this would be practical or not.

Best regards,

More information about the Haskell-Cafe mailing list