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! 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. -- ryan On Tue, Apr 26, 2011 at 12:29 AM, Heinrich Apfelmus < apfelmus@quantentunnel.de> wrote:
Edward Amsden wrote:
As far as I can tell, with classic FRP implementations (those which use behaviors as a first-class abstraction), the only way to create a behavior or event based on some external input (for instance keypresses or microphone input) is to do something with unsafePerformIO or unsafeInterleaveIO. A behavior is a value, which when evaluated at a specific time would have to either block its evaluation until input could be read, or check the input at that particular time.
Is there any other way of implementing external behaviors besides that?
Yes, there are other ways, see for example the implementation here: http://tinyurl.com/frp-automaton . This is essentially a pure variant of Ryan's implementation.
My implementation has a serious problem, namely that sharing is lost. I think this is the case for Ryan's implementation as well. The state of a behavior will be duplicated and updates multiple times. This can be fixed by observing sharing, of course.
I'm currently working on a push-driven FRP implementation. (Though I'm getting second thoughts as to whether the small increase in efficiency is worth the implementation cost.) See also
http://apfelmus.nfshost.com/blog/2011/04/24-frp-push-driven-sharing.html
Best regards, Heinrich Apfelmus
-- http://apfelmus.nfshost.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe