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 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 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

I am -1 on the name foreign-state, because there's absolutely nothing even remotely foreign about anything in that package. On Wed, Oct 22, 2014 at 6:15 PM, Reid Barton 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 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 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 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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Probably not very surprising, I'm +1 on disentangling OpenGL and StateVar. :-) Regarding the actual package name and the module name: I don't feel very strongly about that, although inventing yet another package/module name (it would be the third one!) might confuse people even more. There is the StateVar package on Hackage already, and we should have a very good reason to ignore that fact. "I don't like that name" doesn't count IMHO, because this is a personal opinion and doesn't outweigh the confusion introduced by yet another naming scheme. Nevertheless, if that's the price one has to pay to get it into the Haskell Platform, I won't object. Regarding the actual content: I recently added a Functor instance for GettableStateVar (https://github.com/haskell-opengl/OpenGL/commit/3826a63d), but instances for Applicative and Monad should probably be added, too. WDYT?

On 23-10-2014 08:53, Sven Panne wrote:

Probably not very surprising, I'm +1 on disentangling OpenGL and StateVar. :-)

+1 I'm still amazed as how they got retangled in the first place. Cheers, -- Felipe.

2014-10-23 22:18 GMT+02:00 Edward Kmett :

[...] Another option on that front is to just remove the concept of a "GettableStateVar" entirely and substitute 'IO', [...]

-1, for the simple reason that there are probably tons of code out there which might break, just to save writing a few straightforward lines. Furthermore, I like the duality of gettable and settable vars, and this would break it. Let's not discuss things to death again, this is exactly what happened a few years ago. That lead to the exclusion of StateVar from the standard libraries and the subsequent assimilation into OpenGL, the exact thing we're trying to revert.

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries