Re: Fwd: Merging the OpenGLRaw and gl packages

--===============0677635866474742336==
Content-Type: multipart/alternative; boundary=047d7b5da4cfd713f9051ff45b1b

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

Hello,

I skimmed through the Wiki, below are a few small comments.

I like the idea of merging the two packages, especially if the differences
are indeed that small. I'm a user of the higher-level OpenGL package,
instead of OpenGLRaw or gl, so I will be (hopefully...) not directly
affected, but still I'm interested in the Haskell OpenGL situation in
general (and sometimes OpenGL does not contain some feature, thus you have
to reach for the raw bindings).

Individual comments:

* Pattern synonyms: I usually don't like unnecessary language extensions,
but I can see the value of using pattern synonyms here (which is btw an
awesome language feature, it's just quite new and not (yet) "core haskell")

* exact GL types vs. generic numeric types: I see two issues with the
generic types. One, I'm never sure what kind of code GHC (and possibly
other compilers, in the future) will generate, there may be performance
regressions here. Two: Defaulting. You either need explicit type signatures
for constants (which is both ugly and easy to forget), or let GHC decide
what to default to, which may be for example Integer, causing serious
performance regressions in some programs. Because of these, I support the
exact types of OpenGLRaw and explicit conversions from the user (this is
one of the two points where I have a relatively strong opinion; but feel
free to educate me). Note that a "serious" user will most probably make an
abstraction layer anyway, which can then handle the conversions if
necessary.

* Half: I don't like unnecessary dependencies, but least Half does not
depend on anything else, so as long as it remains like that, I find it an
acceptable compromise.

* expanded enumerant groups in the docs: While these looks indeed useful, I
have to agree with Sven that they are incorrect as of now. So maybe some
new solution should be worked out here. (Also, clicking on the example, I
see 10+ lines of capital letter links with GL constant names, looks kind of
scary)

* XML build dependencies: I strongly agree with Sven that the ease of
building the library should be a priority, and it should not depend on
those hxt- packages.

* module names: "Graphics.GL.Ext.EXT.Foo looks like a hiccup" - indeed :)


Regards,
Balazs




On Thu, Sep 17, 2015 at 5:55 PM, Sven Panne <[email protected]> wrote:

> [ I forgot to add this mailing list in the initial mail... ]
>
> Edward and I already commented a bit on the Wiki, but I would really like
> to have some more input from users. Breaking an API shouldn't be done in a
> hurry and without feedback, so raise your voice! :-)
>
> ---------- Forwarded message ----------
> From: Sven Panne <[email protected]>
> Date: 2015-09-13 22:13 GMT+02:00
> Subject: Merging the OpenGLRaw and gl packages
> To: Haskell Cafe <[email protected]>
>
>
> Currently there are 2 similar packages on Hackage to access raw OpenGL
> functionality: OpenGLRaw and gl. Taking a closer look at them, it turns out
> that they are only superficially different and have a lot of things in
> common. This is a bit confusing for users, so it might make sense to merge
> those packages. Therefore I'd like to start a discussion how to do this in
> detail, collecting user feedback and opinions. I think that haskell-cafe is
> the right place for this discussion, while an accompanying wiki page is
> more suitable to collect the results. As a basis I started a page at
> https://github.com/haskell-opengl/OpenGLRaw/wiki/Merging-OpenGLRaw-and-gl,
> which is necessarily biased at the moment. ;-) It would be nice to hear
> your opinions about how the package should look like, what might be
> missing, what could be done better, which differences I forgot, etc.
>
> Cheers,
>    S.
>
>
>
> _______________________________________________
> HOpenGL mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/hopengl
>
>

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

<div dir=3D"ltr"><div><div><div><div><div><div><div><br></div>Hello,<br><br=
></div>I skimmed through the Wiki, below are a few small comments.<br><br><=
/div>I like the idea of merging the two packages, especially if the differe=
nces are indeed that small. I&#39;m a user of the higher-level OpenGL packa=
ge, instead of OpenGLRaw or gl, so I will be (hopefully...) not directly af=
fected, but still I&#39;m interested in the Haskell OpenGL situation in gen=
eral (and sometimes OpenGL does not contain some feature, thus you have to =
reach for the raw bindings).<br><br></div><div>Individual comments:<br></di=
v><div><br></div>* Pattern synonyms: I usually don&#39;t like unnecessary l=
anguage extensions, but I can see the value of using pattern synonyms here =
(which is btw an awesome language feature, it&#39;s just quite new and not =
(yet) &quot;core haskell&quot;)<br><br></div>* exact GL types vs. generic n=
umeric types: I see two issues with the generic types. One, I&#39;m never s=
ure what kind of code GHC (and possibly other compilers, in the future) wil=
l generate, there may be performance regressions here. Two: Defaulting. You=
 either need explicit type signatures for constants (which is both ugly and=
 easy to forget), or let GHC decide what to default to, which may be for ex=
