I knew about cats from this mailing list, and I went over examples showing the use of mlet but did not come across any examples of alet, so thank you for the whole explanation. Are the awaits try-catchable (assuming the function being called can throw)?
Innovations start in languages like Java, Clojure, Haskel, C# and Elm et al and make their way into JS eventually but what I was suggesting is "core.async" should probably be expanded beyond CSP alone as as many new comers to CLJ/S, such as myself and a few other relative beginners, often think that core.async is the basis for all async stuff you can do in CLJ/S, which as you are explaining is not true, and it takes a while to discover libraries such as cats. Will be definitely playing with the cats patterns you presented here and going over it in more detail. Also, have you seen this? https://github.com/dvlsg/async-csp ... It is CSP style channels implemented with ES7 async/await ... thank you for this! On Sat, Oct 3, 2015 at 1:58 AM, Andrey Antukh <[email protected]> wrote: > > > On Sat, Oct 3, 2015 at 11:15 AM, Marc Fawzi <[email protected]> wrote: > >> While he has a good point to make about the given scenarios, his >> complaining about loss of generality with async/await compared to >> generators and promise api on which async/await is built is misplaced. Loss >> of generality is the obvious consequence of trying to hit the most common >> use cases with the simplest possible syntax and semantics... i.e. you end >> up losing true generality. >> >> The argument I wanted to validate here is if you can implement the very >> common and simple async coordination scenarios with async/await much more >> clearly and suitably than with CSP and if CSP itself as a model can be >> implemented/built using async/await (for more complicated coordination >> scenarios) then it seems to me that async/await would make a more universal >> basis for concurrency management than starting with CSP. >> > > > I understand and I'm pretty convinced that csp as is, is a concurrency > model and can be implemented in different ways. I think that the current > async/await approach is slightly coupled to the promise. > Obviously if you decouple it from promise, a csp can be implemented using > async/await. In fact, async/await is just a sugar syntax. The main error of > the ES7 async/await is that is hard coupled with promises. > > With the link that I have shared in previous email, I mean that generators > are more versatile and also offers the same features that async await. CSP > like abstraction is easily can be implemented on top of > generators/coroutines: https://github.com/ubolonton/js-csp. > > Furthermore, in funcool/cats[1], we have implemented an other way to do it > with more clojure like syntax: `mlet` and `alet` macros. They looks very > familiar because the aspect is like a normal clojure let. The difference is > that them are implemented in terms of abstractions. > > Imagine this example function: > > async function doFoo() { > const x = await doFirstThing() > const y = await doSecondThing(); > return x + y; > } > > With cats abstraction, you do not need any compiler support for implement > async/await, just use a familiar syntax. This is equivalent code in > clojure/clojurescript that does exactly the same thing: > > (require '[cats.core :as m]) > > (defn do-foo > [] > (m/mlet [x (do-first-thing) > y (do-second-thing)] > (m/return (+ x y)))) > > But both, the async/await, and mlet macro has one disadvantage: the code > is inherently serial. But in a lot of circumstances we can optimize the > execution just finding dependencies. You can observe that for calculate x > we do not need any thing from previous execution, and the same for the y. > With `alet` macro you can optimize this kind of cases: > > (defn do-foo > [] > (m/alet [x (do-first-thing) > y (do-second-thing)] > (+ x y))) > > In this code example the operations of x and y are executed in paralel. > And this example uses promises, but we can use core.async channels, > manifold deferreds, jdk8 computable futures, rxjs observables... > > And in future we can add a generalization macro that can look similar to > this: > > (defn do-foo'' > [] > (m/async [x (m/await (do-first-thing)) > y (m/await (do-second-thing)) > z 2] > (+ x y z)))) > > Also, using the same abstractions... > > This that, I intend to say that in clj/cljs we have the power to build > more powerful abstractions that ES7 async/await. > > Regards. > Andrey > > [1]: https://github.com/funcool/cats > > >> >> On Sat, Oct 3, 2015 at 12:34 AM, Andrey Antukh <[email protected]> wrote: >> >>> BTW, >>> http://spion.github.io/posts/es7-async-await-step-in-the-wrong-direction.html >>> >>> On Mon, Sep 28, 2015 at 9:56 PM, Marc Fawzi <[email protected]> >>> wrote: >>> >>>> << >>>> Is there a way to use Javascript's new 'async functions' from within >>>> cljs? I read that Closure compiler can transform es6/7 syntax to es5, given >>>> some command line flags. >>>> >> >>>> >>>> I meant in a way that integrates nicely with ClojureScript? >>>> >>>> The conclusion I'd like to validate is if async/await is a more >>>> universal pattern than CSP because it is designed for the most simple and >>>> common async scenarios but scales up to the more complex CSP scenario, >>>> whereas CSP is the other way around: designed for the most complex async >>>> coordination scenarios but is often applied to the most simple scenarios. >>>> >>>> >>>> >>>> >>>> On Mon, Sep 28, 2015 at 8:11 AM, Marc Fawzi <[email protected]> >>>> wrote: >>>> >>>>> << >>>>> ;; OPTION 3: using Promises;; If you're in ClojureScript, and not >>>>> interested in core.async, you can just use a Promise library:;; - >>>>> funcool/promesa is a ClojureScript wrapper of the popular Bluebird >>>>> JavaScript library.;; - jamesmacaulay/cljs-promises is a Promise >>>>> library designed to operate nicely with core.async.;; Promises take >>>>> care of both asynchrony and error management (they're essentially a mix of >>>>> Futures and Exception Monads); some may say it's convenient, others may >>>>> argue it's not simple. >>>>> >>>>> >> >>>>> >>>>> Is there a way to use Javascript's new 'async functions' from within >>>>> cljs? I read that Closure compiler can transform es6/7 syntax to es5, >>>>> given >>>>> some command line flags. >>>>> >>>>> >>>>> On Sun, Sep 27, 2015 at 3:28 PM, Val Waeselynck <[email protected] >>>>> > wrote: >>>>> >>>>>> Adding my grain of salt: >>>>>> >>>>>> Le mercredi 16 septembre 2015 22:42:19 UTC+2, Andrey Antukh a écrit : >>>>>> > Hi! >>>>>> > >>>>>> > >>>>>> > I think you are comparing apples with oranges. CSP and async/await >>>>>> can't be compared directly. Async/await works with a promise (one value) >>>>>> abstraction and csp works with channel abstraction (sequence). >>>>>> > >>>>>> > >>>>>> > It seems is an anti-pattern use channels as promises because them >>>>>> does not has the notion of error. >>>>>> >>>>>> Actually, I like error management better with core.async than with >>>>>> Promises / Monads, because with little effort you can use the same error >>>>>> constructs for synchronous and asynchronous code: >>>>>> https://gist.github.com/vvvvalvalval/f1250cec76d3719a8343 >>>>>> >>>>>> I do agree that promises are a more natural fit for RPC systems, >>>>>> because of their signal-like nature. I feel I can't really avoid RPC for >>>>>> building web apps, I'd be glad to know about other strategies. >>>>>> >>>>>> >>>>>> I remember that Timothy Baldridge have said something similar about >>>>>> this: >>>>>> > >>>>>> > >>>>>> > "A sort of anti-pattern I see a lot is creating a lot of one-shot >>>>>> channels and go blocks inside every function. The problem, as you see is >>>>>> that this creates a lot of garbage. A much more efficient plan is to stop >>>>>> using core.async as a RPC-like system, and start using it more like a >>>>>> dataflow language: Identity data sources and sinks, and then transform >>>>>> and >>>>>> flow the data between them via core.async. >>>>>> > It's interesting to note that core.async started as something that >>>>>> looked a lot like C#'s Async/Await, but that was dropped in favor of CSP >>>>>> pretty quickly. So there's reasons why the language isn't optimized for >>>>>> this sort of programming style. " >>>>>> > >>>>>> > >>>>>> > Source: >>>>>> https://groups.google.com/d/msg/clojure/57ig0si3gUM/vRr-T1IaebUJ >>>>>> > >>>>>> > >>>>>> > >>>>>> > Without the intention to make spam, the funcool/cats ( >>>>>> https://github.com/funcool/cats) `mlet` macro does something >>>>>> similar in semantics that async/await does. It there some examples using >>>>>> the ES6/7 compatible promise library: >>>>>> http://funcool.github.io/promesa/latest/#sugar-syntax >>>>>> > >>>>>> > >>>>>> > The advantage about this solution is that is generic and can be >>>>>> extended to other async related abstractions as: >>>>>> > - JDK8 CompletableFuture's ( >>>>>> https://github.com/funcool/promissum/blob/master/doc/content.adoc#26-promise-chaining >>>>>> ) >>>>>> > - manifold deferred ( >>>>>> https://github.com/funcool/cats/blob/master/doc/content.adoc#82-manifold-deferred >>>>>> ) >>>>>> > - core.async channels ( >>>>>> https://github.com/funcool/cats/blob/master/doc/content.adoc#81-channel >>>>>> ) >>>>>> > >>>>>> > >>>>>> > Personally, I use core.async to compose different processes, but >>>>>> when I interacting with async apis I almost always use promise >>>>>> abstraction >>>>>> with cats sugar syntax. The promise abstraction semantics fits more >>>>>> properly in async rpc calls that channels because it represents a >>>>>> "eventually available value" and has the notion of error (unlikely >>>>>> core.async channels). >>>>>> > >>>>>> > >>>>>> > Regards. >>>>>> > Andrey >>>>>> > >>>>>> > >>>>>> > On Wed, Sep 16, 2015 at 10:30 PM, Marc Fawzi <[email protected]> >>>>>> wrote: >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > Thanks for that! >>>>>> > >>>>>> > async function baz() { >>>>>> > await* [foo(), bar()]; >>>>>> > } >>>>>> > (defn baz [] >>>>>> > (go >>>>>> > (doseq [c [(foo) (bar)]] >>>>>> > (<! c))))With the core.async case you have to define the >>>>>> channel c, right? It looks cryptic compared to the es7 version. Like "go" >>>>>> what does go mean, seriously? I mean in terms of its English language >>>>>> context. Go does not convey async. And what the heck is <! Are we using >>>>>> bash or something? Some kind of inverted redirection? I guess you can >>>>>> have >>>>>> macros that would make it look just as comprehensible as the es7 async >>>>>> version so people coming into CLJS won't be turned off by the crazy >>>>>> looking >>>>>> syntax and the exposed low level semantics. Maybe a bunch of core.async >>>>>> macros that expose common use cases in a way that anyone can understand >>>>>> without even having to understand CSP basics. In my team, everyone gets >>>>>> the >>>>>> es7 version of things but despite having been CLJS users for 6 months >>>>>> now, >>>>>> no one understands how to use core.async. I've had to play with it in >>>>>> different languages before I realized how powerful it is to have in your >>>>>> toolset to manage complex (potentially dynamic) coordination patterns >>>>>> between async processes but our use cases in the UI have yet to beyond >>>>>> the >>>>>> very simple use cases your gist shows which are (without use of macros) >>>>>> much easier to understand using es7 async functions.If macros can solve >>>>>> the >>>>>> "comprehensibility" problem for the common use cases then maybe something >>>>>> that would provide es7 async like library for cljs that gives you >>>>>> defnasync >>>>>> and await Syntax and semantics can then be so simple while the underlying >>>>>> system remains so powerful and in that case you could have core.async be >>>>>> bundled with those macros thus allowing easy access to common async >>>>>> patterns without the Go syntax obfuscating things and making it seem >>>>>> complicated as well as too noisy syntax wise for the most common tasks >>>>>> > >>>>>> > Sent from my iPhone >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Sep 15, 2015, at 9:38 PM, Shaun LeBron <[email protected]> >>>>>> wrote: >>>>>> > >>>>>> > >>>>>> > ES7 vs core.async (gist): >>>>>> > https://gist.github.com/shaunlebron/d231431b4d6a82d83628 >>>>>> > >>>>>> > On Tuesday, September 15, 2015 at 3:51:06 PM UTC-5, marc fawzi >>>>>> wrote: >>>>>> > Well the title gives that impression and I regret having chose to >>>>>> do that :) >>>>>> > >>>>>> > But if you read the content i am asking the question if Async >>>>>> functions in es7 can be used to build a performant and faithful version >>>>>> of >>>>>> CSP (github: aysnc-csp) and also be useful for common tasks like the >>>>>> simple >>>>>> server request scenario I mentioned then why wouldnt we want to think of >>>>>> CSP as just one pattern not the One True Pattern for async. Right now >>>>>> core.async is being used and or recommended for everything async and I am >>>>>> asking if that is ideal and if CLJS can allow itself to grow beyond this >>>>>> one particular pattern when it comes to async. The first thing would be >>>>>> renaming core.async to core.csp and promoting choice when it comes to >>>>>> async >>>>>> patterns. As it is right now, every time someone has an async design >>>>>> problem core.async is recommended as a solution regardless of whether or >>>>>> not it's the best fit solution. If you have a hammer... >>>>>> > >>>>>> > That's the scope. Not es7 vs core.async and I'm sorry for the >>>>>> stupid title. >>>>>> > >>>>>> > Sent from my iPhone >>>>>> > >>>>>> > On Sep 15, 2015, at 8:32 AM, Johann Bestowrous < >>>>>> [email protected]> wrote: >>>>>> > >>>>>> > At a high level, I think it's pretty important to note that you are >>>>>> comparing a language spec to a library. >>>>>> > >>>>>> > -- >>>>>> > Note that posts from new members are moderated - please be patient >>>>>> with your first post. >>>>>> > --- >>>>>> > You received this message because you are subscribed to the Google >>>>>> Groups "ClojureScript" group. >>>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> > To post to this group, send email to [email protected]. >>>>>> > Visit this group at http://groups.google.com/group/clojurescript. >>>>>> > >>>>>> > -- >>>>>> > Note that posts from new members are moderated - please be patient >>>>>> with your first post. >>>>>> > --- >>>>>> > You received this message because you are subscribed to the Google >>>>>> Groups "ClojureScript" group. >>>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> > To post to this group, send email to [email protected]. >>>>>> > Visit this group at http://groups.google.com/group/clojurescript. >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > >>>>>> > Note that posts from new members are moderated - please be patient >>>>>> with your first post. >>>>>> > >>>>>> > --- >>>>>> > >>>>>> > You received this message because you are subscribed to the Google >>>>>> Groups "ClojureScript" group. >>>>>> > >>>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> > >>>>>> > To post to this group, send email to [email protected]. >>>>>> > >>>>>> > Visit this group at http://groups.google.com/group/clojurescript. >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > Andrey Antukh - Андрей Антух - <[email protected]> >>>>>> > http://www.niwi.nz >>>>>> > >>>>>> > https://github.com/niwinz >>>>>> >>>>>> -- >>>>>> Note that posts from new members are moderated - please be patient >>>>>> with your first post. >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "ClojureScript" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> Visit this group at http://groups.google.com/group/clojurescript. >>>>>> >>>>> >>>>> >>>> -- >>>> Note that posts from new members are moderated - please be patient with >>>> your first post. >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "ClojureScript" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/clojurescript. >>>> >>> >>> >>> >>> -- >>> Andrey Antukh - Андрей Антух - <[email protected]> >>> http://www.niwi.nz >>> https://github.com/niwinz >>> >>> -- >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "ClojureScript" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/clojurescript. >>> >> >> -- >> Note that posts from new members are moderated - please be patient with >> your first post. >> --- >> You received this message because you are subscribed to the Google Groups >> "ClojureScript" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/clojurescript. >> > > > > -- > Andrey Antukh - Андрей Антух - <[email protected]> > http://www.niwi.nz > https://github.com/niwinz > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
