Proposal: Let OpenGL depend on the StateVar package

[Edward Kmett]

I have no particular objection to renaming the package -- though it isn't
my library.

We probably would not want to rename the actual types inside the package
though. (Moving them to a namespace that is less front-and-center, probably
shouldn't be a pain point though). If we bikeshed this to death the
proposal may get rejected by the maintainers as too big of an API change.
Having the existing module just re-export something supplied by an external
package is a small change.

OpenGL has a very large user base.

But that said, it isn't actually anything about OpenGL, so much as how to
manipulate a piece of IO-based state that is gettable/settable in an
external API. I'm working with a bunch of ugly imperative libraries these
days where I have such concerns, OpenEXR, SDL, etc. all expose similar
imperative getter/setter APIs -- none of which have anything in particular
to do with OpenGL, so the name OpenGL-utils is pretty bad, since it'd be
for stuff you can use when you don't or can't depend on OpenGL, that OpenGL
just happens to want too.

-Edward

On Wed, Oct 22, 2014 at 1:44 PM, Don Stewart <dons00 at gmail.com> wrote:

> Previous problems with StateVar apply -  name likely to mislead users into
> using something they shouldn't.
>
> If it was named OpenGL-utils no one would mind...
>
>
> On Wednesday, 22 October 2014, Edward Kmett <ekmett at gmail.com> wrote:
>
>> We're currently actively working on writing better SDL 2 bindings in sdl2
>> .
>>
>> For various reasons, it can't depend on the OpenGL package directly, but
>> it needs a state variable construction.
>>
>> Sadly, not every platform with SDL 2 has OpenGL -- thanks Microsoft.
>>
>> We'd like to depend on the StateVar package, but then we'll get two
>> versions of the notion of a StateVar that conflict.
>>
>> By *far* the cleanest option for us moving forward would be if OpenGL switched
>> to using the externalStateVar package that you also maintain, then we
>> could incur a dependency on that.
>>
>> I realize that when this was last proposed there was some pushback from
>> the Haskell Platform, but otherwise what we're going to start seeing is a
>> profusion of almost-compatible APIs, which is the very thing that the
>> Haskell Platform is meant to prevent.
>>
>>
>> This would necessitate adding StateVar to the Haskell Platform, as OpenGL
>> is in the Haskell Platform.
>>
>>
>> The package is maintained by the same maintainer as the current OpenGL
>> package.
>>
>>
>> Discussion Period: 2 weeks
>>
>>
>> -Edward Kmett
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141022/63bcdd78/attachment.html>