Closed azz closed 3 years ago
I think with the current proposal semantics, it would be translated this way:
double(await ?)
//=>
double(x => await x)
...because the ?
operator only applies to the immediately surrounding invocation (hence the motivation for #13).
If partial application results in eager evaluation, I would need to add a special form for ?
to allow await ?
to work, but in that case the semantics are more like:
const foo = await (1
|> (async x => addOne(await x))
|> (async y => double(await y))
);
Another approach might be to have some syntax for an async pipeline, similar to for await
, e.g.:
const foo = 1
await |> addOne(?)
await |> double(?);
You can easily achieve the same thing without a special syntax:
const foo = await p
.then(addOne(?))
.then(double(?))
Wouldn't addOne(?)
be the same as x => addOne(x)
?
Yes, but the point is that with promises, it's moderately a moot point because we already have then
.
Given that the pipeline proposal has moved forward with Hack-style, and the new syntax and semantics from #49, this is no longer an issue for partial application.
Since partial application is eager, f~(await p, ?)
would perform the following steps:
f
(we'll call that _f
for the purpose of this algorithm)p
(as _p
)await _p
(as _await_p
)_f~(_await_p, ?)
The same would apply to yield
.
I've added these along with desugaring examples to EXAMPLE.md in the repository root.
Context: https://github.com/tc39/proposal-pipeline-operator/issues/53
Does it make sense to introduce a way to integrate the syntax of this proposal and the pipeline proposal in the case of async functions?
If it was legal to place
await
within a partially applied function when part of a pipeline, then:would be loosely equivalent to:
which in turn is loosely:
Syntax alternative: