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 ()