Andre W B Furtado wrote:

1. Will this cause any undesired side-effects if someone intends to use GLUT but not OpenGL?

None at all (the library hierarchy is something different from e.g. GHC's package facility), and even if it did: I can't imagine why one would want to do something like that. GLUT is an extremely simple toolkit, which is really nice for simple OpenGL stuff, but nothing more.

2. Why are you using "OpenGL" rather than "HOpenGL"? Many different implementations of OpenGL use their "own names" to identify themselves, e. g., "DelphiGL".

Well, we don't call other API bindings e.g. "HPosix", etc., either :-) But if somebody else writes a different OpenGL binding, we'll have to fight for our namespace niche... >:-)

3. I also agree that "Rendering" is better than "Drawing".

Yes, but there was already some agreement on "Drawing", IIRC, so I'd propose to simply stick with that.

4. Where can I find more info about the .spec files?

There is no real documentation apart from some Perl/AWK scripts using them in SGI's OpenGL sample implementation: from http://oss.sgi.com/projects/ogl-sample/ The basic idea is as follows: There a two kinds of .spec files, one called "enumerant spec files" describing the data types and their encodings, and another one describing the functions operating on them. Small example: The following part from the GL enumerant spec file describes the possible kinds of parameters for Fogfv: FogParameter enum: FOG_INDEX = 0x0B61 FOG_DENSITY = 0x0B62 FOG_START = 0x0B63 FOG_END = 0x0B64 FOG_MODE = 0x0B65 FOG_COLOR = 0x0B66 And the following part from the GL function spec file describes the Fogfv function itself: Fogfv(pname, params) return void param pname FogParameter in value param params CheckedFloat32 in array [COMPSIZE(pname)] category drawing-control version 1.0 glxropcode 81 glsflags gl-enum glsopcode 0x0084 wglflags small-data offset 154 Note that the description is language-independent and contains *much* more information than the generated parts for the C binding: #define GL_FOG_INDEX 0x0B61 #define GL_FOG_DENSITY 0x0B62 #define GL_FOG_START 0x0B63 #define GL_FOG_END 0x0B64 #define GL_FOG_MODE 0x0B65 #define GL_FOG_COLOR 0x0B66 void glFogfv(GLenum pname, const GLfloat *params); Given such an abstract description of the OpenGL API, a lot of different things can be generated automatically: C header files, parts of the GLX protocol, lots of internal tables for an OpenGL implementation, etc. I've re-engineered the semantics of both kinds of spec files a bit, but only some parts survived the head-crash... :-( Luckily enough, some code has already been in the fptools repository, e.g. an EBNF for the enumerant spec files: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/OpenGL/specs/enu... and a compiler which generates Haskell data types from them: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/OpenGL/specs/enu... Alas, I have to write up some prose again which explains the necessary lexical preprocessing steps to get a grammar which is not line-oriented :-P, the different kinds of possible data types (enumerations, bit masks, ...), usage vs. definition, etc. Nevertheless, if you want to play around with the compiler a bit, just give "configure" the additional flag "--enable-hopengl" when you build GHC from CVS. The aforementioned directory contains enumerant spec files for GL and GLU, which can simply be piped through ConvertEnumSpec to get (almost) complete Haskell modules containing the Haskell data types and their (un)marshalers. The stuff dealing with function specs will follow "soon". Doing something a second time usually speeds things up... :-} *sigh* Cheers, S.