I'm not really convinced by this. This change introduced an inconsistency
and duplication, but doesn't really solve the problem. I already found
another enum that has this problem (GL_LINEAR), and I hardly suggest
introducing GL_LINEAR to work around that.
While I agree that OpenGL is barely typed *statically*, there is a lot of
runtime type checking. In practice o always develop with KHR debug as an
extension or replay via apitrace, and this always checks ebum values for
validity.
I think OpenGLRaw would be more practical with gl-style polymorphic
patterns
On Sun, 10 Jan 2016 7:43 pm Sven Panne
After some discussions and looking at the diffs needed to make the `luminance` package and Oliver Charles' SSAO-example use OpenGLRaw instead of gl, I decided to change the types of GL_TRUE and GL_FALSE from GLenum to GLboolean. When these enums are used as parameters, their type is almost always GLboolean, with glClampColor being the only exception. Some general retrieval functions like glProgramiv return boolean values as GLint, but that seems to be the rarer use case. OpenGL is very loosely typed, so you will have to use some fromIntegral calls, even if the enum patterns were more polymorphic. After several decades of computer science and having seen tons of bugs caused by them, I have a strong aversion to implicit conversions, so I'm still convinced that the monomorphic enums are the right thing. :-)
I made a new release of OpenGLRaw ( https://github.com/haskell-opengl/OpenGLRaw/releases/tag/v3.1.0.0), which in addition to this typing change contains some "mkFoo" synonyms for the "makeFoo" functions, too, a difference between OpenGLRaw and gl I didn't notice earlier.
Cheers, S. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe