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.
What can we do to increase your confidence? Do we need some form of continuous integration testing (eg., a build farm) and some test cases? Do you want me to look at what you have?
The first problem is whether or not everything of the GL3.0 spec is in there, and exposed in the right way. Especially for the 3.0 version this is quite a difficult one, as the spec is about 500 pages long (and quite dull). While it's not a big issue to add a missing function/enum/feature, but this addition might also lead to points where the future proof and usable implementation would lead to breaking changes (e.g. the current Texture part and rectangular textures). The second type of problem is of the sort "Is this the best way to do it?". While most of the work is reading the spec and copying the work already done there are some points where there are some more difficult problems. It should be noted that my history with Haskell/FP is quite short, and that on average more complex things tend to be rewritten at least once before I'm happy with the result. So in short my knowledge/experience is sometimes lacking for some problems (though it's getting better :D). About testing, I'm confident that OpenGL builds as it doesn't require anything special, OpenGLRaw isn't much of a problem either as it's straight forward for the things I could add. The problem with test cases is that they costs are relatively high to the cost of writing the functions, and most of the time you have to check by eye. A look at the code would of course be nice, though most of the stuff is (as said) straight forward. The more difficult problems are with the FramebufferObjects, Textures and maybe more, but I would happily generate a list of points where things are likely missing or wrongly implemented.
... (part about the inconsistencies in the .spec files)
Ah, interesting. So we would probably want to massage the files from Khronos before processing them. Thanks for pointing that out. It's details like that that can really come back to bite you.
For generating Raw, the massaging I had to do to compile it was almost trivial (e.g. fixing a few exports/imports). Though the format has some nasty indirections that I haven't resolved yet.
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.
Is that code in a state where you'd want to share it?
I'm not really started with the code generator. The problem with code generation from my point of view is that while there is a good representation of haskell source in haskell (see the haskell-src-exts package), there seems to be missing higher representation of functions, datatypes, etc. . So I'm trying to come up with something that would represent those things to my wish. Only problem is that there are so much directions, interesting ideas, etc. that I don't know which idea I should chose (due to some inexperience, and coming up with new ideas regularly). So maybe I should implement some ideas and ask, as I cannot decide (yet). On the format, if people would like I could upload or in some other way share the current xml file, which currently describes a part of the Bufferobjects syntax.
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).
I wouldn't want to edit the generated code (I'd rather fix the generator), but I would like to commit the generated code periodically, say at release time, so that there is 1 canonical generated version per release. Also, that way people using the opengl binding wouldn't need to build/run the generator.
Certainly, but I was also wondering what we should do with the current code. Some parts I wouldn't want to recreate/generate others could be easily. And if we would switch to a generator, that probably would mean some API changes in subtle ways. So how would such generator interact with the current code base.It could for example end up between the extra helper functions that are mostly handwritten, and OpenGLRaw replacing part/most of the marshalling. Lars