On Thu, 2005-09-01 at 23:15 +1000, skaller wrote:

> I am. My idea is this: GET RID OF CALLBACKS.
> The idea is to use (user space) threads instead.
> 
> The big problem with GUI's is that they're passive.
> You write 'event handlers' and have to store the current
> state manually. By control inverting the code, you can
> just use a thread for each widget.

Have you actually done this in a GUI context, or do you just find it
conceptually attractive?

I've experimented with GUI concepts and event mechanisms in OCaml, and
created an event mechanism that could relatively easily be used in a
sort-of control inverted form by manually wrapping things into
continuations.  I never ended up making use of that form of events for
the actual low-level GUI functionality, because it always seemed easier
to just use methods or attach callbacks to events and use explicit
state.  Now that could simply be because I was sort-of porting a GUI
library that I had written earlier (in C++ and Scheme) and I'm rather
used to GUI mechanisms layered around inheritance (one of the few places
where it actually seems natural to me).

> For example for a button something like:
> 
> 	let rec wait_down () =
  ...

> 	and wait_up () =
  ...

> is purely functional: it uses the program counter
> to maintain state, instead of a mutable state variable.

But consider that the state of a button isn't quite that simple.
Tracking the state explicitly isn't difficult - attached is an actual
push button class implementation in a traditional imperative/OO style.

There's 3 boolean variables (8 states, although half of them are
impossible) tracked locally by the simplest stateful widget.  It also
has keyboard focus state, tracked by a superclass.