Reason: Built in syntax for async.

Created on 14 Mar 2016 · 14Comments · Source: reasonml/reason

I've really liked Lwt's syntax for async (including the integration with try, let, and let + and for simultaneously async calls). We can bake this into Reason by default with something like let!, and then allow configuration of which library it should represent.

Imagine putting an attribute at the top of the file such as:

[@async Lwt];

[@async Async];

which could influence which library is used for that first class let binding syntax.

For the implementation, we could reuse Lwt's ppx plugin perhaps.

RFC

Source

jordwalke

Most helpful comment

F# computation expressions are nice. You can specify the “builder” outside the let! block so you can have let! with different meaning in one file depending on the context.

gaearon on 14 Mar 2016

❤2 👍1

All 14 comments

Syntax for monadic code will interact well with implicits: if you desugar

 let! x = e in
 let! y = e' in
   return (g x y)

into

 e >>= fun x ->
 fun e' >>= fun y ->
 return (g x y)

then you can just use implicits to pick the appropriate implementation of >>=.

Since the desugaring should be the same in any case, even without implicits you can write something like this

  Lwt.(
   let! x = e in
   let! y = e' in
   return (g x y)
  )

to avoid the need for a magic attribute.

yallop on 14 Mar 2016

❤2

What would be the default? Optionals?
That would be useful.

cristianoc on 14 Mar 2016

F# computation expressions are nice. You can specify the “builder” outside the let! block so you can have let! with different meaning in one file depending on the context.

gaearon on 14 Mar 2016

❤2 👍1

Yes, I also think that the F# async ability to select the desired monad on a per-block rather than per-file basis is a significant benefit. Nesting them (essentially shadowing the outer let! by the inner one) also ought to work.

jberdine on 14 Mar 2016

@gaearon That sounds like what I'm describing with attributes. You can put the "provider" of that asynchronicity at the to of the file, or even scoped to some lexical block, because you can place attributes anywhere in the tree.

jordwalke on 14 Mar 2016

Ah okay, I didn’t realize

you can place attributes anywhere in the tree

gaearon on 14 Mar 2016

Ah okay, I didn’t realize

It's not obvious, and that doesn't mean it won't require some effort to replicate the nice scoping rules of lexical scoping.

We might be able to do it without attribute nodes in the AST, and instead just open the right module.

jordwalke on 14 Mar 2016

@yallop Have you seen Lwt's ppx extension? It seems to do that and much more (considers and bindings as being parallel, also unifies match/with with this same monadic concept). I am very much looking forward to modular implicits as well.

jordwalke on 15 Mar 2016

@jordwalke: I'm not that familiar with Lwt's ppx extension, but I know Jane Street's ppx_let, which does something similar (including parallel computation support for let ... and) and various other implementations. I think the important thing is to have two independent components:

a way to desugar things like let into things like >>=. There are a few choices here (Lwt's ppx extension, ppx_let, ...)
a way to choose _which_ >>= to use in a particular block of code. This should be a separate step from desugaring and is best done via core language mechanisms such as local opens or implicits.

yallop on 15 Mar 2016

👍2

I'm probably missing some context here, but if ! means what I think it means, how would you express the following (which is valid using Babel/regenerator in JavaScript today) in Reason:

async function(): Promise<void> {
  if (await someCall()) {
    const [first, second] = Promise.all([thisReturnsAPromise(), thisAlsoReturnsAPromise()]);
  }
}

I believe there was a proposal to add syntactic sugar for Promise.all() that died, which would have allowed for something like:

async function(): Promise<void> {
  if (await someCall()) {
    const [first, second] = await* thisReturnsAPromise(), thisAlsoReturnsAPromise();
  }
}