[HOpenGL] HOpenGL and the new library hierarchy

[Sven Panne]

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/enumerant/EBNF.txt

and a compiler which generates Haskell data types from them:

    http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/OpenGL/specs/enumerant/ConvertEnumSpec.hs

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.