That is Section 2, which describes how to make observers more composable and thus simpler to use. The problem solved in Section 3 is to use some cleverness in

That is Section 2, which describes how to make observers more composable and thus simpler to use. The problem solved in Section 3 is to use some cleverness in your compiler/runtime to make it so you can write a state machine as straight line code but have it wait for signals to arrive and run in parallel with other code without having to think about it. The Reactor described on the second column of page 4 enables this. Notice the difference with the previous column, and even more so with the first example. You are no longer tracking any state (starting/disposing moveObserver or adding/removing moveObservers) but just writing the code as if you can wait forever for the signals and then respond to them. This looks really nice, but depends on some compiler features that most languages do not have (continuations and/or tail call optimisation) so it is unlikely to make it into other languages soon. Section 4 describes time-varying instead of discrete signals, so that Section 5 can then describe how to unify time-varying and event-based signals into a framework, which is (the already invented but not widely used) functional reactive programming. The types make it much more exciting than the Scheme implementation though. Section 6 shows how this is/could be actually implemented.