From svenpanne at gmail.com  Thu Sep 17 15:55:30 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Thu, 17 Sep 2015 17:55:30 +0200
Subject: [HOpenGL] Fwd: Merging the OpenGLRaw and gl packages
In-Reply-To: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
Message-ID: <CANBN=mvxQyHi_=vUK+TOJjb=t+30pT9VhRf8qL6VRGU123dyqg@mail.gmail.com>

[ 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 <svenpanne at gmail.com>
Date: 2015-09-13 22:13 GMT+02:00
Subject: Merging the OpenGLRaw and gl packages
To: Haskell Cafe <haskell-cafe at haskell.org>


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hopengl/attachments/20150917/b43d3cdd/attachment.html>

From bkomuves at gmail.com  Thu Sep 17 17:00:56 2015
From: bkomuves at gmail.com (Balazs Komuves)
Date: Thu, 17 Sep 2015 19:00:56 +0200
Subject: [HOpenGL] Fwd: Merging the OpenGLRaw and gl packages
In-Reply-To: <CANBN=mvxQyHi_=vUK+TOJjb=t+30pT9VhRf8qL6VRGU123dyqg@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
 <CANBN=mvxQyHi_=vUK+TOJjb=t+30pT9VhRf8qL6VRGU123dyqg@mail.gmail.com>
Message-ID: <CAHZd2pnya8LXrQNHM6u4eNNYL5cga-m1+EHLsDRbN3JjW9LB6w@mail.gmail.com>

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 <svenpanne at gmail.com> 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 <svenpanne at gmail.com>
> Date: 2015-09-13 22:13 GMT+02:00
> Subject: Merging the OpenGLRaw and gl packages
> To: Haskell Cafe <haskell-cafe at haskell.org>
>
>
> 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
> HOpenGL at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/hopengl
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hopengl/attachments/20150917/962196a4/attachment.html>

From svenpanne at gmail.com  Wed Sep 30 14:29:12 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 30 Sep 2015 16:29:12 +0200
Subject: [HOpenGL] Merging the OpenGLRaw and gl packages
In-Reply-To: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
Message-ID: <CANBN=msTe-=fB6p89-4+iBQ3vj_8GY-o-j1Ee9iH2-DGTc_itg@mail.gmail.com>

After some discussions via email and via the Wiki (
https://github.com/haskell-opengl/OpenGLRaw/wiki/Merging-OpenGLRaw-and-gl),
I've already made a few changes to OpenGLRaw, bringing it closer to 'gl'.
These are fully backwards compatible, because they mainly consist of
improvements in the generated documentation and the addition of various
extension-related retrieval functions. Before I move on and introduce
breaking changes, I'd like to hear some opinions about a few items which
might need some more discussion:

  * Should OpenGLRaw use pattern synonyms? (Probably yes, but note that
this implies GHC >= 7.8.1)

  * Should OpenGLRaw use the 'Half' type from the 'half' package? (Probably
yes, but again this implies GHC 7.8.1)

  * Should the incredibly long 'Graphics.Rendering.OpenGL.Raw' module
prefix be replaced by the more palatable 'Graphics.GL.Raw'? (Probably yes)

More details and other already resolved and/or less controversial items can
be found on the Wiki. The plan is to release a new OpenGLRaw version soon
(3.0), after which Edward and Gabr?el Arth?r can deprecate the 'gl' package
(if they like).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hopengl/attachments/20150930/8c70fd1f/attachment.html>

From svenpanne at gmail.com  Wed Sep 30 17:38:26 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 30 Sep 2015 19:38:26 +0200
Subject: [HOpenGL] [Haskell-cafe] Merging the OpenGLRaw and gl packages
In-Reply-To: <CAJ5riwL1xJeTaxueoV6bbH+t6fY04B2kPFyzbUG4c3iLApzrAA@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
 <CANBN=msTe-=fB6p89-4+iBQ3vj_8GY-o-j1Ee9iH2-DGTc_itg@mail.gmail.com>
 <CAJ5riwL1xJeTaxueoV6bbH+t6fY04B2kPFyzbUG4c3iLApzrAA@mail.gmail.com>
Message-ID: <CANBN=mt-tWyE=t1gJ9_G2sZZH9KSJ58hRTeJpgW5knDFMLCsJg@mail.gmail.com>

2015-09-30 17:02 GMT+02:00 Casey McCann <cam at uptoisomorphism.net>:

> On Wed, Sep 30, 2015 at 10:29 AM, Sven Panne <svenpanne at gmail.com> wrote:
> >   * Should OpenGLRaw use pattern synonyms? (Probably yes, but note that
> this
> > implies GHC >= 7.8.1)
> >
> >   * Should OpenGLRaw use the 'Half' type from the 'half' package?
> (Probably
> > yes, but again this implies GHC 7.8.1)
>
> 7.8.1 is, what, a year and a half old?
>
> I'm all for bleeding edge personally but not everyone feels that way,
> and that seems pretty severe relative to the benefits.
>

That's my biggest concern, too, and that's why I wanted to hear other
people's opinions: IMHO using pattern synonyms vs. plain old Haskell values
is to a large part just bikeshedding, at least in the trivial case at hand
where we talk about simple integral values. It basically boils down to the
question: Is

   foo x = case x of
     GL_BAR -> expr1
     GL_BAZ -> expr2
     _ -> expr3

really so much better than

   foo x
     | x == GL_BAR = expr1
     | x == GL_BAZ = expr2
     | otherwise = expr3

that we want to drop support for GHC < 7.8.1? Personally, I'm not
convinced, but if most other people think that it's OK, I'm willing to pay
the price for the sake of merging the packages. Edward claims that using
pattern synonyms will result in more efficient code, too, but I haven't
checked that. And even if it was: Perhaps GHC can be tweaked to treat both
versions above in the same way (I can see no reason why this shouldn't be
possible, but perhaps I'm wrong). Regarding readability: The version with
pattern synonyms *is* slightly more readable, but not so much that it would
warrant dropping slightly outdated GHCs.

Regarding the 'half' package: I've just seen that it should work with any
GHC 7.x now, so this decision can be decoupled from the pattern synonym
issue. Perhaps I should release a new, only slightly incompatible OpenGLRaw
version using 'half'? Although GLhalf is part of OpenGL core since 3.0, it
is only used in very few non-central places (GL_ARB_half_float_pixel,
GL_ARB_half_float_vertex, and GL_NV_half_float). So the resulting breakage
will probably be very low.

Regarding the module prefix: I'm not sure if it's worth making this
breaking change alone, probably this should only be done in conjunction
with the introduction of pattern synonyms. But other opinions would be
valuable here, too.

[...] As an aside regarding the wiki discussion, I don't really see how
> there's a sane way to have a combined low-level API for WebGL and full
> OpenGL. [...]


As already mentioned in more detail on the Wiki, the plan to combine OpenGL
and WebGL in a single package is doomed: Different values for the same
token, different contents of the extensions, different ways to retrieve the
entry points. It's a pity, but that's how it is...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hopengl/attachments/20150930/f8a31548/attachment.html>