Monday, June 15, 2015

A trivial implementation of Reactive Demand Programming

I wrote a trivial implementation of RDP in JavaScript to help me understand how it works.

It's called bucky-rdp (about 200 lines of heavily commented code).

It currently supports Sirea's bconst, bpipe, and bfmap.

Here's an example:

// Create some behaviors for transforming numbers.
var bDouble = rdp.bFMap(function(val) { return val * 2; });
var bMinusOne = rdp.bFMap(function(val) { return val - 1; });

// Create a pipeline behavior of the two behaviors
var myBehavior = rdp.bPipe(bDouble, bMinusOne);

// Apply an inactive input signal to the pipeline behavior
var sigIn = rdp.makeSignal();
var sigOut = rdp.apply(myBehavior, sigIn);

// Change the input signal value and watch the output signal change
sigIn.setValue(2);
console.log(sigOut.getValue()); // Prints 3
sigIn.setValue(4);
console.log(sigOut.getValue()); // Prints 7
sigIn.deactivate();


(This post refers to v1.0.1)

6 comments:

Lars Brinkhoff said...

Reminds me of Forth.

Dobes said...

This is great I am also trying to decode RDP. I thought in RDP the downstream behaviors or signals were supposed to push a parameter upstream as well. Otherwise we are missing the "demand" part. Am I right here? Have you thought about how that would work in "bucky"?

Manuel Simoni said...

Dobes, in the above example, sigIn is the demand that causes myBehavior to compute an output on sigOut.

patrickdlogan said...

One thing I am not clear about is how dynamic the signals system can be. For example, can I define a "current menu selection" signal and as I move the pointer over a menu (list of items), the item under the point at any given time is the value of a "current menu selection" signal? (if that the proper terminology?)

Manuel Simoni said...

Patrick, yes that absolutely sounds like something RDP can model this way.

Usually, signals are actually accessed by means of behaviors, analogously to how a filesystem is accessed by means of a file server in Plan 9.

So there could be a bCurrentMenuSelection behavior that, when there is a demand (input signal) on it, responds with a dynamically updating output signal containing the currently selected item. The input signal on bCurrentMenuSelection could simply be an empty/null/unit signal, indicating the time and duration of your (or another component's) interest in the current selection.

The main behavior of an RDP app is activated by supplying it with an empty demand, and usually its output signal is ignored (if the app is just run for effect, such as displaying a GUI). This initial empty main demand is then passed around inside the application (duplicated with bdup into a product signal, see Sirea README) to activate its sub-behaviors.

It's also possible to dynamically reconfigure the behavior network at runtime. Here's an example of how that could work from David: https://groups.google.com/forum/#!msg/reactive-demand/C_0TJjTQkzo/z5VEoSJZePkJ

Anonymous said...

Reading a blurb on Alan Kay's idea to create whole computer system, including windowing system, menus, gui with layout, publishing etc in 20,000 lines of code mentioned that it uses reactive programming (and constraint based layout). But it was mentioned that a tick based model for updates was chosen because that apparently simplifies some problems. That is to say, it's organized like a video game where time is measured in discrete animation steps.

I'd like to see how that solves problems and how one rolls that in.