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.<br>
<br>On Friday, October 28, 2011, Jason Dagit <<a href="mailto:dagitj@gmail.com">dagitj@gmail.com</a>> wrote:<br>> On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br>
>> Jason,<br>>> Thank you for taking ownership of HOpenGL!<br>><br>> Thanks!<br>><br>>> I would like to make a formal request for there to be some way to get access<br>>> to either<br>>> Graphics.Rendering.OpenGL.Raw.Core31.TypesInternal<br>
>> or that<br>>> Graphics.Rendering.OpenGL.Raw.Core31.Types<br>>> re-export the newtype wrappers it places around CDouble and CFloat.<br>>> As things stand the only way to work with them is to pointlessly round-trip<br>
>> through rational or pray that GHC is smart enough to automatically convert<br>>> once it sees through the newtype, which it isn't, potentially costing me<br>>> orders of magnitude of performance in tight loops in exchange for<br>
>> implementation freedom the current OpenGL bindings do not use on any<br>>> platform.<br>><br>> Yes, it's a real problem. I think there are a couple directions we<br>> could move in (and some may not even be mutually exclusive).<br>
><br>> Andy Gill created this workaround:<br>> {-# RULES "realToFrac/a->GLfloat" realToFrac = \x -> GLfloat (realToFrac x)<br>> #-}<br>> {-# RULES "realToFrac/GLfloat->a" realToFrac = \(GLfloat x) -> realToFrac x<br>
> #-}<br>><br>> That one helps a lot for most people.<br>><br>> Someone made a libraries proposal that also helps the conversion<br>> situation but I don't have the details handy at the moment.<br>><br>
> If you read here, I'd like to get some MArray support in and I think<br>> it's possible, although I haven't the idea I proposed yet:<br>> <a href="http://www.haskell.org/pipermail/haskell-cafe/2011-March/090511.html">http://www.haskell.org/pipermail/haskell-cafe/2011-March/090511.html</a><br>
><br>> Another thing we could do is find a different balance between newtypes<br>> and the C types.<br>><br>> I'm totally onboard with exposing all of OpenGLRaw. I think we just<br>> need to sufficiently document the "internal" bits so that only people<br>
> who absolutely need them will use them. That's how I see ByteString<br>> and it seems to be working there.<br>><br>> Thanks for your suggestion (and your pull request on github, yay for<br>> collaborative tools!).<br>
><br>> Jason<br>>