digitalmars.D - async/await in F#
- bearophile (16/19) Jun 14 2014 In this post:
- Mason McGill (30/30) Jun 14 2014 Good tutorial choices; they're very well-written. I haven't used
- Idan Arye (2/21) Jun 14 2014 Can't we use Fibers to get something similar?
- Rikki Cattermole (11/27) Jun 14 2014 There's actually an interesting research paper [0] I found during this
- Russel Winder via Digitalmars-d (25/25) Jun 15 2014 Scala Async introduces async/await as the way of "simplifying" future
In this post: http://forum.dlang.org/post/l62466$2n8p$1 digitalmars.com Walter said, in November:I agree that async/await has to eventually be added to D. I'm not convinced it can or should be done with AST macros.flexibility: https://mrange.wordpress.com/2014/05/29/why-i-wish-c-never-got-asyncawait/ of a Google search, but also found to be the best references on this topic): tomasp.net/academic/papers/computation-zoo/computation-zoo.pdf http://msdn.microsoft.com/en-us/library/dd233182.aspx http://en.wikibooks.org/wiki/F_Sharp_Programming/Computation_Expressions http://fsharpforfunandprofit.com/series/computation-expressions.html Bye, bearophile
Jun 14 2014
"Mason McGill" <mmcgill caltech.edu>
Good tutorial choices; they're very well-written. I haven't used
understanding):
`async` being just a particular instance of a class of
user/library-defined "computation expression" has a lot of good
things going for it. This setup provides an alternative to nested
lambda expressions that's more readable in some cases. And it's
read without being intimately familiar with the "workflow" you
are using (e.g. `async`). If I see a `for..do` expression inside
an `async` block, I don't know whether `async` has overridden
that syntax unless I open up the `async`'s documentation. It
seems this is easily side-stepped by using explicit syntax (e.g.
designers made some of the syntax overrides stand out (`let!` and
`do!`), but not others (`return` and `while..do`).
Finally, I wonder what happens if you nest computation
expressions:
async {
query {
/* Code for an asynchronous query. */
}
}
My guess it that the inner workflow (`query`) transforms the code
inside it, then passes the result to the outer workflow, which
then transforms it further. This could get confusing quickly, but
I suppose you'd only write something like this if it was the best
way to express your intent, which means the alternatives were
*more* confusing.
Jun 14 2014
On Saturday, 14 June 2014 at 07:53:17 UTC, bearophile wrote:In this post: http://forum.dlang.org/post/l62466$2n8p$1 digitalmars.com Walter said, in November:Can't we use Fibers to get something similar?I agree that async/await has to eventually be added to D. I'm not convinced it can or should be done with AST macros.flexibility: https://mrange.wordpress.com/2014/05/29/why-i-wish-c-never-got-asyncawait/ top of a Google search, but also found to be the best references on this topic): tomasp.net/academic/papers/computation-zoo/computation-zoo.pdf http://msdn.microsoft.com/en-us/library/dd233182.aspx http://en.wikibooks.org/wiki/F_Sharp_Programming/Computation_Expressions http://fsharpforfunandprofit.com/series/computation-expressions.html Bye, bearophile
Jun 14 2014
On 14/06/2014 7:53 p.m., bearophile wrote:In this post: http://forum.dlang.org/post/l62466$2n8p$1 digitalmars.com Walter said, in November:There's actually an interesting research paper [0] I found during this semester about a similar topic. Supposedly when used its able to speed up IO considerably. Its possible with D as it stands to implement this (thanks to our foreach closures ext.). The only reason I haven't done so was because of reconstructing e.g. register state and thread sleeping overriding. Basically while blocking instead of sleeping it will execute the next iteration of a loop. And then go back at the appropriate time. At least that is how I summarized it. [0] http://www.barrelfish.org/barrelfish_oopsla11.pdfI agree that async/await has to eventually be added to D. I'm not convinced it can or should be done with AST macros.https://mrange.wordpress.com/2014/05/29/why-i-wish-c-never-got-asyncawait/ Google search, but also found to be the best references on this topic): tomasp.net/academic/papers/computation-zoo/computation-zoo.pdf http://msdn.microsoft.com/en-us/library/dd233182.aspx http://en.wikibooks.org/wiki/F_Sharp_Programming/Computation_Expressions http://fsharpforfunandprofit.com/series/computation-expressions.html Bye, bearophile
Jun 14 2014
Scala Async introduces async/await as the way of "simplifying" future and promise construction. I haven't played with this much as yet, I have generally just used Future in Scala. Akka had something that was an extension of Scala's Future, but this is now deprecated in favour of Async. (The Akka stuff was way over-complicated to install and use.) Akka used to call this dataflow, and in the sense of dataflow as a single batch job making use of futures and promises to calculate a value, this could be seen as true. Dataflow though is about processes communicating with channels, and is far more interesting than what was called dataflow in Akka. GPars has this much more properly organized and spelled out (*). Go has gone the CSP, with elements of π-calculus, route and so can do dataflow but there are subtle issues which means dataflow should be different from π-calculus, and different from actors. This means D really needs a dataflow module to add to its data parallel module (std.parallelism) and actors module (std.concurrency provides what can be used as actors). (*) For obvious reasons :-) -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 15 2014