There are many ways to manage concurrency concepts: with threads, co-routines, 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 only as PowerPoint slides [L1 ].
Notice that C# makes events first-class objects. This is consistent with Anders Hejlsberg's earlier work with Delphi ...
This Wiki has several other pages [L2 ] 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?
Than ...
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.
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.