Switch to push based implementation

[seadowg]

Howdy,

This switches the MVP code to use a very basic push based implementation rather than an array one. Array implementations of FRP events allow for arbitrary access to the past but require large quantities of memory and generally don't match up to the requirements of an infinite stream. The push based approach however gives you a pretty nice way of sticking to the semantics (as long as people follow the rules) without storing the whole past.

One caveat of using a push based implementation is that the following would happen:

stream = Frappuccino::Stream.new(button)
button.push
counter = stream.map {|event| event == :pushed ? 1 : 0 }.inject(0) {|sum, n| sum + n }
counter.to_i # => 0

This means that you have to declare the event processing you want upfront if you care about the whole stream.

I've also switched the Map class to extend Stream (which I'm guessing would have been the idea eventually anyway).

</>

[seadowg]

Use Streams to dispatch values as well as Source

[steveklabnik]

This is super awesome, thank you so much! The arrays were very MVP, you're totally right about memory etc.

This means that you have to declare the event processing you want upfront if you care about the whole stream.

I'm slightly confused, it seems your example moves the source event before the processing, not after.

[seadowg]

Sorry that's badly worded. I mean you need to declare all the relationships before the events actually 'occur'. Ie in my example we create a new stream after the button is pressed so we are out of date: Conceptually the value of the inject should be 1.

[steveklabnik]

Oh, oh oh. Yes, it's zero, that's the part that I'm missing.

I'm okay with this.

[steveklabnik]

Thanks so much again for this! :)

[seadowg]

No problem 😄. I loves me some FRP.

[steveklabnik]

Awesome 🤘

I haven't built anything with it yet, just read things for a long time, so this project is my way of tackling it. Any good literature I should be reading?

[seadowg]

The original '97 paper (http://conal.net/papers/icfp97/) and the later revisit by Conal Elliott are pretty awesome (http://conal.net/papers/push-pull-frp/) but also take a bit of work to understand (something I still don't think I've fully achieved). If you haven't read them though they provide a proper overview of the semantics which a lot of implementations cherry pick from.

This Stack Overflow question is also provides some insights:
http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming.

I've implemented a couple of FRP projects also, only one of them really being 'pure', which might be interesting (on top of others like bacon.js which I'm guessing you've seen):

• echo
• milo
• frappuccino 😉

[steveklabnik]

Yeah, I wrote this gem because I'm at RealtimeConf EU and we were discussing FRP and bacon.js. Thanks for the links, I'll check all those out. I have enough functional background that I should be able to make my way through the literature...

[seadowg]

Ah awesome. Enjoy!

On Tue, Apr 23, 2013 at 12:35 AM, Steve Klabnik notifications@github.com
wrote:

Yeah, I wrote this gem because I'm at RealtimeConf EU and we were discussing FRP and bacon.js. Thanks for the links, I'll check all those out. I have enough functional background that I should be able to make my way through the literature...

Reply to this email directly or view it on GitHub:
#5 (comment)