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

[Jason Dagit]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110417/3b9e5cae/attachment.htm>