Hello, The last time I brought this discussion up with the list, I made some mistakes. Let's see if I can do things better this time :) The GSoC student who was scheduled to work on improvements to the bindings disappeared before writing any code. I took a long holiday for relaxation and also some time due to illness, but I'm back now. So, I think now is a time when we can safely get a fresh start on improving Haskell OpenGL/graphics support. Also, one of the major points of feedback was that the improved bindings need to have a nice upgrade path, and for example not a jolting version bump. I have not forgotten that and I do want to incorporate it in the plans for updates. I'll try to be timely with my email responses going forward. I'd like some feedback on the directions I outline below. What follows is my impression of the state of things. I would like to see the most recent versions of the opengl bindings make it into the Haskell platform. Currently, the HP ships a version of HOpenGL that is NOT the most recent. Even if the bindings are not included in the HP, I think the feedback they gave us is good and should be implemented. OpenGLRaw has the following open issues: https://github.com/haskell-opengl/OpenGLRaw/issues OpenGL has these issues: https://github.com/haskell-opengl/OpenGL/issues GLUT and GLUTRaw have no open issues, but there is one bug fix on github that needs to be pushed to hackage. The issues fit into a few categories: a) Support for specific versions of the OpenGL spec b) Refinement of the types (better modeling of C while easy to use in Haskell) c) Performance (MArray instances, if possible and fast floating point conversions) d) OpenGL doesn't expose everything that OpenGLRaw already supports/exposes Before Alexander disappeared he showed me that someone has started a tool (available on github) for parsing the Khronos xml spec for OpenGL. We could use that code to auto generate much of the code in OpenGLRaw. I think that could be a fun and reasonable project for someone. How do others feel about using that to address (a) and (b)? Of course, some work would need to be done first to prototype how it should look/work and then the automated conversion could be developed. I'm not personally all that worried about (d) because I like the *Raw bindings better, but I think that the user base is split on that issue with people holding both preferences. I'd like to focus my attention on (a) and (b) first. I also want to make a bug fix release of all four packages that update the cabal files and just do a minor version number bump. Any objects to that? Suggestions? Thanks, Jason