Ryan Ingram wrote:
Apfelmus, I hope you don't abandon your efforts, at least for the selfish reason that I enjoy reading your blog entries about trying to implement it!
:D My reasoning was that a temporary demand-driven implementation would allow me to release the library sooner; I want people to start using the library and experiment with FRP. I can always add the push-driven implementation later. However, even in a demand-driven implementation, there is one optimization that I would like make: when there are multiple external events, say e1 and e2, the network splits into subnetworks that react only to one of the inputs. For instance, your example would split into two graphs e1 e2 | \ | \ e3 e4 and e3 e4 | | | | e5 e5 e5 e5 that are independent of each other. Unlike successful filters, these subnetworks are known *statically* and it's worth splitting them out. That said, it appears to me that this optimization is quite tricky even in a demand-driven setting! I can as well stick to the push-driven implementation I have already started.
I was looking at your last entry and trying to understand if/how you solve the order-dependency problem for events. In particular:
source events e1, e2
e3 = e1 union e2 e4 = e2 union e1
e5 = e3 union e4
The graph from your description would look something like
e1 e2 | \-A / \ A-\ e3 e3 e4 e4 | | | | e5 e5 e5 e5
When I was looking at the FRP problem before, it felt a lot like the 'adaptive' problem, so I was looking at Umut Acar's papers and trying to build something along those lines. But perhaps your API is simple enough that you don't need that degree of complexity.
Thanks, I'll have a look at his work. It's really very similar to some kind of adaptive computation. What currently irks me about my push-driven implementation is that it is ad-hoc. I would really like to start from a demand-driven implementation and systematically transform it into a push-driven one. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com