[Haskell-cafe] Merging the OpenGLRaw and gl packages

Oliver Charles ollie at ocharles.org.uk
Sun Jan 10 20:56:40 UTC 2016


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 <svenpanne at gmail.com> wrote:

> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160110/bd5f26e6/attachment.html>


More information about the Haskell-Cafe mailing list