Peeking into the future with RDP

One aspect of reactive demand programming that sets it apart from other reactive programming models is its support for optimistically working with the predicted future states of signals.

Think about a signal that carries the current time in seconds, that you want to display on screen as a clock. The screen should update close to the full second.

Let's say your clock display uses complicated drawing routines that take a while to display. So if you start drawing at the full second, your drawing will always lag behind the full second.

But why should this be? The clock signal already knows that it will change to the next full second at a particular time in the future, and can communicate this to the display code.

In RDP, we can view a value not as a point, but as an arrow in time, that may point into the future. Consider a mouse: during mouse moves it is often possible to give a good prediction of where the mouse will move in the next instant. With RDP it's possible for the mouse signal to communicate this information to its clients.

Given that the clock display code can peek into the clock signal's future, it can perform intensive processing at leisure before the actual switch to the next full second (e.g. by drawing into an offscreen buffer and copying it to the screen buffer at the full second).

Predictions are often wrong, so clients always need to have a fallback (e.g. throwing away the prepared drawing in the offscreen buffer and drawing from scratch, accepting a laggy display). But the fact that RDP signals can inform clients about future states enables a wider spectrum of behaviors that were previously impossible to achieve.

The worm is the spice

Just had a nice insight regarding systems that deal with reactively updating (potentially large, structured) values such as RDP:

The dynamic output of a process is indistinguishable from a static storage resource (file).

In batch systems like Unix, this symmetry is not so deep: the output stream of a process looks somewhat like a file, but the process can't make any changes to earlier, already emitted portions of the stream. This is unlike a file, which can be edited anywhere.

In a reactive system, a process output is truly indistinguishable from a file. The process may decide to update any part of the emitted value at any time, just like a user editing a storage resource.

Apart from being a nice symmetry in itself, I think this also offers new possibilities for user experience. Processes and files can be used interchangeably in the UI. A file can be viewed as a (rather boring) process, whose output gets edited by the user (similar to data in pi calculus).