Re: Merging the OpenGLRaw and gl packages

--===============3582993250798188701==
Content-Type: multipart/alternative; boundary=001a114028a62ead9d0529010f49

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

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 <[email protected]> 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
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

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

<p dir=3D"ltr">I&#39;m not really convinced by this. This change introduced=
 an inconsistency and duplication, but doesn&#39;t really solve the problem=
. I already found another enum that has this problem (GL_LINEAR), and I har=
dly suggest introducing GL_LINEAR to work around that.</p>
<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>
<p dir=3D"ltr">I think OpenGLRaw would be more practical with gl-style poly=
morphic patterns </p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, 10 Jan 2016 7:43 pm=
=C2=A0Sven Panne &lt;<a href=3D"mailto:[email protected]">svenpanne@gmail=
.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">After some discussions and looking at the diffs needed to make the `lumin=
ance` package and Oliver Charles&#39; SSAO-example use OpenGLRaw instead of=
 gl, I decided to change the types of GL_TRUE and GL_FALSE from GLenum to G=
Lboolean. When these enums are used as parameters, their type is almost alw=
ays GLboolean, with glClampColor being the only exception. Some general ret=
rieval 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 h=
ave to use some fromIntegral calls, even if the enum patterns were more pol=
ymorphic. 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&#39;m still convinced that the monomorphic enums are the right thing. :-)=
<div><br></div><div>I made a new release of OpenGLRaw (<a href=3D"https://g=
ithub.com/haskell-opengl/OpenGLRaw/releases/tag/v3.1.0.0" target=3D"_blank"=
>https://github.com/haskell-opengl/OpenGLRaw/releases/tag/v3.1.0.0</a>), wh=
ich in addition to this typing change contains some &quot;mkFoo&quot; synon=
yms for the &quot;makeFoo&quot; functions, too, a difference between OpenGL=
Raw and gl I didn&#39;t notice earlier.<br></div><div><br></div><div>Cheers=
,</div><div>=C2=A0 =C2=A0S.</div></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Haskell-Cafe@=
haskell.org</a><br>
<a href=3D"http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" r=
el=3D"noreferrer" target=3D"_blank">http://mail.haskell.org/cgi-bin/mailman=
/listinfo/haskell-cafe</a><br>
</blockquote></div>

--001a114028a62ead9d0529010f49--

--===============3582993250798188701==
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

--===============3582993250798188701==--