Re: [HOpenGL] [Haskell-cafe] ANN: Haskell OpenGL package updates

The biggest problem with the RULES based approach is that if you are in a context where the RULES don't or can't fire, then your semantics silently change. This leads to subtle bugs which only show up in ghci, etc. On Friday, October 28, 2011, Jason Dagit wrote:

On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett wrote:

...

Jason, Thank you for taking ownership of HOpenGL!

Thanks!

...

I would like to make a formal request for there to be some way to get access to either Graphics.Rendering.OpenGL.Raw.Core31.TypesInternal or that Graphics.Rendering.OpenGL.Raw.Core31.Types re-export the newtype wrappers it places around CDouble and CFloat. As things stand the only way to work with them is to pointlessly round-trip through rational or pray that GHC is smart enough to automatically convert once it sees through the newtype, which it isn't, potentially costing me orders of magnitude of performance in tight loops in exchange for implementation freedom the current OpenGL bindings do not use on any platform.

Yes, it's a real problem. I think there are a couple directions we could move in (and some may not even be mutually exclusive).

Andy Gill created this workaround: {-# RULES "realToFrac/a->GLfloat" realToFrac = \x -> GLfloat (realToFrac x) #-} {-# RULES "realToFrac/GLfloat->a" realToFrac = \(GLfloat x) -> realToFrac x #-}

That one helps a lot for most people.

Someone made a libraries proposal that also helps the conversion situation but I don't have the details handy at the moment.

If you read here, I'd like to get some MArray support in and I think it's possible, although I haven't the idea I proposed yet: http://www.haskell.org/pipermail/haskell-cafe/2011-March/090511.html

Another thing we could do is find a different balance between newtypes and the C types.

I'm totally onboard with exposing all of OpenGLRaw. I think we just need to sufficiently document the "internal" bits so that only people who absolutely need them will use them. That's how I see ByteString and it seems to be working there.

Thanks for your suggestion (and your pull request on github, yay for collaborative tools!).

Jason