Proposal: Let OpenGL depend on the StateVar package

[Ganesh Sittampalam]

How about io-state?

It seems that adopting this package under any name is better than the
status quo, so I'm +0.1 on that, but I'd much prefer a less generic name
than StateVar.

On 23/10/2014 01:00, Edward Kmett wrote:
> imperative-state then?
> 
> On Wed, Oct 22, 2014 at 6:15 PM, Reid Barton <rwbarton at gmail.com
> <mailto: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
>     <mailto: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
>         <mailto: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 <mailto: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
>                 external|StateVar| 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 <mailto:Libraries at haskell.org>
>         http://www.haskell.org/mailman/listinfo/libraries
> 
> 
> 
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>