Re: events & callbacks

Daan wrote (about whether callbacks are concurrent)
> Just for the record: this is *not* true for most (all?) event
> based implementations as they are *not* concurrent (at least not
> pre-emptively concurrent). Somewhere down, there is an event loop --
> a loop that waits for an event, executes a callback, and loops again.
> Even though more events can happen while executing the callback, it
> will only propegate into Haskell once the callback returns and the
> event loop pops it off the OS event queue. [note: You can achieve more
> concurrency in Haskell by using Haskell threads but even than one
> has to wait till the callbacks are done or otherwise the runtime system
> sits idle while waiting for the next event (as this is a C call).]
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.

But really, are you serious?  Imagine I click button A, which is supposed
to start another dialog in which I click button B, and so on.  Since it
is apparently illegal in GIOs world for button A's callback to include a
wait on button B's callback, the only way to do this kind of thing is
turn my whole program inside out, rewrite it in continuation-passing-style,
and then make button A put the whole continuation on button B's callback.
I remember having to do this kind of thing once, back in the days when
GHC only allowed continuations to be given to interrupt handlers, and
believe me I don't want to do it again.

As far as I'm concerned you can forget about any GUI which doesn't allow
you to write a function
     confirm :: String -> IO Bool
which puts up a window containing the String and "OK" and "Cancel" buttons,
instead making the user put up with the CPS style.
     confirm :: String -> (Bool -> IO ()) -> IO ()