2013/7/22 Jason Dagit
[...]. 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.
As a previous maintainer of the OpenAL SI, this saddens me... :-( I didn't follow the OpenAL changes lately, but I should probably do that now. At least OpenAL Soft seems to be still alive, and it is the default implementation installed on my Ubuntu box. So it probably makes at least some sense to fix the OpenAL binding, and it shouldn't be too hard.
It's a mix. Andy Gill sent patches at one point [...] With the type synonyms it's trivial to use the GL types with unboxed Data.Vectors. [...] 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 [...]
All those reasons make sense, and other replies favored synonyms, too, so I think I am convinced now. :-) Thinking about it a bit more, the main use of the GL types is for OpenGLRaw, and there you are basically "driving without safety belts", anyway. So the little bit of additional type safety is probably not worth the trouble. The newtype hac^H^H^H technology originates from ancient times, when there was no distinction between OpenGL and OpenGLRaw, and there it made some sense.
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.
As a previous freeglut contributor, I am shocked! ;-) More seriously: Perhaps I can put GLUT versions of nehe-tuts into the GLUT package, if that's OK for you and I have time. Examples are still our best documentation, so the more there are, the better it is.
We should fix that.
I think the breakage with the NVIDIA drivers on Ubuntu are a result of http://ghc.haskell.org/trac/ghc/ticket/5289: The "fix" of using 'gcc --print-file-name' is basically wrong, because it doesn't mirror what gcc is actually doing during linking via ld. I think I'll comment on that issue in the bug tracker, because having to manually modify a Haskell package description every time one switches the GL implementation via update-alternatives is not the way to go.
Send me your Github username and I can give you a commit bit in the haskell-opengl organization.
Very surprisingly, it is "svenpanne". ;-) Cheers, S.