[GUI] Re: events & callbacks

George Russell ger@tzi.de
Tue, 11 Mar 2003 16:07:59 +0100

Daan Leijen wrote:
>> Well, if the callback model requires you to work in a gaol in which
>> concurrency is banned, it is useless.  I rest my case, m'lud.
> It has nothing to do with the Haskell "callback" model. It is how most 
> GUI libraries just work on the OS level: win32, X, GTK, etc.
> This doesn't mean you can't do all kinds of tricks to implement a more 
> appropiate model in Haskell -- I just wanted to make clear that
> the argument/example/supposed bug was false.

I just don't understand this at all.  Either IO actions provoked by
callbacks run concurrently with other Haskell actions or they do not.  If
they run concurrently, the "argument/example/supposed bug" is going to

Furthermore, I think there is actually very little alternative to allowing
other Haskell actions to run concurrently, if only because of the infamous
blackholing problem (see FFI archives, passim; the basic problem is what
you do when the callback needs some value which some other bit of Haskell
is half-way through evaluating).  You can't bring the whole of the
rest of the Haskell world to a stop and run just the callback thread.

> Again, it has nothing to do with Haskell but depends on the OS. Fortunately
> all platforms indeed allow you to run a window "modally". (In this case,
> you call C world again from a callback, but that C call will go into its
> own event loop and call Haskell callbacks from there again.).
> In short, the eventloop model is what each platform provides and it is
> up to us to implement something nice in Haskell. Since each platform has
> "modal" windows, there is no need for CPS style programming. Even better,
> using concurrency, I have even found an implementation of "sync" on top
> of the eventloop model.

If the GUI is to be built in terms of modal event loops, then we should at
least know how these work, so we can see how they will fit in with
concurrency, laziness and so on.

It does seem to me that my plain old events are likely to be a lot
simpler ...

A simple question: what happens when two separate Haskell threads both
try and open dialogues?