I'd love to give an update on my River project for the November 4 pdxfunc meeting

[Jake Brownson]

... 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
class.

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
in it.

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.

[Jake Brownson]

Oops, sorry guys, it's November 11th

[Lyle Kopnicky]

Yeah Jake, sounds awesome! I'm looking forward to it.

[Leif]

I'd like to to see that.  We'll go ahead and add you to the schedule.

[Bart Massey]

I'm assuming we're meeting on Veteran's Day?

[Jake Brownson]

According to Calagator. I'd be fine w/ rescheduling if folks are going
to be out of town.

> --
> You received this message because you are subscribed to the Google Groups
> "pdxfunc" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pdxfunc+u...@googlegroups.com.
> To post to this group, send email to pdx...@googlegroups.com.
> Visit this group at http://groups.google.com/group/pdxfunc.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Jake Brownson
Cofounder
Brainium Studios
Skype: jake.brownson
Cell: 503.349.4841

[Lyle Kopnicky]

I'll be here on Veteran's Day. It's the following few weeks I'll be out of town. So my vote is for keeping the schedule. :)

[Leif]

I'm fine with it being on Veteran's Day; I don't have any plans otherwise.  Sure, having it then might hurt attendance, but maybe the confusion of trying to find an appropriate date to reschedule to would, as well?

-Leif