Oct 25, 2013, 3:00:47 PM10/25/13
to pdx...@googlegroups.com, Kevin Lynagh, Paul deGrandis, Pat Hickey, Benjamin van der Veen
... if you guys are interested of course :)
I've presented it twice before to pdxfunc at major milestones, and I
used to call it "Reactive" but it's new working title is "River". I've
mostly completed its 3rd major rewrite and it gets nicer every time.
Here's a summary of River:
River is a purely functional reactive system built on top of C++11
with some Ruby metaprogramming. It's reactive in the sense that as
inputs to the program change invalidations ripple through a big graph
of functions until they hit the outputs which greedily reevaluate the
graph. One significant difference from other reactive systems is that
there is no notion of time, or sequences of values at the language
level. There is no notion of events, or continuous streams of values.
It is just a big function that gets reevaluated as the input changes.
We can talk about these things using the system, but they aren't first
One key idea is to push all of the logical state out of the program
itself and just make the outputs a big function of the inputs to the
program. One big function.
Inputs to the program can be things like the total console input as a
list of characters, a list of clicks the user has made, etc. Outputs
of the program are things like "There should be a window on screen"
"The window should be called 'Frank'", "The window should have this
button on it", etc. When the user clicks a button in the window the
inputs change and a new output is calculated. Maybe the window is now
called "Bob". Maybe the window no longer is on screen, but there's no
state in the program that isn't a function of the inputs.
Interactive Haskell programs work by ultimately evaluating some lazy
list of things that doesn't end until the program is terminated.
They're always in a state of being partially evaluated until the
program ends. In each invalidation cycle the River program is fully
evaluated, but the bits of it that are dependent on inputs that could
change stay in memory so they can respond to changing inputs. An input
list may have been empty the first go around, but now it has an item
I'm building River as the first phase of a larger project, but would
be a whole different talk that hopefully I'll be able to do some day
when I have something to demo. I'm always happy to rant about it if
you ask though :).
If the group is interested I would be showing an AppKit GUI
implementation of the logic puzzle Akari running in the system and
digging in to how things work a bit (don't worry, I won't show the
particularly crazy c++ bits). I'll also show an interactive
visualization of the in-memory graph that allows you to navigate it
hierarchically which makes a great debugging tool.