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.