Alastair Reid wrote:

[...] To me, the word 'Rendering' suggests that it can (only) do output (drawing graphics) but HGL also does input (reading keyboard and mouse events). So I think Graphics.HGL is more accurate.

But the same argument surely applies to OpenGL too (???) so maybe I'm reading too much into 'Rendering'?

No, OpenGL is solely concerned about producing pixels, and GLUT only handles the non-rendering stuff, so the distinction makes perfect sense here. X11 is a different beast, so your hierarchy looks fine to me. Something completely different, but still X11-related: With the current state of the FFI, I can't see an advantage in using GreenCard for the X11 binding. All X11 constants are hardwired through the protocol, and the FFI + its related libraries handle newtypes, (un-)marshaling, error handling, etc. at least as nicely as GreenCard. But on the other hand we already have the GC stuff for X11, but this looks like the only advantage... Cheers, S.

heck, lets dispense with the FFI altogether and just write some Haskell code to speak the X11 protocol :). I am only semi-serious (although such a project is entirely feasible). In any case there are some alternate client X11 libraries besides XLib which have some very nice features which are worth looking at if you are at all interested in the design of a modern interface to X. http://xcb.wiki.cs.pdx.edu/ John On Mon, Apr 14, 2003 at 08:40:48AM +0100, Alastair Reid wrote:

Sven Panne writes:

...

Something completely different, but still X11-related: With the current state of the FFI, I can't see an advantage in using GreenCard for the X11 binding. All X11 constants are hardwired through the protocol, and the FFI + its related libraries handle newtypes, (un-)marshaling, error handling, etc. at least as nicely as GreenCard. But on the other hand we already have the GC stuff for X11, but this looks like the only advantage...

The fact that no-one has done the conversion is certainly the most obvious advantage.

I also think that GreenCard offers some things that the ffi + libraries does not or does not do as nicely. Describing constants is more verbose (and there's a lot of constants in X) and you usually have to write a separate wrapper function to marshall arguments and results, to catch error conditions and to return multiple values. hsc2hs and c2hs go some way to alleviating these problems and I'd look seriously at them if starting over again.

The same applies to Win32 as well except that many functions return error codes so you need wrapper functions in virtually every case. (X11 functions rarely return error codes because it is has an asynchronous connection with the server.)

All that said, if anyone wants to have a shot at translating the lot into readable, maintainable pure ffi then please go ahead. (The 'readable, maintainable' part is intended to exclude committing the code generated by greencard :-)

-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------