Experiment with async-await. #1

cristianoc · 2022-05-19T04:07:26Z

Build the compiler as usual by following these instructions.

Try the example in example-async. Or go to one of your ReScript repos and do npm link __path_to_rescript-compiler-experiments__.

Notes:

Async functions are written as definitions async (...) => ....
Await expressions are written as await e.
An await expression can only be used in an async context. So e.g. not in the callback of the body of an async function, unless the callback itself is async.
To avoid falling easily in the trap of nested promises, a warning is given when the type checker detects the use of nested promises in an intermediate expression. This check applies to promises in any case, even if one does not use async/await.

cristianoc · 2022-05-19T04:13:48Z

This is what has been explored so far:

type testable = (. unit) => Js.Promise.t<unit>

let tests: array<testable> = []

let addTest = t => tests->Js.Array2.push(t)->ignore
let addTest1 = (t, x) => tests->Js.Array2.push((. ()) => t(. x))->ignore

//
//
// Basic tests

let foo = async (. x, y) => x + y

let bar = async (. ff) => {
  let a = await ff(. 3, 4)
  let b = await foo(. 5, 6)
  a + b
}

let baz = async (. ()) => await bar(. foo)

let testBaz: testable = async (. ()) => {
  let n = await baz(.)
  Js.log2("baz returned", n)
}

testBaz->addTest

//
//
// Catching exceptions

exception E(int)

let e1: testable = async (. ()) => raise(E(1000))
let e2: testable = async (. ()) => Js.Exn.raiseError("Some JS error")
let e3: testable = async (. ()) => await e1(.)
let e4: testable = async (. ()) => await e2(.)
let e5: testable = %raw(`function() { return Promise.reject(new Error('fail')) }`)

let testTryCatch = async (. fn) =>
  try {await fn(.)} catch {
  | E(n) => Js.log2("testTryCatch: E", n)
  | JsError(_) => Js.log("testTryCatch: JsError")
  }

testTryCatch->addTest1(e1)
testTryCatch->addTest1(e2)
testTryCatch->addTest1(e3)
testTryCatch->addTest1(e4)
testTryCatch->addTest1(e5)

//
//
// Check for nested promise

let singlePromise = async (. x) => x + 1

let nestedPromise = async (. x) => {
  let resolve = x => [Js.Promise.resolve(x)]
  let _result = singlePromise(. x + 1)->resolve
  32
}

//
//
// Test error handling in fetch

module Fetch = {
  //@raises(JsError)
  let fetch = url => Fetch.fetch(url)

  let status = response => Fetch.Response.status(response)
}

let explainError: unknown => string = %raw(`(e)=>e.toString()`)

let testFetch = async (. url) => {
  open Fetch
  switch {await fetch(url)} {
  | response =>
    let status = response->status
    Js.log2("Fetch returned status:", status)
  | exception JsError(e) => Js.log2("Fetch returned an error:", e->explainError)
  }
}

testFetch->addTest1("https://www.google.com/sdkjdkghdsg")
testFetch->addTest1("https://www.google.comsdkjdkghdsg")

//
//
// Callbacks
let withCallback = async (. ()) => {
  async (. x) => await (x->Js.Promise.resolve) + 1
}

let testWithCallback = async (. ()) =>
  Js.log2("callback returned", await (await withCallback(.))(. 3))

testWithCallback->addTest

//
//
// Async list
module AsyncList = {
  let map = async (. l, f) => {
    let rec loop = async (. l, acc) =>
      switch l {
      | list{} => acc
      | list{p, ...rest} => await loop(. rest, list{await p, ...acc})
      }

    await loop(. l->Belt.List.mapReverse(x => f(. x)), list{})
  }
}

let fetchAndCount = {
  let counter = ref(0)

  let ff = async (. url) => {
    let response = await Fetch.fetch(url)
    counter := counter.contents + 1
    (counter.contents, response->Fetch.status)
  }

  ff
}

let testFetchMany = async (. ()) => {
  let fetchedItems = await AsyncList.map(.
    list{
      "https://www.google.com",
      "https://www.google.com",
      "https://www.google.com",
      "https://www.google.com",
      "https://www.google.com",
    },
    fetchAndCount,
  )
  fetchedItems->Belt.List.forEach(((i, s)) => Js.log3("Fetched", i, s))
}
testFetchMany->addTest

//
//
// Fetch with Result type
module FetchResult = {
  let fetch = async (. url) => {
    switch {await Fetch.fetch(url)} {
    | response => Ok(response)
    | exception JsError(e) => Error(e)
    }
  }
}

let nextFetch = (. _response) => Some("https://github.com/")

