Hi everyone, HOpenGL hasn't really had any major update lately. Though I think there are quite some things that can/should be done on the package. Therefore I've made a list of task/ideas so people can decide what should(n't) be done. Comments, ideas and remarks are welcome as I would like to know which of these things you value and which are worthless so I (and others) can take it into account when programming on the package. I've added a list of them grouped in three categories, and after that there is a little more detail about them. General work (external API visible) - Make the package OpenGL 4.2 compliant. - Do something useful with the deprecation model - Rework/implement support for matrices - Add per OpenGL version export Restructure the internals - Rework marshalling - Restructuring to get it more type-safe - Restructure the module hierarchy Policies - Policy on extensions - Policy on testing - Policy on documentation *General work* * Make the package OpenGL 4.2 compliant.* The current package supports OpenGL 2.x as maximum. I've been doing some work on 3.0 (which has the worst spec of all) and I think to be over 75%, maybe even over 90% ready. But the package should, of course, be supporting all versions of OpenGL. This is probably the most work to be done. *Do something useful with the deprecation model* With 3.0 and higher versions part of the OpenGL API has been deprecated. Though it's a bad to drop all support for the deprecated stuff, it's also not a signal to ignore. We should probably be using this information in some way to improve the package. I think it's probably a good idea to make an export with and one without deprecated functionality. Maybe even make a compilation possibility for compiling without deprecated stuff. *Rework/implement support for matrices* Some basic support for the use of matrices is missing from the package and it's needed for some new functions. Some discussion is needed on how we should add them (only a typeclass vs. datatype). *Add per OpenGL version export* It would be nice to have an export/import module for each version so that you could do "import .....OpenGL.Core31" to import only the functions of OpenGL 3.1 (and of course similar for the other versions). *Restructure the internals ** Rework marshalling* As stated in a previous mail to this list (see [1]), I want to improve some of the marshalling, that would in quite a lot of places improve the readability of the code and the efficiency of coding (at least that is my theory). *Restructuring to get it more type-safe* There are some places where the code could be improved to make it safer (in the sense that more wrong code it ill typed). For example, GetPName could be broken up into several separate datatypes for different result datatypes and sizes. *Restructure the module hierarchy* The current structure is that almost all modules(about 55 for me) are in Graphics.Rendering.GL. Furthermore some of the most important modules are 1000+ lines, this makes it sometimes quite hard to have overview over the code. This coud probably be fixed quite a bit by moving all deprecated functionality to it's own modules (I estimate it's about 50% of the code). A side from that, some modules could be split up in directory form (as with Texturing and PixelRectangles) to make the code more readable. A further change could be to export some extra functionality from 'Internal' modules for people how find that they need that in order to make a function that isn't in the package. *Policies* *Policy on extensions* Extensions are a major part of OpenGL usability and there for we should think about what to do with them in the package. *Policy on testing* Testing all the workings of the package would be nice, but building a test suite is quite a lot of work. And thus we should decide how much we should test or otherwise make sure that the written code is compatible with the OpenGL specification before including it in an release. *Policy on documentation* The current package is mostly undocumented. Most of the functions are the same in name and working as those described in the OpenGL specification, but the specification is not something most people want to read. On the other hand, in my opinion writing documentation is one of the least favourite tasks of programming. So how much and what should be documented. Greetings, Lars Corbijn [1] http://www.haskell.org/pipermail/hopengl/2011-June/001038.html