[GUI] GUIs and events

[George Russell]

Oh gosh I'm glad we've got a decent debate going on this ...

Wolfgang Thaller wrote (snipped)
> 1) Callbacks will be executed synchronously. No other events will be 
> handled until a callback returns.
> Rationale:
> 	*) This maps directly to the execution model of all backend toolkits 
> that I know
> 	*) You can easily get concurrency by calling forkIO, but going the 
> other way is difficult.

I am strongly opposed to this proposal.  As a matter of fact this does
*not* map directly to the execution model of HTk, in the sense that if I
wanted to add such callbacks to HTk I would have to add an extra lock to
prevent callbacks running synchronously.  However there is a more
fundamental objection.

I think in general this does not scale.  For example initialisation code
(1) might occasionally need to put up a window (eg one that says
     "Can't find configuration file, please enter new path")
(2) might, thanks to the common paradigm of doing initialisation using
     unsafePerformIO, need to be run almost anywhere in the program, including
     during a callback.   The only way of avoiding that is to force the user
     to adopt a paradigm where no callback may make use of a service which
     might require an initialisation (or anything else) which itself requires
     a GUI event.  This is highly unpleasant.

Also this way of programming is highly unpleasant.  For example, if I have
a button "Send an insult to Simon.Peyton-Jones@microsoft.com" and it wants to
put up a window saying "Do you really want to insult Simon Peyton-Jones?" then
you need a chain of callbacks.  The callback attached to the first button
is not allowed to insult Simon PJ itself, instead it has to attach a
continuation (containing the insult) to the confirmation button.  In general
this means continuation-passing-style is going to infect this part of the
program.  For programs where almost everything is initiated by user action,
an awful lot of them is going to have to be written in CPS.