Hank, I did my best to answer your questions and respond to your thoughts as I understand them, below. Thanks in advance for interpreting my suppositions and word choices liberally, as the words and ideas in this area of computing are notoriously overloaded.
I'm looking forward to viewing your Clojure/West talk as soon as it comes > out on video. > Thanks! > In the meantime, I don't think javelin qualifies as "functional reactive". > It is just "reactive". State like this: > https://github.com/tailrecursion/javelin/blob/master/src/cljs/tailrecursion/javelin/core.cljs#L64 > is > place-oriented computing vs. the value-oriented computing that FP is aiming > for. > Cell deref rarely appears in user code, and signifies departure from Javelin's evaluation environment. Even so, if one admits Clojure + refs as "FP", I think there remains an argument to sell the Javelin model as "functional". > The functional qualifier would require that producers output some > immutable data structure that consumers read. This is important for > concurrency, so that each producing/consuming task can run in separate > thread and be scheduled at will, decoupled from any other task. This is a > Hard Problem (tm). Infinite sequences are a popular data structure for > decoupling consumers from producers, but naive implementations lead to > uncontrolled resource usage esp. when it gets more complicated with higher > order functions. > Javelin was not particularly designed to tackle concurrency, but we think the Javelin model might empower the underlying propagation machinery to leverage concurrency in a JVM implementation. > In the JavaScript world, Elm tries to tackle this. They have the right > goals but not yet the right implementation if I understand correctly. E.g. > see this discussion: > https://groups.google.com/d/msg/elm-discuss/7oFhwuIX0Go/OA3rvEh-lcIJ > Yes, Classic FRP's switch operation can be thought of as a concurrency primitive not unlike Go's switch statement, and EventStream objects can be thought of as a kind of coroutine. I don't think Elm is tackling this, as browser JSVMs aren't generally multi-threaded, but maybe other FRP impls. are. Re: the discussion you linked: to the extent that one can implement green threads with arrows or CPS, switch might be useful as a (contrived?) concurrency primitive in single-threaded environments. On a meta note, I am glad every time FRP comes up in Clojure circles. The > reactive space is populated by naive implementations that don't scale and > fail at concurrency on the one side, and academic Haskell-types that > conjure up unimplementable pie-in-the-sky schemes on the other side. The > hope is that Clojure folks are ambitious enough to produce something that > scales in complexity and performance while having plenty real-world > scenarios to test their schemes against at their disposal > Yes, I'm glad when it comes up too. I'm personally convinced there's a lot of utility in the general idea of dataflow, and look forward to further developments in the Clojure space. Alan . > > Cheers > -- hank > > On Wednesday, February 20, 2013 6:33:56 PM UTC+11, Alan Dipert wrote: >> >> Hi all, >> We recently released a ClojureScript library for FRP called Javelin. >> Links of interest: >> >> * Release announcement: >> http://tailrecursion.com/blog/2013/02/15/introducing-javelin-an-frp-library-for-clojurescript/ >> * Demos (more on the way): http://tailrecursion.com/~alan/javelin-demos/ >> * GitHub project: https://github.com/tailrecursion/javelin >> >> In a nutshell, Javelin is an abstract spreadsheet that encourages working >> with concrete values instead of abstract event streams a la FRP. It >> supports "discrete propagation", which most FRP implementations provide as >> the event stream, via the ability to toggle cells between >> discrete/continuous propagation modes. Cell mutation semantics are those >> of ClojureScript atoms. >> >> We have ported Javelin's core to a ref-based Clojure implementation >> capable of parallel propagation and hope to release it soon. Among other >> things, our hope is to use it to process Prismatic graph [1] -compatible >> workflows reactively. If you are using graph or flow [2] and are >> interested in reactive processing, and wouldn't mind helping us with >> performance testing, drop me a line. >> >> Thanks for giving Javelin a look! I look forward to your feedback and >> collaboration. >> >> Alan >> >> 1. https://github.com/Prismatic/plumbing >> 2. https://github.com/stuartsierra/flow >> >> >> >> >> -- -- 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.
