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@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@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@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries