[HOpenGL] GLdouble/GLfloat vs. Double/Float

[Sven Panne]

Andre W B Furtado wrote:
 > [...] Can I always assume that the result of f will be the same of g (I
 > mean, no truncations, rounding, etc.)?

Strictly speaking, the answer is no: The OpenGL spec only says that GLfloat
is at least 32bit and GLdouble is at least 64bit, whatever this should mean
exactly, see table 2.2 in

    http://www.opengl.org/developers/documentation/version1_3/glspec13.pdf

On the other hand, the Haskell 98 report is less restrictive and leaves
everything as "implementation-defined", see

    http://haskell.org/onlinereport/basic.html#numbers

The only guarantee you have is that HOpenGL's GLfloat/GLdouble map to the
correct C types, but nothing more.

But the reality is not so bad after all: I'm not aware of any OpenGL
implementation where GLfloat/GLdouble are *not* mapped to float/double,
respectively, and GHC maps those to Float/Double, so everything is well.
Note that Hugs used to map both Float and Double to C's float, but I'm
not sure if it is doing still, and I'm even more ignorant of NHC98. :-}
In any case, HOpenGL's types are type synonyms and you still have the
type checker...

 > Do I have to use something like:
 >
 > f :: a -> (Double, Double)
 > f x = (realToFrac g1, realToFrac g2)
 >       where (g1,g2) = g x

To be on the safe side, yes. For GHC at least, there is no performance
penalty at all if GLfloat == Float / GLdouble == Double, because there are
RULES (see http://haskell.org/ghc/docs/latest/set/rewrite-rules.html) which
handle all combinations of Float and Double much smarter than the plain

    fromRational . toRational

Cheers,
    S.