G'day all. On Wed, Jun 19, 2002 at 10:29:52AM +0200, Wolfgang Thaller wrote:

The problem here is with OpenGL, not with GLUT. OpenGL requires some thread-local state to be set correctly in order to operate. Surely you wouldn't suggest reimplementing OpenGL (plus all OpenGL video drivers for every platform/OS/graphics card combination out there) in Haskell?

Point taken. Actually, many high-level language GUI interface bindings spawn a dedicated thread to handle all the graphical I/O and everything else is done with inter-thread communication. It would be fiddly and unnecessarily painful, but you could probably do that with no changes to the rts so long as the dedicated thread wasn't a Haskell thread.

I agree that it is difficult, and it can cause headaches. But in order to write "real-world" applications in Haskell, there is no way around it. In order to write GUI applications, I need a binding to Win32 (a "C-specific" framework) for Windows, [...]

This may be a definitional issue, but I wouldn't call Win32 a framework. MFC is a framework. POSIX isn't. BeOS is somewhere on the boundary.

Most of those use callbacks of some sort.

Most of them don't require thread local state for correct operation.

Exceptions just require a little more marshaling, I think. As for the even hairier things, I don't think "they" are going to add many more crazy things to the C language family, so C-specific frameworks shouldn't hold too many surprises in store for us...

I'm constantly surprised by the hairiness you can find even in constructing C++ bindings for C APIs. It's not going to be long, for example, before you find an API which requires a callback to use varargs, at which point we'll be having this conversation yet again. Cheers, Andrew Bromage