Proposal: Let OpenGL depend on the StateVar package

[Edward Kmett]

imperative-state then?

On Wed, Oct 22, 2014 at 6:15 PM, Reid Barton <rwbarton at gmail.com> wrote:

> 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/4ccc81fe/attachment.html>