I made very little contribution to the decision (just submitting an issue on github a while ago), but I'm very positive about the decision to switch to type synonyms instead of newtypes. In my experience, the newtypes added an inconvenience that seemed to imply that the only safe way to convert between GL* types and their corresponding C* types is to use fromIntegral/realToFrac, which can be *very* inconvenient, especially if your data is in a Ptr (as OpenGL often expects for anything but the fixed-function pipeline). When binding to C libraries, you have to create wrappers around your functions to convert between GL types and C types (provided they use C types and their GL typedefs), if you buy into GL types truly being different. A specific problem I ran into was (see ) that GLchar being a newtype meant that I had to use castPtr to convert to and from CString or Ptr CString to Ptr (Ptr GLchar). On https://github.com/haskell-opengl/OpenGLRaw/pull/11 is my issue. Jason Dagit's response is probably of interest to you as well. As for more modern OpenGL things, for my recent game (that excusively used "modern" OpenGL, aside from glRaster* to draw text with ftgl), I made some nice wrappers around OpenGL things, that had no overhead while still being more than just convenience wrappers (something that can't be said about OpenGL, the package, today), and I'd like to get them into a package sometime, when I have more time. Mike On Mon, Jul 22, 2013 at 7:23 PM, Sven Panne wrote:

After a few HOpenGL-free years caused by personal and job-related circumstances, I'd like to work on this again. First of thanks to all the people involved in keeping the binding alive, especially Jason! Having the packages in the Haskell platform is simply great, because it improves the visibility of the binding a lot and will keep new users (and new bug reports ;-) coming.

I've browsed through the mailing list archives, so here are a few miscellaneous remarks:

* The StateVar/Tensor/ObjectName packages are now in the OpenGL package itself (in a different namespace), and the previous standalone packages are still available, too. Although I don't think it is a perfect solution, it was probably done to get the OpenGL packages into the Haskell platform, right? If this was the motivation, I think the price to pay was well worth it. The OpenAL/ALUT packages use the assimilated packages, too, so I should probably update the former ones to use the latter ones. This will introduce a dependency of OpenAL/ALUT on OpenGL, something I wanted to avoid. But I think there are very few programs using OpenAL without OpenGL, and the latter is now universally available via the Haskell platformm, so this should be the right way to proceed.

* What was the exact motivation for using type synonyms instead of the former renamings (newtypes) for the OpenGL types? Were there any *real* problems or only potential/hypothetical ones? I am a bit torn between those alternatives, so I'd like to learn the experience of other people, including their opinions.

* The examples have bit-rotted, e.g. SmoothOpenGL3.hs yields an InvalidOperation in triangle's vertexAttribPointer calls, 'catch' should probably be replaced by Control.Exception.{catch,IOException}, etc. Apart from fixing them, having GLUT versions of nehe-tuts in the GLUT package would be great. I really like the idea of GLUT being a one-stop-shop for tons of examples regarding the usage of the OpenGL/OpenGLRaw packages.

* Currently the binding doesn't work out-of-the box with ghci on Ubuntu 12.04 if you have NVIDIA drivers installed in addition to the Mesa ones. I have an ugly fix (adding /usr/lib/nvidia/current to OpenGLRaw's library-dirs), but I'd like to solve this more cleanly. More about this in a separate mail.

