Oops forgot to send it also to the list. Lars ....
OpenGL has these issues: https://github.com/haskell-opengl/OpenGL/issues
Most of the issues regarding regarding GL3.0 have been implemented though not yet merged, partially because I'm not yet confident that everything is there and for some parts I'm not yet happy about what I've written. ...
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 believe that something has been done by Sven in the past (see the files in the OpenGL repo under specs). I've been working on some things (from scratch) for about a month (though not very active, due to lack of time). There are some difficult points about generating the binding from the spec files. Their are some inconsistencies in the enum spec file (which Khronos hasn't fixed, and probably isn't gone fix soon), but they can be fixed by hand. A different problem is that information needed for creating a type safe haskell binding is missing. For example enumerations aren't grouped and 'ObjectName'-s aren't identified. As OpenGLRaw doesn't need that information it can be created from the files. I've created code that does that, though it's missing some essential things. For generating OpenGL marshalling there is some need for extra information before it can be generated. I'm currently experimenting with an xml format I've made. Though the code generator is still absent, I'm trying to make one that is sturdy enough to be able to handle the things OpenGL throws at it. One major question about any code generation is how it should affect the current implementation, should it replace, augment the current library or should it be only a tool for the developers speeding up the code process. My personal preference goes to augment and replace (in the future). A generator that can fully replace/rewrite the code could have some extra (partial) back-ends that could for example generate memory managed code or code that reduces needles GLfunction calls.
...
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?
... Sounds good.