let testFetchWithResult = async (. ()) => {
  switch await FetchResult.fetch(. "https://www.google.com") {
  | Ok(response1) =>
    Js.log2("FetchResult response1", response1->Fetch.status)
    switch nextFetch(. response1) {
    | None => ()
    | Some(url) =>
      switch await FetchResult.fetch(. url) {
      | Ok(response2) => Js.log2("FetchResult response2", response2->Fetch.status)
      | Error(_) => ()
      }
    }
  | Error(_) => ()
  }
}

// // imaginary syntax
// let testFetchWithResult = async () =>
//   if let Ok(response1) = await FetchResult.fetch("https://www.google.com")
//      and Some(url) = nextFetch(response1)
//      and Ok(response2) = await FetchResult.fetch(url) {
//     Js.log2("FetchResult response2", response2->Fetch.Response.status)
//   }

testFetchWithResult->addTest

//
//
// Run tests

let rec runAllTests = async (. n) => {
  if n >= 0 && n < Array.length(tests) {
    await (@doesNotRaise tests[n])(.)

    await runAllTests(. n + 1)
  }
}

runAllTests(. 0)->ignore

//
//
// Curried functions

let bb = async (x) => await x

let cc = async (x, ~y=x, z) => (await x) + await y + (await z)

let dd = async (x) => {y => (await x) + (await y)}

let ee = async (. x) => {y => (await x) + (await y)}

//
//
// Errors

// let aa =
//   async
//   (. x) => {
//     let cb = (. _) => await x // Error: Await on expression not in an async context
//     cb
//   }

// let _ = async (_, . x) => await x // Error: Await on expression not in an async context

IwanKaramazow · 2022-07-05T07:04:37Z

An await expression can only be used in an async context. So e.g. not in the callback of the body of an async function, unless the callback itself is async.

Modern browsers also allow top-level await in modules. Should this be supported by the ReScript compiler?

cristianoc · 2022-07-05T07:26:22Z

An await expression can only be used in an async context. So e.g. not in the callback of the body of an async function, unless the callback itself is async.

Modern browsers also allow top-level await in modules. Should this be supported by the ReScript compiler?

Possibly. What are the pluses and minuses?

cristianoc · 2022-07-05T07:27:42Z

One immediate question is why at top level in a file and not at top level in a submodule.
And if one wants at top level in a submodule, should that be an async submodule? What does it mean?

cristianoc · 2022-07-05T07:30:34Z

I'd probably be inclined to keep changes to a minimum for now, unless future changes are likely to affect today's design.
As long as it is possible to add the extra features later, it can be done once people have tested this extensively.

IwanKaramazow · 2022-07-05T07:54:35Z

Agreed, let's revisit this at a later point in time. (if needed)

Reasoning: In JavaScript `await` is a keyword *only* inside async functions. ```javascript let await = 1 // OK ✅ async function wait() { let await = 1 // NOT OK ❌ } ``` The plot twist is that the newer browsers (chrome or node) support top-level await. (By implicitly wrapping everything in an async function?) ```javascript let await = 1 // NOT OK, with top level await ❌ ``` This makes me think: * We can replicate JavaScript parser; inside async function expressions, use of `await` as identifier will result into a syntax error - Downside: this feels like a responsibility for another part of the compiler, not the parser? This is already implemented in cristianoc/rescript-compiler-experiments#1, so we would also be doing double work. - Other downside: if we ever allow top-level await, then we just implemented the above for nothing. * Allow `await` as a "non-keyword" everywhere with some "tricks". ```javascript let await = 1 let x = await // Ok, now it gets tricky. Does this start an "await"-expression? = await fetch(url) // could be this = await() // could be this = await await() // or even this = await // or we might just be assigning the identifier `await` to `x` ``` Seems like we can infer the following rules for an `await expression`: - space after `await` - next token is on the same line as `await` - next token indicates the start of a unary expression But this "breaks down" in the case of ```javascript let x = await - 1 // could be a binary expression: "identifier" MINUS "1" // could also be an await expression with a unary expression: `await` `(-1)` ``` These whitespace sensitive rules kinda feel super arbitrary. Which makes me think that introducing `await` as a keyword is an ok compromise.

example-async/src/AA.res

cristianoc · 2022-07-07T15:39:32Z

@IwanKaramazow one more thing:

let withCallback = async (. ()) => {
  async (. x) => await (x->Js.Promise.resolve) + 1
}

formats to:

let withCallback = async (. ()) => {
  async (. x) => await x->Js.Promise.resolve + 1
}

which does not compile.

See rescript-lang/syntax#600

Pull in rescript-lang/syntax#600

