How to contact OpenGL package maintainer (where is Sven?)

[Don Stewart]

Something under Foreign, then, if it is an abstraction for pointers.
Take a proposal to the libraries@ list.

-- Don

On Sun, Apr 17, 2011 at 12:32 PM, Jason Dagit <dagitj at gmail.com> wrote:
>
>
> On Sun, Apr 17, 2011 at 10:43 AM, Don Stewart <dons00 at gmail.com> wrote:
>>
>> It would need to be proposed to join the HP standard library set -- at
>> the moment, it has no other users, and a surprising top level name.
>
> The top level name for StateVar is Data.StateVar.  It is a pretty general
> api that has some handy uses.  The best parts being, turning Ptrs into
> something that behaves like an IORef and splitting read and write
> capabilities.
>
>>
>> My proposal would be to move those packages under the Graphics.*
>> namespace, and, optionally, merge (some) of them back into OpenGL, to
>> reduce maintainance burden. I don't buy the argument that the StateVar
>> interface should be widely exposed and encouraged.
>
> Where it's useful is that it provides an api that unifies access to IORefs
> and Ptrs and it separates read/write capabilities.  For something like the
> opengl package that exposes the OpenGL state machine via Ptrs and higher
> level state via IORefs this makes some sense as a way to hide implementation
> details and provide a more haskell-friendly api.  Outside of Haskell
> bindings for stateful C apis, it's probably not that useful.
> Due to how it's implemented (IORefs, Ptr and Storable), I think this is
> something that should possibly be in an FFI related module, if it were to
> live separate from the opengl package.  It does get used for opengl, openal,
> himpunk and a few other things so I can see why Sven separated it from
> OpenGL:
> http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/StateVar-1.0.0.0#direct
> My main goal though is to balance the concerns people have so that we can
> move forward using it and bundling it with the HP.  If being a top level
> name (Data.StateVar) means people don't want it in the platform then I'm
> happy to compromise on that.
> Graphics.StateVar is fine with me in that sense of compromise for opengl,
> but then it will look kind of funny when OpenAL imports something from the
> graphics hierarchy just to get access to its state variables.  So for that
> reason, I would prefer a name like, Foreign.State or Foreign.StateVar.
>  Would that be acceptable?  Which parts of the module name space can I use
> for something like this?  Suggestions?
> Jason