Hi falcon,

Unless you're going to plug into new OS functionality then in some sense you're ultimately going to be mapping existing events, callbacks or code execution points to higher-level events. The ConcurrentLife and DirectX InteractiveVisualization samples have examples of creating and mapping events in this way, e.g. using IEvent.create.

In a reactive GUI application many events will be "piped down the event queue of the GUI thread" and then result in a the event callbacks being invoked. For example, the System.Windows.Forms.Timer control provides an event of this kind. If you wanted to create this event from hand you would effectively have to call into the Win32 API to send messages through the GUI application's queue at appropriate intervals.

1
2
3
4
5
6
7
8
9
10
11
12

 

let timer = new Timer()
timer.Interval <- 1500
timer.Tick.Add(fun _ -> printf "hello world\n")
timer.Start()

// Enough!

timer.Stop()

Event values are everwhere in the .NET APIs, including in the networking libraries, and I'm certain that most socket programming would benefit from using them heavily.

Although I haven't seen it written up in this way, I think of IEvent values as an imperative counterpart to continuations (not callcc continuations, but rather the more general sense of "how does the program continue after some particular thing happens"). I am certain you will find counterparts to the construct in the Scheme and Smalltalk literature, though I'm not certain of the terminology used.

One of the main challenges with using events is to know which thread the callbacks are invoked on. This applies to all the asynchronous constructs of .NET - e.g. finalizers will be run on the finalization thread, a huge source of potential race conditions, and callbacks from non-blocking I/O get run ni the thread pool, though it's not easy to see that form the code. Tracking thread IDs through a static or dynamic analysis (or a mixture) and feeding the information back to the programmer is a very interesting area for those who really want to improve the life of working programmers. One day soon we'll probably have to read main memory asynchronously (there being such a stteply increasing cost to a chache miss), so this problem isn't going to go away soon.

I think it's very interesting to explore the design space between the style of "event wiring" that .NET supports and the declarative reactive programming of Fran and later developments. The challenge would be to bring the goodness of the DRP work into an imperative programming setting, without requiring a complete rewrite of the entire GUI framework. F# is the obvious language in which to perform this investigation, and in conjunction with WPF you'd be able to give some very groovy demos!

Don