Did you ever look into Hoplon/Javelin? Haven't heard much about it on this group recently, and curious why....
On Saturday, December 6, 2014 10:37:20 PM UTC-8, James MacAulay wrote: > > What prompted me to write Zelkova? > > The short answer is curiosity and gut feeling. The long answer: > > I consider core.async (and CSP in general) to be an excellent low-level > abstraction for coordinating concurrency, but I feel like it relies way too > much on mutating operations for me to want to use it much directly in > application code. Like any other mutating code, I want to push it to the > edges as much as possible. Along those lines, I had previously explored > using core.async with JS promises [1] and "async futures" [2]. > > Promises and futures are great (pseudo-?)immutable constructs for > representing single "eventual values", but don't really help at all with > values that change over time. So I wanted to build an FRP library based on > core.async, which seemed like an obviously strong foundation for FRP that > was surprisingly under-explored as such. At first I made some initial stabs > at modelling a system after Bacon.js, which at the time I considered more > attractive than Elm's style of FRP. However, I was fighting too much with > core.async to make it work, and it just felt like the wrong direction. > > I decided to read Evan Czaplicki's 2012 thesis on Elm to understand that > different perspective better, and the more I understood it the more > compelling I found that approach. I had a very similar experience with the > paper as Eric Normand recently described [3], and that Concurrent ML code > was just begging to be ported to core.async :) > > The fact that Elm's signal graphs are static does present some challenges, > but it also brings real benefits (as Evan outlines well in his talk that I > linked in the original post). People are still figuring out how best to > structure larger applications in Elm, but I see a lot of potential. At its > best, Elm code is some of the clearest code I've seen, with almost zero > "baggage" (read: incidental complexity). > > Furthermore, Zelkova brings its own advantages by being embedded in and > implemented entirely in Clojure/ClojureScript. You can reach outside the > strictness of the signal graph whenever you need to, and continue using the > same nice language as when you're working "from within" a graph. Needless > to say, development in Clojure also helps immensely with implementing the > library itself. > > [1]: https://github.com/jamesmacaulay/cljs-promises > [2]: > https://github.com/jamesmacaulay/async-tools/blob/master/test/cljx/jamesmacaulay/async_tools/core_test.cljx#L62-L82 > [3]: http://www.lispcast.com/elm-frp-clojure-core-async > > On Saturday, 6 December 2014 07:01:30 UTC-5, eric wrote: >> >> Hi, >> >> May I ask what prompted you to write this? A coding exercise or some >> real-world need? I'm asking because I've been keeping an eye on FRP for a >> while. From what I understand it's conceptually not ready for anything >> other than toy problems yet. Like Elm's restriction on static flow graphs. >> It's like programming without 1st class functions, you don't get very far. >> >> eric >> >> On Monday, October 20, 2014 11:56:45 AM UTC+11, James MacAulay wrote: >>> >>> I've just published an FRP library based on Elm[1]: >>> >>> https://github.com/jamesmacaulay/zelkova >>> >>> Here's what the app code looks like: >>> >>> >>> https://github.com/jamesmacaulay/zelkova/blob/4b06c49678e11e3af7b1eda7a18929a512f7753d/examples/mario/src/mario/core.cljs#L118-L133 >>> >>> Right now Zelkova includes ports of Elm's Signal, Mouse, Keyboard, and >>> Window libraries, plus part of its Time library[2]. Zelkova's signal >>> namespace works in both Clojure and ClojureScript, but the rest only have >>> implementations for ClojureScript in the browser. >>> >>> Elm-style FRP is a bit different from other flavours like those of Rx or >>> Bacon.js. In particular, Elm's signal graphs are static (can't be >>> reconfigured once they start running) and don't allow for >>> signals-of-signals. >>> >>> Zelkova is the same way, but its signal functions actually return >>> "recipes" for signals which don't start processing values until a "live" >>> graph gets spawned from one of them. This allows multiple live graphs to >>> run concurrently while sharing logical structure, and should make some >>> things easier in the future (like porting Elm's time-travelling debugger). >>> Theoretically this should also make it possible to compile some kinds of >>> signal graphs into transducers instead of running them as networks of >>> core.async channels. >>> >>> If you're interested in the differences and tradeoffs between the >>> different forms of FRP out there, Evan Czaplicki gave an excellent talk on >>> the subject at Strange Loop this year: >>> >>> https://www.youtube.com/watch?v=Agu6jipKfYw >>> >>> Cheers, >>> James >>> >>> [1] http://elm-lang.org >>> [2] >>> https://github.com/jamesmacaulay/zelkova/tree/master/src/cljx/jamesmacaulay/zelkova >>> >>> -- 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/d/optout.
