async/await in F#

Mason McGill via Digitalmars-d digitalmars-d at puremagic.com
Sat Jun 14 12:24:55 PDT 2014


Good tutorial choices; they're very well-written. I haven't used 
F# much, but here's my take (call me out on any mistakes in my 
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 
far more future-proof than C#'s approach.

There was one thing I didn't like about monadic F#: it's hard to 
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. 
`for!` instead of `for`), which makes me wonder why the F# 
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.


More information about the Digitalmars-d mailing list