Re: [Haskell-cafe] ANN: Haskell OpenGL package updates
Edward Kmett <[email protected]> Sun, 30 Oct 2011 12:18:34 -0400
| Newsgroups | gmane.comp.lang.haskell.hopengl,gmane.comp.lang.haskell.cafe |
|---|---|
| Message-ID | <CAJumaK8N8GAsFPX0cddV+1o=LvE8O9S7dLni5inMSJ4DL8-9Wg@mail.gmail.com> |
--===============5055412443174174125== Content-Type: multipart/alternative; boundary=f46d044517b954021c04b08679de --f46d044517b954021c04b08679de Content-Type: text/plain; charset=UTF-8 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 <[email protected]> wrote: > On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett <[email protected]> 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 > --f46d044517b954021c04b08679de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The biggest problem with the RULES based approach is that if you are in a c= ontext where the RULES don't or can't fire, then your semantics sil= ently change. This leads to subtle bugs which only show up in ghci, etc.<br= > <br>On Friday, October 28, 2011, Jason Dagit <<a href=3D"mailto:dagitj@g= mail.com">[email protected]</a>> wrote:<br>> On Fri, Oct 28, 2011 at 2= :07 PM, Edward Kmett <<a href=3D"mailto:[email protected]">[email protected]= om</a>> wrote:<br> >> Jason,<br>>> Thank you for taking ownership of HOpenGL!<br>&= gt;<br>> Thanks!<br>><br>>> I would like to make a formal reque= st 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 pointles= sly 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 ti= ght loops in exchange for<br> >> implementation freedom the current OpenGL bindings do not use on a= ny<br>>> platform.<br>><br>> Yes, it's a real problem. =C2= =A0I 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 "rea= lToFrac/a->GLfloat" realToFrac =3D \x -> GLfloat (realToFrac x)<= br>> #-}<br>> {-# RULES "realToFrac/GLfloat->a" realToFr= ac =3D \(GLfloat x) -> realToFrac x<br> > #-}<br>><br>> That one helps a lot for most people.<br>><br>&= gt; Someone made a libraries proposal that also helps the conversion<br>>= ; situation but I don't have the details handy at the moment.<br>><b= r> > If you read here, I'd like to get some MArray support in and I thi= nk<br>> it's possible, although I haven't the idea I proposed ye= t:<br>> <a href=3D"http://www.haskell.org/pipermail/haskell-cafe/2011-Ma= rch/090511.html">http://www.haskell.org/pipermail/haskell-cafe/2011-March/0= 90511.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 w= ith exposing all of OpenGLRaw. =C2=A0I think we just<br>> need to suffic= iently document the "internal" bits so that only people<br> > who absolutely need them will use them. =C2=A0That's how I see Byt= eString<br>> and it seems to be working there.<br>><br>> Thanks fo= r your suggestion (and your pull request on github, yay for<br>> collabo= rative tools!).<br> ><br>> Jason<br>> --f46d044517b954021c04b08679de-- --===============5055412443174174125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOpenGL mailing list [email protected] http://www.haskell.org/mailman/listinfo/hopengl --===============5055412443174174125==--