Reasoning: In JavaScript `await` is a keyword *only* inside async functions. ```javascript let await = 1 // OK ✅ async function wait() { let await = 1 // NOT OK ❌ } ``` The plot twist is that the newer browsers (chrome or node) support top-level await. (By implicitly wrapping everything in an async function?) ```javascript let await = 1 // NOT OK, with top level await ❌ ``` This makes me think: * We can replicate JavaScript parser; inside async function expressions, use of `await` as identifier will result into a syntax error - Downside: this feels like a responsibility for another part of the compiler, not the parser? This is already implemented in cristianoc/rescript-compiler-experiments#1, so we would also be doing double work. - Other downside: if we ever allow top-level await, then we just implemented the above for nothing. * Allow `await` as a "non-keyword" everywhere with some "tricks". ```javascript let await = 1 let x = await // Ok, now it gets tricky. Does this start an "await"-expression? = await fetch(url) // could be this = await() // could be this = await await() // or even this = await // or we might just be assigning the identifier `await` to `x` ``` Seems like we can infer the following rules for an `await expression`: - space after `await` - next token is on the same line as `await` - next token indicates the start of a unary expression But this "breaks down" in the case of ```javascript let x = await - 1 // could be a binary expression: "identifier" MINUS "1" // could also be an await expression with a unary expression: `await` `(-1)` ``` These whitespace sensitive rules kinda feel super arbitrary. Which makes me think that introducing `await` as a keyword is an ok compromise.

bobzhang · 2022-09-09T03:57:49Z

Do you have some high level docs on the encoding?
I suppose await is translated into a function, what async will be translated into?

since we are going to treat promise type with some special caveats, we can make promise a built in type and alias Js.Promise.t = promise``
How do you detect await in a non async function, is it done in the ast checker?

cristianoc · 2022-09-09T04:26:56Z

Let me point directly at the main repo, which has more cleanup. Here I just wanted to show the code for checking nested promises.

Do you have some high level docs on the encoding? I suppose await is translated into a function, what async will be translated into?

await is indeed translated to a function https://github.com/rescript-lang/rescript-compiler/blob/master/jscomp/frontend/ast_await.ml
async is first an attribute and later represented directly at the lambda level https://github.com/rescript-lang/rescript-compiler/blob/master/jscomp/ml/lambda.mli#L273

The high level description is quite simple: some well formed-ness checks are performed at the ast level, so you can only await in an async context. Then the info about async and await is simple preserved throughout the pipeline until they are emitted verbatim. Nothing surprising there.

Plus, a warning is emitted in case of nested promises used anywhere (e.g. in a sub-expression). This check is orthogonal in principle, but goes well with this feature. I was not sure how to check "anywhere" hence the possibly deep type traversal. This is best effort of course, as the type could be inferred later.

since we are going to treat promise type with some special caveats, we can make promise a built in type and alias Js.Promise.t = promise``

Makes sense.

bobzhang · 2022-09-09T04:47:30Z

Plus, a warning is emitted in case of nested promises used anywhere (e.g. in a sub-expression). This check is orthogonal in principle, but goes well with this feature. I was not sure how to check "anywhere" hence the possibly deep type traversal. This is best effort of course, as the type could be inferred later

This feature could be submitted in a separate PR? It seems not harmful if it is opt-in

cristianoc · 2022-09-09T05:08:18Z

Done the built-in promise
rescript-lang/rescript#5650

Is there a way to check for both promise and Js.Promise.t?
E.g. this uses both:

let doublePromise = async (p:Js.Promise.t<int>) => p

cristianoc · 2022-09-09T05:21:55Z

Done the built-in promise rescript-lang/rescript-compiler#5650

Is there a way to check for both promise and Js.Promise.t? E.g. this uses both:
let doublePromise = async (p:Js.Promise.t<int>) => p

I guess one could use something like this done for option?

let extract_option_type env ty =
  match expand_head env ty with {desc = Tconstr(path, [ty], _)}
    when Path.same path Predef.path_option -> ty
  | _ -> assert false

d4h0 · 2022-10-28T13:41:18Z

@cristianoc: Thanks for your amazing work on this!

I'm testing the RC at the moment, and noticed that the current implementation requires parentheses, where I didn't expect them to be required.

Wouldn't it be better, if await had a precedence that would not require these parentheses?

As an example, the following:

let br = playwright.chromium -> setup
let br = await br->BrowserType.launch
let page = await br->Browser.newPage
await page->Page.goto("https://example.com")

...fails with Somewhere wanted: promise<'a>.

Instead, I had to use the following:

let br = playwright.chromium -> setup
let br = await (br->BrowserType.launch)
let page = await (br->Browser.newPage)
await (page->Page.goto("https://example.com"))

...which doesn't seem great.

To me, it seems, that br->BrowserType.launch is equal to BrowserType.launch(br), so await br->BrowserType.launch should behave exactly like await BrowserType.launch(br), I feel.

Was this issue discussed somewhere?

cknitt · 2022-10-28T16:02:21Z

Yes, see rescript-lang/syntax#686

mvaled · 2022-12-21T11:37:43Z

