There are many ways to manage concurrency concepts: with threads, coroutines, continuations, generators, ... and events. A page on Event programming and why it is relevant to Tcl/Tk programming explains some of the background behind Tcl's emphasis of the latter.

Events are a relatively "safe" programming model, particularly when compared to threading. John Ousterhout's influential "Why Threads Are A Bad Idea" is available as PowerPoint slides [1] or in a PDF [2].

Notice that C# makes events first-class objects. This is consistent with Anders Hejlsberg's earlier work with Delphi ...

Steve Ferg created a SourceForge placeholder [3] for event-driven material, including his "Event-Driven Programming: Introduction, Tutorial, History".

---

This Wiki has several other pages [4] on event-oriented programming techniques.

---

Martin Lemburg July 11nd, 2002: I have a question:

Why isn't there an event Invoke for invokeable widgets, like buttons? Wouldn't make it sense to have such an event? To bind widgets using the Invoke event, like to connect a widget with the -command option to an event handler?

Then ...

 button .b -text exit -command {cmdProc .b [clock seconds]};

... would be equal to ...

 bind .b <Invoke> {cmdProc %W %t};

It shouldn't be a problem to use the substitution capabilities during the usage of a binding, like:

 button .b -text exit -command {cmdProc %W %t};

Wouldn't that be nice and consequent? Wouldn't it be consequent (for example) to use bindings to scrollbars or entries too? ...

 entry     .e   -textvariable filter;
 button    .b   -text "filter";
 listbox   .lb  -listvar data -selectmode extended;
 scrollbar .sbx -orient horizontal;
 scrollbar .sby -orient vertical;

 bind .e   <Validate> {validateFilter %V %s};
 bind .b   <Invoke>   {filter .e .lb};
 bind .lb  <XScroll>  {.sbx set};
 bind .lb  <YScroll>  {.sby set};
 bind .sbx <Invoke>   {.lb xview};
 bind .sby <Invoke>   {.lb yview};

There would be the chance to elimate all (event)handlers from that code, that only builds up the GUI. The code to handle events could use now use bindings.

---

While Tcl-ers are generally trained to believe, "event orientation: good; threads: bad", that is, of course, an exceptionally truncated version of reality. Threading's programmability problems begin with the necessity to mess with data consistency. Event-based programming, on the other hand, needs continuations or closures or comparable expressive power to manage the program-control stack. With none of these, developers must mess with stack contents on their own, and, of course, that's a horror.

WK Threads used for everything are a bad thing. I think that Tcl community is getting to like threads, but I like the idea that I can have every single interaction (GUI and network) in one thread and if I need some long lasting calculations, I can just add a thread and communicate with it using thread::send -async, and then (well a small nice wrapper is a must here :-) I can talk to a thread similar to a networked application. And it takes 30 lines to wrap this:

  set code [catch $someCommandList result]
  myCallback $code $result

into

  asyncEval $someCommandList myCallback

And this is how larger calculations could be done easily.

Tcl performs its usual compromise and provides everything as a string. More precisely, Tcl gives enough introspection to pack and unpack events and their "formal arguments". That's enough.

---