Just an aside, Nils, have you take a look at Elm? It's a Haskell-like language, designed for FRP, compiles to JS, and deliberately avoids monads and arrows (at least in terminology) by having Signal and Automaton abstractions... http://elm-lang.org
On Tue, Sep 3, 2013 at 9:12 AM, bertschi <[email protected]> wrote: > Hi David, > > On Tuesday, September 3, 2013 5:28:13 PM UTC+2, David Nolen wrote: >> >> On Tue, Sep 3, 2013 at 10:47 AM, bertschi <[email protected]> >> 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. > > > thanks for your insightful comments. I perfectly agree that FRP is not yet > there (and maybe never will given its ambitious goals) and core.async > provides a nice and WORKING solution. I certainly do not want to criticize > or even argue against core.async which is indeed a very nice library (the > power of code walking has always impressed me :-)). >> >> >> >> 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. > > Good to know and FRP certainly has some good ideas which could be exploited > on top of core.async. Maybe one has to give up some of the theoretical > niceties in order to reach an efficient and resource controlled data flow > model. I will try to read some more about CSP and see if I get the > programming model that it employs ... > > Best, > > Nils >> >> >> >> >> David > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to [email protected] > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > [email protected] > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
