Export to
Friday, August 30, 2013 at 11:07am and last updated
Monday, November 11, 2013 at 5:03pm.
pdxfunc: Portland Functional Programming Study Group
Access Notes
Enter the Dekum building in the middle of the block on the West side of 3rd Avenue, between Washington and Alder. Meetings are in 4th floor basketball court.
In the 4th floor basketball court.
Website
Description
Jake Brownson will be presenting on his project 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.
ABOUT THE GROUP: Join programmers, researchers and enthusiasts to discuss functional programming. pdxfunc is a study/user group exploring the world of functional programming based in Portland, Oregon. The group welcomes programmers interested in all functional languages, including Haskell, OCaml, Erlang, Scala and others, as well as using functional techniques in non-functional languages. The group meets regularly and provides presentations, demos and discussions applicable to all skill levels, from newbies and experts. The meetings are usually on the second Monday of the month.