Re: Merging the OpenGLRaw and gl packages

--===============3837181670683411586==
Content-Type: multipart/alternative; boundary=047d7b8738b6ee067905290006c5

--047d7b8738b6ee067905290006c5
Content-Type: text/plain; charset=UTF-8

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.

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

<div dir=3D"ltr">After some discussions and looking at the diffs needed to =
make the `luminance` package and Oliver Charles&#39; SSAO-example use OpenG=
LRaw instead of gl, I decided to change the types of GL_TRUE and GL_FALSE f=
rom GLenum to GLboolean. When these enums are used as parameters, their typ=
e is almost always GLboolean, with glClampColor being the only exception. S=
ome general retrieval functions like glProgramiv return boolean values as G=
Lint, 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 pattern=
s were more polymorphic. After several decades of computer science and havi=
ng seen tons of bugs caused by them, I have a strong aversion to implicit c=
onversions, so I&#39;m still convinced that the monomorphic enums are the r=
ight thing. :-)<div><br></div><div>I made a new release of OpenGLRaw (<a hr=
ef=3D"https://github.com/haskell-opengl/OpenGLRaw/releases/tag/v3.1.0.0">ht=
tps://github.com/haskell-opengl/OpenGLRaw/releases/tag/v3.1.0.0</a>), which=
 in addition to this typing change contains some &quot;mkFoo&quot; synonyms=
 for the &quot;makeFoo&quot; functions, too, a difference between OpenGLRaw=
 and gl I didn&#39;t notice earlier.<br></div><div><br></div><div>Cheers,</=
div><div>=C2=A0 =C2=A0S.</div></div>

--047d7b8738b6ee067905290006c5--

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

--===============3837181670683411586==--