On Tue, Sep 3, 2013 at 10:47 AM, bertschi <nils.bertschin...@googlemail.com>wrote:
> As far as I know, Haskell has Chan data types in its concurrency > extensions, but I have never seen them in FRP. Maybe this means that FRP is > addressing a different problem. On the other hand, the Automaton Arrow can > be used to implement state machines that transition on receiving inputs in > a composable and referentially transparent way ... but they still have some > problems regarding efficiency and space-leaks. > referential transparency without efficiency with space leaks is not what I call a path towards correctness. I am sure pure FRP implementations will one day widely surmount these obstacles towards correctness. I'm personally not going to wait - a tunable CSP model seems better suited to the construction of correct (in the sense that it actually reliably works for the end user, not proof) interactive programs. That said core.async is not anti-FRP, most of the code that I've written using core.async leverages an FRP style quite liberally, but it's refreshing to not be ball-and-chained to that approach when writing interactive programs. David -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
