How to contact OpenGL package maintainer (where is Sven?)
dons00 at gmail.com
Sun Apr 17 21:36:33 CEST 2011
Something under Foreign, then, if it is an abstraction for pointers.
Take a proposal to the libraries@ list.
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
>> 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
> 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?
More information about the Libraries