[Haskell-cafe] Merging the OpenGLRaw and gl packages

[Sven Panne]

2016-01-10 21:56 GMT+01:00 Oliver Charles <ollie at ocharles.org.uk>:

> 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.
>
GL_LINEAR as a parameter is sometimes used as a GLenum (see e.g.
glBlitFramebuffer) and sometimes as a GLint (see
e.g. glGetTextureParameteriv), and there is no clear winner.


> 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.
>
Yes, using a debug context + glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS)
+ glDebugMessageCallback during development is always a good idea. Apart
from the stateful nature of the API ("this and that is only allowed when we
are in state foobar etc."), the whole notion of profiles and extensions
makes it fundamentally impossible to have a 100% type-safe API. You can't
even e.g. statically tell which set of enums is allowed as a parameter for
a given function.

> I think OpenGLRaw would be more practical with gl-style polymorphic
> patterns
>
As I said in my previous email: Whenever you use the OpenGL API directly
(be it via OpenGLRaw or gl), you *will* have lots of 'fromIntegral's, and
the patterns don't make much of a difference. A quick grep showed that your
SSAO-example project has 33 fromIntegral calls, and only 2 are caused by
the patterns being monomorphic. The luminance package is even more extreme
in this respect: It contains 188 fromIntegral calls, and only 2 are caused
by the monomorphic patterns. (I may be off by small amount, but that
doesn't really change the fact.) So in a nutshell: This is a non-issue in
practice and mostly a bikeshedding discussion, and I won't change that
aspect of the binding.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160111/04b0f0f2/attachment.html>