ample Integer, causing serious performance regressions in some programs. Be=
cause of these, I support the exact types of OpenGLRaw and explicit convers=
ions from the user (this is one of the two points where I have a relatively=
 strong opinion; but feel free to educate me). Note that a &quot;serious&qu=
ot; user will most probably make an abstraction layer anyway, which can the=
n handle the conversions if necessary.<br><br></div>* Half: I don&#39;t lik=
e unnecessary dependencies, but least Half does not depend on anything else=
, so as long as it remains like that, I find it an acceptable compromise.<b=
r><br>* expanded enumerant groups in the docs: While these looks indeed use=
ful, I have to agree with Sven that they are incorrect as of now. So maybe =
some new solution should be worked out here. (Also, clicking on the example=
, I see 10+ lines of capital letter links with GL constant names, looks kin=
d of scary)<br><br></div>* XML build dependencies: I strongly agree with Sv=
en that the ease of building the library should be a priority, and it shoul=
d not depend on those hxt- packages.<br><div><br></div><div>* module names:=
 &quot;<code>Graphics.GL.Ext.EXT.Foo</code> looks like a hiccup&quot; - ind=
eed :)<br></div><div><br><br></div><div>Regards,<br></div><div>Balazs<br><b=
r><br><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Thu, Sep 17, 2015 at 5:55 PM, Sven Panne <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>[ I forgot to add this mailing list in the initial mail... ]</div><div><br=
></div><div>Edward and I already commented a bit on the Wiki, but I would r=
eally like to have some more input from users. Breaking an API shouldn&#39;=
t be done in a hurry and without feedback, so raise your voice! :-)</div><b=
r><div class=3D"gmail_quote">---------- Forwarded message ----------<br>Fro=
m: <b class=3D"gmail_sendername">Sven Panne</b> <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>=
&gt;</span><br>Date: 2015-09-13 22:13 GMT+02:00<br>Subject: Merging the Ope=
nGLRaw and gl packages<br>To: Haskell Cafe &lt;<a href=3D"mailto:haskell-ca=
[email protected]" target=3D"_blank">[email protected]</a>&gt;<br><br><=
br><div dir=3D"ltr"><div>Currently there are 2 similar packages on Hackage =
to access raw OpenGL functionality: OpenGLRaw and gl. Taking a closer look =
at them, it turns out that they are only superficially different and have a=
 lot of things in common. This is a bit confusing for users, so it might ma=
ke sense to merge those packages. Therefore I&#39;d like to start a discuss=
ion how to do this in detail, collecting user feedback and opinions. I thin=
k that haskell-cafe is the right place for this discussion, while an accomp=
anying wiki page is more suitable to collect the results. As a basis I star=
ted a page at <a href=3D"https://github.com/haskell-opengl/OpenGLRaw/wiki/M=
erging-OpenGLRaw-and-gl" target=3D"_blank">https://github.com/haskell-openg=
l/OpenGLRaw/wiki/Merging-OpenGLRaw-and-gl</a>, which is necessarily biased =
at the moment. ;-) It would be nice to hear your opinions about how the pac=
kage should look like, what might be missing, what could be done better, wh=
ich differences I forgot, etc.</div><div><br></div><div>Cheers,</div><div>=
=C2=A0 =C2=A0S.</div><div><br></div></div>
</div><br></div>
<br>_______________________________________________<br>
HOpenGL mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><br>
<a href=3D"http://mail.haskell.org/cgi-bin/mailman/listinfo/hopengl" rel=3D=
"noreferrer" target=3D"_blank">http://mail.haskell.org/cgi-bin/mailman/list=
info/hopengl</a><br>
<br></blockquote></div><br></div>

--047d7b5da4cfd713f9051ff45b1b--

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

_______________________________________________
HOpenGL mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/hopengl

--===============0677635866474742336==--