* Finally Khronos has released the OpenGL registry in a less braindead format ( http://www.opengl.org/discussion_boards/showthread.php/181927-New-XML-based-... ), so there is a good chance now that the OpenGLRaw package can be completely autogenerated, something I wanted to do for ages. Judging from the HOpenGL mailing list, Lars is already looking into it, so let's coordinate our efforts here, preferably in a separate mail thread. My main concerns here are: Include the generator (plus pre-generated bindings) in the OpenGLRaw package, it really belongs there. Don't put anything clever into OpenGLRaw, it should really, really be a plain, straightforward 1:1 mapping of the registry. No name mangling, structural modifications etc. apart from things automatically derivable from the XML registry. A big question remains: Can we generate the (un-)marshaling functions already in OpenGLRaw? The XML registry has <groups>/<group> tags, but I fear that they are still too incomplete/incorrect to be of any use for the Haskell binding. On the positive side, I think that it should be possible to upstream changes to the registry to make it more useful in general. I had contact with Jon Leech in the past, and he has always been very open and helpful.

* Given the fact that OpenGL 4.3 is quite different from OpenGL in the "old days", there are quite a few design decisions in the OpenGL (convenience) package that I would do differently nowadays. But I think with the feedback from the community we can gradually tweak this layer to something more useful and up-to-date. Perhaps we can somehow re-arrange things to be more in line with OpenGL versions/profiles, but whatever we do, we should not drop support for "old skool" OpenGL, there are *tons* of tutorials, books and courses relying on it, and even NVIDIA has effectively promised to support this forever.

Cheers, S.

_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl

On Mon, Jul 22, 2013 at 2:23 AM, Sven Panne wrote:

After a few HOpenGL-free years caused by personal and job-related circumstances, I'd like to work on this again. First of thanks to all the people involved in keeping the binding alive, especially Jason! Having the packages in the Haskell platform is simply great, because it improves the visibility of the binding a lot and will keep new users (and new bug reports ;-) coming.

Welcome back!

I've browsed through the mailing list archives, so here are a few miscellaneous remarks:

* The StateVar/Tensor/ObjectName packages are now in the OpenGL package itself (in a different namespace), and the previous standalone packages are still available, too. Although I don't think it is a perfect solution, it was probably done to get the OpenGL packages into the Haskell platform, right?

Yes, that is exactly why. I prefer to have the packages split up.

If this was the motivation, I think the price to pay was well worth it. The OpenAL/ALUT packages use the assimilated packages, too, so I should probably update the former ones to use the latter ones. This will introduce a dependency of OpenAL/ALUT on OpenGL, something I wanted to avoid. But I think there are very few programs using OpenAL without OpenGL, and the latter is now universally available via the Haskell platformm, so this should be the right way to proceed.

That's probably right. It looks like OpenAL is now proprietary. (See license information: http://en.wikipedia.org/wiki/OpenAL). So I don't really know if it makes sense to bother with OpenAL bindings. I know several folks have stopped considering it completely.

* What was the exact motivation for using type synonyms instead of the former renamings (newtypes) for the OpenGL types? Were there any *real* problems or only potential/hypothetical ones? I am a bit torn between those alternatives, so I'd like to learn the experience of other people, including their opinions.

It's a mix. Andy Gill sent patches at one point that introduce a {-# RULE #-} that removed the conversion, it looked like this: {-# RULES "realToFrac/a->GLfloat" realToFrac = \x -> GLfloat (realToFrac x) #-} {-# RULES "realToFrac/GLfloat->a" realToFrac = \(GLfloat x) -> realToFrac x #-} He did that because it had very real performance implications. The default implementation of realToFrac goes through Rational :( With the type synonyms it's trivial to use the GL types with unboxed Data.Vectors. With the newtype wrappers you have to dig pretty deep into GHC to get the unboxing magic. To me that sounded like a maintenance headache. The other benefit is that the C types have more instances in the standard library than the GL types. So that makes it just that much easier to use them with other libraries (for example, vector-space). Admittedly this issue is minor. As we could provide a separate package with common instances or make sure to include all the RULES necessary to make it efficient to convert.

* The examples have bit-rotted, e.g. SmoothOpenGL3.hs yields an InvalidOperation in triangle's vertexAttribPointer calls, 'catch' should probably be replaced by Control.Exception.{catch,IOException}, etc. Apart from fixing them, having GLUT versions of nehe-tuts in the GLUT package would be great. I really like the idea of GLUT being a one-stop-shop for tons of examples regarding the usage of the OpenGL/OpenGLRaw packages.

Ah, that would be my fault. I haven't been updating the examples. I don't like GLUT for various reasons. For example, the translation of the nehe-tuts that I maintain use OpenGLRaw and GLFW-b instead of OpenGL and GLUT.

* Currently the binding doesn't work out-of-the box with ghci on Ubuntu 12.04 if you have NVIDIA drivers installed in addition to the Mesa ones. I have an ugly fix (adding /usr/lib/nvidia/current to OpenGLRaw's library-dirs), but I'd like to solve this more cleanly. More about this in a separate mail.

We should fix that.

