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

[Edward Kmett]

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 <dagitj at gmail.com> wrote:
> On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett <ekmett at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/hopengl/attachments/20111030/eb0bde91/attachment.htm>