[<<][compsci][>>][..]
Sat Apr 17 10:25:04 EDT 2010

Functional Reactive Programming

I'm building a (naive implementation of) an FRP evaluator to implement
the incremental update logic (compiler cache) of the ramblings
formatter for the http://zwizwa.be website.  Output events are server
http requests, while input events are database (file) changes.
Because file changes are infrequent compared to http requests, a
"compiled" representation where intermediate data are retained in a
cache works best.

The amazing part is that, yes, it is really all about composition.
And for composition, functions are king.

Once you have all logic abstracted as a collection of functions,
everything becomes a lot simpler to test individually and to string
together.

The reactive part then becomes a "toplevel" wrapped around a large
collection of pure functions that does the real work.  I.e. FP allows
complete separation of the functional and the reactive part.  This is
great.

The implementation uses lazy evaluation in the direction of functional
dependencies (data pull) combined with event-driven invalidation in
the reverse direction (data push).

In Scheme this can be implemented using weak hash tables; whenever you
apply a function to reactive values, notify each of the values that a
computation depends on it.  This can be done by associating each
reactive value with a weak hash table of values that depend on them.
Whenever a value gets invalidated, it can propagate invalidation to
all nodes that depend on it.  The weak table ensures that the GC still
works for reactive values.

The main abstraction then becomes function application, or more
specifically: application of pure functions to reactive values, in
zwizwa/plt/rv implemented as `rv-app'.



[Reply][About]
[<<][compsci][>>][..]