On Sun, Apr 17, 2011 at 10:43 AM, Don Stewart
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/StateVa... 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