Peter Verswyvelen wrote:
I don't want to use the GL types directly since the OpenGL renderer is not exposes in the rest of the API. I was hoping that realToFrac would be a nop in case it would be identical to an unsafeCoerce.
This is one of the areas where the H98 spec is broken. Not only is the H98 realToFrac slow, it is also incorrect for Double and Float since those types contain transfinite values which cannot be represented in Rational, but which can be converted successfully when mapping from Double to Float and vice versa. Once you find a suitable function definition, I suggest using the RealToFrac class[1]. I don't know the GL types to know what the definition should be, but there is a class already out there to help deal with this kind of problem both efficiently and correctly.
I guess one could make rules for that, but this tickets makes me wander if that really works: http://hackage.haskell.org/trac/ghc/ticket/1434
The RealToFrac class solves Henning's performance complaint as well. Because of the correctness issues involved here, I strongly advocate *against* the use of rewrite rules for trying to optimize the H98 definition of realToFrac. The semantics of the program where transfinite values are involved should not be contingent on the whims of how the compiler feels today. Even though IEEE-754 is fuzzy to begin with, altering whether things fall into or out of transfinite states is grossly inconsistent. And in case you're worried about "extraneous dependencies", the logfloat package is portable and has negligable dependencies. Moreover it also provides a number of other facilities for dealing with IEEE-754 numbers correctly. Some examples include: * correcting the definitions of isInfinite and isNaN used in Hugs, * defining a class for partial orders (since neither Double nor Float is actually a total order due to NaN), * and a class for types with explicit representations of transfinite values, which in turn allows for a modified definition of log which has log 0 == negativeInfinity (other Floating methods could be extended similarly). [0]http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat [1]http://hackage.haskell.org/packages/archive/logfloat/0.12.0.1/doc/html/Data-... -- Live well, ~wren