* Finally Khronos has released the OpenGL registry in a less braindead format (http://www.opengl.org/discussion_boards/showthread.php/181927-New-XML-based-...), so there is a good chance now that the OpenGLRaw package can be completely autogenerated, something I wanted to do for ages. Judging from the HOpenGL mailing list, Lars is already looking into it, so let's coordinate our efforts here, preferably in a separate mail thread. My main concerns here are: Include the generator (plus pre-generated bindings) in the OpenGLRaw package, it really belongs there. Don't put anything clever into OpenGLRaw, it should really, really be a plain, straightforward 1:1 mapping of the registry. No name mangling, structural modifications etc. apart from things automatically derivable from the XML registry. A big question remains: Can we generate the (un-)marshaling functions already in OpenGLRaw? The XML registry has <groups>/<group> tags, but I fear that they are still too incomplete/incorrect to be of any use for the Haskell binding. On the positive side, I think that it should be possible to upstream changes to the registry to make it more useful in general. I had contact with Jon Leech in the past, and he has always been very open and helpful.

Sounds good.

* Given the fact that OpenGL 4.3 is quite different from OpenGL in the "old days", there are quite a few design decisions in the OpenGL (convenience) package that I would do differently nowadays. But I think with the feedback from the community we can gradually tweak this layer to something more useful and up-to-date. Perhaps we can somehow re-arrange things to be more in line with OpenGL versions/profiles, but whatever we do, we should not drop support for "old skool" OpenGL, there are *tons* of tutorials, books and courses relying on it, and even NVIDIA has effectively promised to support this forever.

That's fine with me. Send me your Github username and I can give you a commit bit in the haskell-opengl organization. Thanks! Jason

On Mon, Jul 22, 2013 at 11:23 AM, Sven Panne wrote:

After a few HOpenGL-free years caused by personal and job-related circumstances, I'd like to work on this again. First of thanks to all the people involved in keeping the binding alive, especially Jason! Having the packages in the Haskell platform is simply great, because it improves the visibility of the binding a lot and will keep new users (and new bug reports ;-) coming.

I've browsed through the mailing list archives, so here are a few miscellaneous remarks:

* The StateVar/Tensor/ObjectName packages are now in the OpenGL package itself (in a different namespace), and the previous standalone packages are still available, too. Although I don't think it is a perfect solution, it was probably done to get the OpenGL packages into the Haskell platform, right? If this was the motivation, I think the price to pay was well worth it. The OpenAL/ALUT packages use the assimilated packages, too, so I should probably update the former ones to use the latter ones. This will introduce a dependency of OpenAL/ALUT on OpenGL, something I wanted to avoid. But I think there are very few programs using OpenAL without OpenGL, and the latter is now universally available via the Haskell platformm, so this should be the right way to proceed.

* What was the exact motivation for using type synonyms instead of the former renamings (newtypes) for the OpenGL types? Were there any *real* problems or only potential/hypothetical ones? I am a bit torn between those alternatives, so I'd like to learn the experience of other people, including their opinions.

* The examples have bit-rotted, e.g. SmoothOpenGL3.hs yields an InvalidOperation in triangle's vertexAttribPointer calls, 'catch' should probably be replaced by Control.Exception.{catch,IOException}, etc. Apart from fixing them, having GLUT versions of nehe-tuts in the GLUT package would be great. I really like the idea of GLUT being a one-stop-shop for tons of examples regarding the usage of the OpenGL/OpenGLRaw packages.

* Currently the binding doesn't work out-of-the box with ghci on Ubuntu 12.04 if you have NVIDIA drivers installed in addition to the Mesa ones. I have an ugly fix (adding /usr/lib/nvidia/current to OpenGLRaw's library-dirs), but I'd like to solve this more cleanly. More about this in a separate mail.

* Finally Khronos has released the OpenGL registry in a less braindead format (http://www.opengl.org/discussion_boards/showthread.php/181927-New-XML-based-...), so there is a good chance now that the OpenGLRaw package can be completely autogenerated, something I wanted to do for ages. Judging from the HOpenGL mailing list, Lars is already looking into it, so let's coordinate our efforts here, preferably in a separate mail thread. My main concerns here are: Include the generator (plus pre-generated bindings) in the OpenGLRaw package, it really belongs there. Don't put anything clever into OpenGLRaw, it should really, really be a plain, straightforward 1:1 mapping of the registry. No name mangling, structural modifications etc. apart from things automatically derivable from the XML registry. A big question remains: Can we generate the (un-)marshaling functions already in OpenGLRaw? The XML registry has <groups>/<group> tags, but I fear that they are still too incomplete/incorrect to be of any use for the Haskell binding. On the positive side, I think that it should be possible to upstream changes to the registry to make it more useful in general. I had contact with Jon Leech in the past, and he has always been very open and helpful.

* Given the fact that OpenGL 4.3 is quite different from OpenGL in the "old days", there are quite a few design decisions in the OpenGL (convenience) package that I would do differently nowadays. But I think with the feedback from the community we can gradually tweak this layer to something more useful and up-to-date. Perhaps we can somehow re-arrange things to be more in line with OpenGL versions/profiles, but whatever we do, we should not drop support for "old skool" OpenGL, there are *tons* of tutorials, books and courses relying on it, and even NVIDIA has effectively promised to support this forever.

Cheers, S.

_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl

A bit overtime (I've been incredibly busy with some other things) but welcome back! Some notes on generating. For OpenGLRaw I had build a generator which works with the old spec format. Discussion on starting to use it was at https://github.com/haskell-opengl/OpenGLRaw/issues/3 . Though with the new spec files the generator requires major overhaul. The starting point for this would be to parse the new format. For this I did start on a project https://github.com/Laar/opengl-xmlspec , but I've not had the time to work on it nor could I choose an xml library (it seems that there are too many of them out there, suggestions are welcome). Generating (un)marshalling code is quite a bit harder, but I think doable for quite some functions. From my experience on extending OpenGL to include version 3.0 I think that even more is possible. Though the question is then how much information the user would need to supply to a helper tool and how complex it should be. But before starting such project the OpenGLRaw generator should probably be finished and in use. Lars