www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - async/await in F#

reply "bearophile" <bearophileHUGS lycos.com> writes:
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
next sibling parent "Mason McGill" <mmcgill caltech.edu> writes:
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
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
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:

 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
Can't we use Fibers to get something similar?
Jun 14 2014
prev sibling next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
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:

 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.
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
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.pdf
Jun 14 2014
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
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