Is this being developed now on the main repo (after removal of submodules)? Is this completely abandoned?

cristianoc · 2022-12-21T11:51:04Z

Is this being developed now on the main repo (after removal of submodules)? Is this completely abandoned?

Yes

cristianoc force-pushed the async-await branch from 8c752c1 to b63d66a Compare June 12, 2022 00:42

cristianoc force-pushed the async-await branch from b63d66a to 31e5604 Compare June 23, 2022 03:44

cristianoc force-pushed the async-await branch from 31e5604 to b90ac95 Compare July 5, 2022 06:54

IwanKaramazow mentioned this pull request Jul 6, 2022

Done, but do not merge yet: Async/Await syntax. rescript-lang/syntax#600

Merged

cristianoc commented Jul 7, 2022

View reviewed changes

example-async/src/AA.res Outdated Show resolved Hide resolved

cristianoc added 17 commits July 11, 2022 04:45

Experiment with async-await.

c8c4165

Add example project example-async.

722bd77

Use @async attribute instead of an external.

9e9f6ad

Remove old support for async primitive.

60d8fa4

Add recursive function to run all tests.

3a6a88a

Support for @await decorator.

fc565eb

Support async callbacks.

0300cfd

tweak callback example

c3deada

Add async list example.

b4cf03a

Clean up treatment of async attribute.

27e5da0

Work around funny pretty printer formatting of await.

40f8549

Clean up.

de1a94a

clean up dump

a7108dc

format dump

5b87456

More cleanup.

7bdf4eb

Give error when awaiting not in an async context.

99dfce2

Give error when async is applied to a curried function.

90427ed

cristianoc added 14 commits July 11, 2022 04:45

Example with exception-annotated fetch.

31d304d

tweak example

df9fcbc

snapshot

d4ebe16

Rebase on latest 10.0 alpha compiler.

53b5950

Begin preparing for source syntax.

29d83b8

See rescript-lang/syntax#600

Pull in the surface syntax from the syntax submodule.

1299f6e

Pull in rescript-lang/syntax#600

Make sure the example still builds.

c233a1f

Example: switch to the new res.* attributes.

87b9033

Example: switch async to surface syntax.

d414bc5

Switch over await's to surface syntax.

eb3dbaf

Sync latest surface syntax.

f9a8eb4

Almost reformat.

fd46313

One more syntax sync.

17b3dcd

Update .prettierignore

baf8d45

Rebase on latest compiler.

0c8fb12

cristianoc force-pushed the async-await branch from aa56e25 to 0c8fb12 Compare July 11, 2022 02:54

cristianoc mentioned this pull request Jul 11, 2022

Async await support rescript-lang/rescript#5537

Merged

4 tasks

cknitt mentioned this pull request Oct 29, 2022

Latest syntax rescript-lang/rescript#5762

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Experiment with async-await. #1

Experiment with async-await. #1

cristianoc commented May 19, 2022 •

edited

Loading

cristianoc commented May 19, 2022 •

edited

Loading

IwanKaramazow commented Jul 5, 2022

cristianoc commented Jul 5, 2022

cristianoc commented Jul 5, 2022

cristianoc commented Jul 5, 2022

IwanKaramazow commented Jul 5, 2022 •

edited

Loading

cristianoc commented Jul 7, 2022

bobzhang commented Sep 9, 2022 •

edited

Loading

cristianoc commented Sep 9, 2022

bobzhang commented Sep 9, 2022

cristianoc commented Sep 9, 2022

cristianoc commented Sep 9, 2022

d4h0 commented Oct 28, 2022

cknitt commented Oct 28, 2022

mvaled commented Dec 21, 2022

cristianoc commented Dec 21, 2022

Experiment with async-await. #1

Are you sure you want to change the base?

Experiment with async-await. #1

Conversation

cristianoc commented May 19, 2022 • edited Loading

cristianoc commented May 19, 2022 • edited Loading

IwanKaramazow commented Jul 5, 2022

cristianoc commented Jul 5, 2022

cristianoc commented Jul 5, 2022

cristianoc commented Jul 5, 2022

IwanKaramazow commented Jul 5, 2022 • edited Loading

cristianoc commented Jul 7, 2022

bobzhang commented Sep 9, 2022 • edited Loading

cristianoc commented Sep 9, 2022

bobzhang commented Sep 9, 2022

cristianoc commented Sep 9, 2022

cristianoc commented Sep 9, 2022

d4h0 commented Oct 28, 2022

cknitt commented Oct 28, 2022

mvaled commented Dec 21, 2022

cristianoc commented Dec 21, 2022

cristianoc commented May 19, 2022 •

edited

Loading

cristianoc commented May 19, 2022 •

edited

Loading

IwanKaramazow commented Jul 5, 2022 •

edited

Loading

bobzhang commented Sep 9, 2022 •

edited

Loading