Proposal: Let OpenGL depend on the StateVar package

[Reid Barton]

As a point in the package name bike-shedding space, how about
"foreign-state"? Seems suitably descriptive yet general, while also
dissuading casual use with the scary word "foreign".

Regards,
Reid Barton


On Wed, Oct 22, 2014 at 2:23 PM, Edward Kmett <ekmett at gmail.com> wrote:

> 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
>>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141022/04c2e3d2/attachment.html>