Re: Merging the OpenGLRaw and gl packages

--===============0195103316102266983==
Content-Type: multipart/alternative; boundary=001a113eaf320c890405290bc282

--001a113eaf320c890405290bc282
Content-Type: text/plain; charset=UTF-8

2016-01-10 21:56 GMT+01:00 Oliver Charles <[email protected]>:

> 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.

--001a113eaf320c890405290bc282
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2016=
-01-10 21:56 GMT+01:00 Oliver Charles <span dir=3D"ltr">&lt;<a href=3D"mail=
to:[email protected]" target=3D"_blank">[email protected]</a>&gt;</=
span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><p dir=3D"ltr">I&#39;m not really convinced by t=
his. This change introduced an inconsistency and duplication, but doesn&#39=
;t really solve the problem. I already found another enum that has this pro=
blem (GL_LINEAR), and I hardly suggest introducing GL_LINEAR to work around=
 that.</p></blockquote><div>GL_LINEAR as a parameter is sometimes used as a=
 GLenum (see e.g. glBlitFramebuffer) and sometimes as a GLint (see e.g.=C2=
=A0glGetTextureParameteriv), and there is no clear winner.<br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
<p dir=3D"ltr">While I agree that OpenGL is barely typed *statically*, ther=
e 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 v=
alues for validity.</p></blockquote><div>Yes, using a debug context + glEna=
ble(GL_DEBUG_OUTPUT_SYNCHRONOUS) +=C2=A0glDebugMessageCallback during devel=
opment is always a good idea. Apart from the stateful nature of the API (&q=
uot;this and that is only allowed when we are in state foobar etc.&quot;), =
the whole notion of profiles and extensions makes it fundamentally impossib=
le to have a 100% type-safe API. You can&#39;t even e.g. statically tell wh=
ich set of enums is allowed as a parameter for a given function.</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">
<p dir=3D"ltr">I think OpenGLRaw would be more practical with gl-style poly=
morphic patterns</p></blockquote><div>As I said in my previous email: Whene=
ver you use the OpenGL API directly (be it via OpenGLRaw or gl), you *will*=
 have lots of &#39;fromIntegral&#39;s, and the patterns don&#39;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 monomorphi=
c. 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&#39;t really change the fact.=
) So in a nutshell: This is a non-issue in practice and mostly a bikesheddi=
ng discussion, and I won&#39;t change that aspect of the binding.</div><div=
><br></div><div>Cheers,</div><div>=C2=A0 =C2=A0S.</div></div></div></div>

--001a113eaf320c890405290bc282--

--===============0195103316102266983==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

--===============0195103316102266983==--