Re: Re: New Promise Syntax Proposal

[Mat At Bread]

I proposed an enhanced definition for `async return` and `async throw` to 
address this issue 
in https://github.com/tc39/ecmascript-asyncawait/issues/38 – it didn’t get 
accepted, however it is implemented in rodent 
(see https://github.com/MatAtBread/nodent#exiting-async-functions-from-callbacks)



Using it would produce an async function like:

```javascript


async function requestInput(question) {
   interface.question(question, function(input) {
   async return input ;
   });
}

```


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: monadic extension to do-notation

[Mat At Bread]

The conflation of assignment and awaiting is a bad idea. It leads to lots 
of unnecessary temporary variables and makes anything but the simplest 
expression involving more than one await/promise very ugly - akin to the 
original syntax you're trying to avoid with inner variable declarations and 
<- operations.


A very similar syntax was used by nodent until v1 when it was replaced with 
async and await.


I'd be much more interested in a VM extension that performed auto 
boxing/unboxing on Promises, achieving a similar result without the need 
for additional syntactic constructions




--
monadic extension to do-notation
From: Raphael Mu 
Date: 7 Feb, 17:07
To: es-discuss@mozilla.org

The ES Promise is an instance of Monad, a property that implies a much more
concise and expressive syntax for using Promise, by exploiting its monadic
properties. I've seen a lot of people complain about Promises having too
clumsy a syntax, and likewise for async/await.

We now have the do-notation proposal (
http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions), and
monadic assignment would fit well into the syntax.

The extension would allow use of `<-` within a do-expression for binding
Promise values to variables, and the computation would behave most
similarly to the Either monad in Haskell (in the following code, if
promiseA or promiseB reject, the result of the entire expression would be a
rejected Promise).

(monadic extension)
```javascript
let finalPromise = do {
let a <- promiseA;
let b <- promiseB;
let c = f(a, b);
g(a, b, c)
}
```

(desugared to async/await)
```javascript
let finalPromise = (async () => {
let a = await promiseA;
let b = await promiseB;
let c = f(a, b);
return g(a, b, c);
})();
```

(desugared to ES6)
```javascript
let finalPromise = promiseA.then(a =>
promiseB.then(b => {
let c = f(a, b);
return g(a, b, c);
})
);
```

The do-notation would apply Promise.resolve to the last expression (like
async and Promise#then), effectively returning another Promise. The current
proposal doesn't specify this behavior, but there are two ways about this
collision:

1. use an explicit version of do-notation, e.g. `async do { ... }` or `do*
{ ... }`
2. revise the do-notation proposal to always apply Promise.resolve to the
last expression

Both choices give us a new Promise literal for free: `do* { x }` (1) or `do
{ x }` (2) would be functionally equivalent to `Promise.resolve(x)`.

The idea was briefly mentioned several years ago, but didn't attract much
attention (
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021624.html).

This is an earlier draft of this proposal:
https://github.com/edge/es-monadic



--
Re: monadic extension to do-notation
From: Rick Waldron 
Date: 7 Feb, 17:19
To: Raphael Mu , es-discuss@mozilla.org

What does this do?


let finalPromise = do {
let a;
a <- b;
}


Currently, that's an expression that means "a less than negated b"

Rick

On Sun, Feb 7, 2016 at 12:07 PM Raphael Mu  wrote:


The ES Promise is an instance of Monad, a property that implies a much
more concise and expressive syntax for using Promise, by exploiting its
monadic properties. I've seen a lot of people complain about Promises
having too clumsy a syntax, and likewise for async/await.

We now have the do-notation proposal (
http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions), and
monadic assignment would fit well into the syntax.

The extension would allow use of `<-` within a do-expression for binding
Promise values to variables, and the computation would behave most
similarly to the Either monad in Haskell (in the following code, if
promiseA or promiseB reject, the result of the entire expression would be a
rejected Promise).

(monadic extension)
```javascript
let finalPromise = do {
let a <- promiseA;
let b <- promiseB;
let c = f(a, b);
g(a, b, c)
}
```

(desugared to async/await)
```javascript
let finalPromise = (async () => {
let a = await promiseA;
let b = await promiseB;
let c = f(a, b);
return g(a, b, c);
})();
```

(desugared to ES6)
```javascript
let finalPromise = promiseA.then(a =>
promiseB.then(b => {
let c = f(a, b);
return g(a, b, c);
})
);
```

The do-notation would apply Promise.resolve to the last expression (like
async and Promise#then), effectively returning another Promise. The current
proposal doesn't specify this behavior, but there are two ways about this
collision:

1. use an explicit version of do-notation, e.g. `async do { ... }` or `do*
{ ... }`
2. revise the do-notation proposal to always apply Promise.resolve to the
last expression

Both choices give us a new Promise literal for free: `do* { x }` (1) or
`do { x }` (2) would be functionally equivalent to `Promise.resolve(x)`.

The idea was briefly mentioned several years ago, but 

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Mat At Bread]

I'd also prefer this. Plus, one could use 'try' in an expression context as 
a unary operator.



// z is undefined if a or a.b or a.b.c are undefined
z = try a.b.c ;

// x is undefined if a exists but b or c don't. It throws a ReferenceError 
if a doesn't exist.

x = a.(try b.c) ;



I've not thought it through all the way, but an implementation would be an 
implicit catch that re-throws on anything that's not a ReferenceError, e.g.



x = a ;
try {
   x = x.b.c ;
} catch(ex) {
   if (!(ex instanceof ReferenceError))
   throw ex ;
}


_
Re: Optional Chaining (aka Existential Operator, Null Propagation)
From: Kevin Smith 
Date: 5 Feb, 15:22
To: Claude Pache 
CC: es-discuss 

Show quoted text


Just curious: what's the rationale for that behavior, as opposed to "deep"
short-circuiting? It seems like if I have a long query, like:

a.b.c.d

I think I would typically want to test that the whole query is satisfiable
(not just a single term), so I'll need to write:

a?.b?.c?.d



On 5 February 2016 5:08:38 p.m. es-discuss-requ...@mozilla.org wrote:


Send es-discuss mailing list submissions to
es-discuss@mozilla.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.mozilla.org/listinfo/es-discuss
or, via email, send a message with subject or body 'help' to
es-discuss-requ...@mozilla.org

You can reach the person managing the list at
es-discuss-ow...@mozilla.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of es-discuss digest..."



--
Today's Topics:

   1. Re: Optional Chaining (aka Existential Operator, Null
  Propagation) (Kevin Smith)
   2. January 26th 2016 Meeting Notes (Rick Waldron)



--
Re: Optional Chaining (aka Existential Operator, Null Propagation)
From: Kevin Smith 
Date: 5 Feb, 15:22
To: Claude Pache 
CC: es-discuss 



Yes: the `?.` operator does not change the meaning of the subsequent `.`
operator. I like to think of it as: the effect is local (short-circuiting
aside), you are not switching between "modes". It’s a feature.



Just curious:  what's the rationale for that behavior, as opposed to "deep"
short-circuiting?  It seems like if I have a long query, like:

a.b.c.d

I think I would typically want to test that the whole query is satisfiable
(not just a single term), so I'll need to write:

a?.b?.c?.d



--
January 26th 2016 Meeting Notes
From: Rick Waldron 
Date: 5 Feb, 17:08
To: es-discuss 

January 26th 2016 Meeting Notes

Eric Farriauolo (EF), Caridy Patino (CP), Michael Ficarra (MF), Peter
Jensen (PJ), Domenic Denicola (DD), Jordan Harband (JHD), Leland Richardson
(LM), Chip Morningstar (CM), Brian Terlson (BT), John Neumann (JN), Dave
Herman (DH), Yehuda Katz (YK), Jeff Morrison (JM), Lee Byron (LB), Daniel
Ehrenberg (DE), Lars Hansen (LH), Nagy Hostafa (NH), Michael Saboff (MS),
John Buchanan (JB), Stefan Penner (SP), Sebastian McKenzie (SMK), Waldemar
Horwat (WH), Mark S. Miller (MM), Paul Leathers (PL), Sebastian Markbage
(SM), Zibi Braniecki (ZB), Andreas Rossberg (ARB), Ian Halliday (IH), Keith
Miller (KM), Tim Disney (TD), Misko Hevery (MH), Brad Green (BG), Kevin
Smith (KS), Brad Nelson (BN), JF Bastien (JFB), Shu-yu Guo (SYG), Rick
Waldron (RW), Staś Małolepszy (STM), Dean Tribble (DT)


## Agenda

https://github.com/tc39/agendas/blob/master/2016/01.md


## Approval of the minutes from November 2015

WH: what sort of changes?

JHD: some editorial cleanup

 Conclusion/Resolution

  - Minutes approved.



## 5. Proposals for Future Editions

## 5.i Zones

DD: Misko is presenting, zones.

https://docs.google.com/presentation/d/1H3E2ToJ8VHgZS8eS6bRv-vg5OksObj5wv6gyzJJwOK0/edit#slide=id.p

MH: Writing async code is hard, specifically book keeping of (begin/end of
async tasks). Specifically for framework authoring, and cooperation between
various components. In other langauges, this may be "domains" or "contexts".

MH: some existing implementations, Angular Zone.js, Zone, Dart Zones,
Node.js domains/continuation local storage/asyncwrap, c# logical call
context etc.

MH: this has been around for some time, but the lack of standarization
prevents interopt and may also prevent more ideal solutions.

MH: Frameworks often what to know when work has begun and completing, this
allows for batching.

WH: Can you clarify the example?

MH: In a typcial application, a whole orchistration of async tasks occurs

YK: browser do this already, flush work -> calculate changes -> paint.

MH: by annotating different context, prioritizaing is possible. One example
would be animation context vs ..

WH: thanks

MH: another example is testing, existing solutions result in test
"flickering", but using zones would enable some determism.

BT: test262 would benefit 

Re: Legitimate uses of IIFEs?

[bread]

Ok, I'm convinced :)

Whether the solution is to invent new syntax or not is moot. It occurred to me 
that 'async' could be used as a modifier preceding a block, e.g.

async {
let user = await fetchUser(id);
let scores = user.scores.map(score => score.latest);
let data = await fetchData(scores);
}

...with the caveat (of course) that the body will execute out of order. Or 
possibly modify the 'do' specification to stipulate that the body of the do {} 
has the semantics of an async function body, allowing 'await' to be implemented 
as a keyword. This would seem to fit in better with the OPs observation that 
do, amongst other constructs, renders IIFEs less necessary than before.

On 20 December 2015 23:48:42 -00:00, Dmitry Soshnikov 
<dmitry.soshni...@gmail.com> wrote:

> But how would you make an async entry point? Say, you have couple of async 
> functions which you imported, they should be ran sequentily, depending on 
> each other:
> 
> let user = await fetchUser(id);
> let scores = user.scores.map(score => score.latest);
> let data = await fetchData(scores);
> 
> What should be an entry point to this async code, if thete is no top-level 
> await?
> Having an async IIFE for the purpose of an entry point seems fits well here. 
> How else would you do this, except an async function declaration, and further 
> its execution?
> 
> function asyncEntryPoint() {
> // await here
> }
> 
> 
> asyncEntryPoint();
> // .then(...); // not needed
> 
> Dmitry
> 
> On Dec 20, 2015 13:57, "Mat At Bread" <<br...@mailed.me.uk>> wrote:
> 
> > I don't dispute you can do it, I just don't see it as necessary, or at 
> > least any more necessary than using an IIFE to collect together synchronous 
> > logic. The creation of the scope is not a factor here.
> > 
> > On 20 December 2015 9:54:59 pm Dmitry Soshnikov 
> > <<dmitry.soshni...@gmail.com>> wrote:
> >
> > > 
> > > 
> > > On Sunday, December 20, 2015, <<br...@mailed.me.uk>> wrote:
> > >
> > > > You're quite right, which demonstrates the lack of necessity for a 
> > > > top-level await (FYI, I find the inconsistency irritating but 
> > > > understandable), so I still maintain this is not a _required_ use for 
> > > > an IIAFE - there is no reason to create an async function to invoke 
> > > > another async function; one can simply invoke it, and if the 
> > > > result/completion is required, use it's ,then() memberbut there's 
> > > > no need/advantage to wrapping such an invocation in an IIAFE, right?
> > > > 
> > > > 
> > > The use case is valid, there was no mistakes. We use async IIFEs as an 
> > > "entry point" to async code: you can await there, do intermediate 
> > > calculations with temporary variables, again awai, etc (Promise.all has a 
> > > different use case).
> > > 
> > > Dmitry 
> > > 
> > > 
> > >
> > > 
> > > > 
> > > > On 20 December 2015 13:40:30 -00:00, Forbes Lindesay <> wrote:
> > > > 
> > > > > Promises are eager. That is, they do the work and resolve whether you 
> > > > > await them or not. If you want to handle exceptions, you need to call 
> > > > > .then and provide an error handler, but other than that it's totally 
> > > > > ok to not bother waiting for a promise.
> > > > > 
> > > > > 
> > > > > On 19 Dec 2015, at 22:02, Mat At Bread <> wrote:
> > > > > 
> > > > > 
> > > > > > Which is what I said, I hope. Use the .then for top-level 
> > > > > > invitation. Dimitry's example wouldn't resolve the Promise
> > > > > > 
> > > > > > On 19 December 2015 9:24:04 pm Fabrício Matté <> wrote:
> > > > > > 
> > > > > > > @bread I see you are referencing Dmitry's sample, but why do you 
> > > > > > > say it won't work? AFAIK async functions return promises, so you 
> > > > > > > don't necessarily need a top-level `await`. I believe this 
> > > > > > > (extremely ugly) sample should work:
> > > > > > > 
> > > > > > > ```js
> > > > > > > function f(cb) {
> > > > > > > 
> > > > > > > (async function() {
> > > > > > > // await here
> > > > > > > })().then(v => cb(null, v), cb);
> > > > > > > }
> > > &

Re: Legitimate uses of IIFEs?

[Mat At Bread]

I don't dispute you can do it, I just don't see it as necessary, or at 
least any more necessary than using an IIFE to collect together synchronous 
logic. The creation of the scope is not a factor here.



On 20 December 2015 9:54:59 pm Dmitry Soshnikov 
<dmitry.soshni...@gmail.com> wrote:



On Sunday, December 20, 2015, <br...@mailed.me.uk> wrote:


You're quite right, which demonstrates the lack of necessity for a
top-level await (FYI, I find the inconsistency irritating but
understandable), so I still maintain this is not a _required_ use for an
IIAFE - there is no reason to create an async function to invoke another
async function; one can simply invoke it, and if the result/completion is
required, use it's ,then() memberbut there's no need/advantage to
wrapping such an invocation in an IIAFE, right?



The use case is valid, there was no mistakes. We use async IIFEs as an
"entry point" to async code: you can await there, do intermediate
calculations with temporary variables, again awai, etc (Promise.all has a
different use case).

Dmitry





On 20 December 2015 13:40:30 -00:00, Forbes Lindesay <
for...@lindesay.co.uk
<javascript:_e(%7B%7D,'cvml','for...@lindesay.co.uk');>> wrote:

Promises are eager.  That is, they do the work and resolve whether you
await them or not.  If you want to handle exceptions, you need to call
.then and provide an error handler, but other than that it's totally ok to
not bother waiting for a promise.

On 19 Dec 2015, at 22:02, Mat At Bread <br...@mailed.me.uk
<javascript:_e(%7B%7D,'cvml','br...@mailed.me.uk');>> wrote:

Which is what I said, I hope. Use the .then for top-level invitation.
Dimitry's example wouldn't resolve the Promise

On 19 December 2015 9:24:04 pm Fabrício Matté <ultco...@gmail.com
<javascript:_e(%7B%7D,'cvml','ultco...@gmail.com');>> wrote:

@bread I see you are referencing Dmitry's sample, but why do you say it
won't work? AFAIK async functions return promises, so you don't necessarily
need a top-level `await`. I believe this (extremely ugly) sample should
work:

```js
function f(cb) {
  (async function() {
// await here
  })().then(v => cb(null, v), cb);
}
```

/fm

On Sat, Dec 19, 2015 at 7:11 PM, <br...@mailed.me.uk
<javascript:_e(%7B%7D,'cvml','br...@mailed.me.uk');>> wrote:

That’s not going to work. The correct form still requires an (illegal)
top-level await:

await (async function() {
// await here
})();

The easiest way to spawn a top-level async function is:

here.then(function(result){},function(error){}) ;

On 19 December 2015 20:14:44 -00:00, Dmitry Soshnikov <
dmitry.soshni...@gmail.com
<javascript:_e(%7B%7D,'cvml','dmitry.soshni...@gmail.com');>> wrote:



On Saturday, December 19, 2015, Šime Vidas <sime.vi...@gmail.com
<javascript:_e(%7B%7D,'cvml','sime.vi...@gmail.com');>> wrote:

With block statements + let/const, IIFEs are no longer needed to emulate
block-scoped variables. That got me thinking, are there other uses of
IIFEs, or are they no longer needed?
I’ve checked my code and found instances of this pattern:

var foo = (function () {
var a, b, c; // helper variables
// some computation
return /* final value of foo */;
}());
Btw, there is a "do expression" proposal (stage 0) [1] for this type of
pattern.
Anything else?


FWIW, one of the still valid use cases is async IIFE, to spawn an async
code (since there's no yet top-level async/await)

(async function() {
  // await here
})();

Dmitry



___
es-discuss mailing list
es-discuss@mozilla.org
<javascript:_e(%7B%7D,'cvml','es-discuss@mozilla.org');>
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
<javascript:_e(%7B%7D,'cvml','es-discuss@mozilla.org');>
https://mail.mozilla.org/listinfo/es-discuss



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[bread]

You're quite right, which demonstrates the lack of necessity for a top-level 
await (FYI, I find the inconsistency irritating but understandable), so I still 
maintain this is not a _required_ use for an IIAFE - there is no reason to 
create an async function to invoke another async function; one can simply 
invoke it, and if the result/completion is required, use it's ,then() 
memberbut there's no need/advantage to wrapping such an invocation in an 
IIAFE, right?


On 20 December 2015 13:40:30 -00:00, Forbes Lindesay <for...@lindesay.co.uk> 
wrote:

> Promises are eager. That is, they do the work and resolve whether you await 
> them or not. If you want to handle exceptions, you need to call .then and 
> provide an error handler, but other than that it's totally ok to not bother 
> waiting for a promise.
> 
> 
> On 19 Dec 2015, at 22:02, Mat At Bread <<br...@mailed.me.uk>> wrote:
> 
> 
> > Which is what I said, I hope. Use the .then for top-level invitation. 
> > Dimitry's example wouldn't resolve the Promise
> > 
> > On 19 December 2015 9:24:04 pm Fabrício Matté <<ultco...@gmail.com>> wrote:
> > 
> > > @bread I see you are referencing Dmitry's sample, but why do you say it 
> > > won't work? AFAIK async functions return promises, so you don't 
> > > necessarily need a top-level `await`. I believe this (extremely ugly) 
> > > sample should work:
> > > 
> > > ```js
> > > function f(cb) {
> > > 
> > > (async function() {
> > > // await here
> > > })().then(v => cb(null, v), cb);
> > > }
> > > ```
> > > 
> > > /fm
> > > 
> > > 
> > > 
> > > On Sat, Dec 19, 2015 at 7:11 PM, <<br...@mailed.me.uk>> wrote:
> > > 
> > > 
> > > 
> > > > That’s not going to work. The correct form still requires an (illegal) 
> > > > top-level await:
> > > > 
> > > > await (async function() {
> > > > // await here
> > > > })();
> > > > 
> > > > The easiest way to spawn a top-level async function is:
> > > > 
> > > > here.then(function(result){},function(error){}) ;
> > > > 
> > > > 
> > > > On 19 December 2015 20:14:44 -00:00, Dmitry Soshnikov 
> > > > <<dmitry.soshni...@gmail.com>> wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > On Saturday, December 19, 2015, Šime Vidas <<sime.vi...@gmail.com>> 
> > > > > wrote:
> > > > > 
> > > > > > With block statements + let/const, IIFEs are no longer needed to 
> > > > > > emulate block-scoped variables. That got me thinking, are there 
> > > > > > other uses of IIFEs, or are they no longer needed?
> > > > > > I’ve checked my code and found instances of this pattern:
> > > > > > 
> > > > > > var foo = (function () {
> > > > > > var a, b, c; // helper variables
> > > > > > // some computation
> > > > > > return /* final value of foo */;
> > > > > > 
> > > > > > }());
> > > > > > 
> > > > > > Btw, there is a "do expression" proposal (stage 0) [1] for this 
> > > > > > type of pattern.
> > > > > > Anything else?
> > > > > > 
> > > > > FWIW, one of the still valid use cases is async IIFE, to spawn an 
> > > > > async code (since there's no yet top-level async/await)
> > > > > 
> > > > > (async function() {
> > > > > // await here
> > > > > })();
> > > > > 
> > > > > Dmitry 
> > > > > 
> > > > 
> > > > ___
> > > > es-discuss mailing list
> > > > <es-discuss@mozilla.org>
> > > > 
> > > > <https://mail.mozilla.org/listinfo/es-discuss>
> > > > 
> > > > 
> > > > 
> > ___
> > es-discuss mailing list
> > 
> > <es-discuss@mozilla.org>
> > 
> > <https://mail.mozilla.org/listinfo/es-discuss>
> >

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[Mat At Bread]

Which is what I said, I hope. Use the .then for top-level invitation. 
Dimitry's example wouldn't resolve the Promise



On 19 December 2015 9:24:04 pm Fabrício Matté <ultco...@gmail.com> wrote:


@bread I see you are referencing Dmitry's sample, but why do you say it
won't work? AFAIK async functions return promises, so you don't necessarily
need a top-level `await`. I believe this (extremely ugly) sample should
work:

```js
function f(cb) {
  (async function() {
// await here
  })().then(v => cb(null, v), cb);
}
```

/fm

On Sat, Dec 19, 2015 at 7:11 PM, <br...@mailed.me.uk> wrote:


That’s not going to work. The correct form still requires an (illegal)
top-level await:

await (async function() {
// await here
})();

The easiest way to spawn a top-level async function is:

here.then(function(result){},function(error){}) ;

On 19 December 2015 20:14:44 -00:00, Dmitry Soshnikov <
dmitry.soshni...@gmail.com> wrote:



On Saturday, December 19, 2015, Šime Vidas <sime.vi...@gmail.com> wrote:

With block statements + let/const, IIFEs are no longer needed to emulate
block-scoped variables. That got me thinking, are there other uses of
IIFEs, or are they no longer needed?
I’ve checked my code and found instances of this pattern:

var foo = (function () {
var a, b, c; // helper variables
// some computation
return /* final value of foo */;
}());
Btw, there is a "do expression" proposal (stage 0) [1] for this type of
pattern.
Anything else?


FWIW, one of the still valid use cases is async IIFE, to spawn an async
code (since there's no yet top-level async/await)

(async function() {
  // await here
})();

Dmitry



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[bread]

That’s not going to work. The correct form still requires an (illegal) 
top-level await:

await (async function() {
// await here
})();

The easiest way to spawn a top-level async function is:

here.then(function(result){},function(error){}) ;

On 19 December 2015 20:14:44 -00:00, Dmitry Soshnikov 
 wrote:

> 
> 
> On Saturday, December 19, 2015, Šime Vidas <> wrote:
> 
> > With block statements + let/const, IIFEs are no longer needed to emulate 
> > block-scoped variables. That got me thinking, are there other uses of 
> > IIFEs, or are they no longer needed?
> > I’ve checked my code and found instances of this pattern:
> > 
> > var foo = (function () {
> > var a, b, c; // helper variables
> > // some computation
> > return /* final value of foo */;
> > 
> > }());
> > 
> > Btw, there is a "do expression" proposal (stage 0) [1] for this type of 
> > pattern.
> > Anything else?
> > 
> FWIW, one of the still valid use cases is async IIFE, to spawn an async code 
> (since there's no yet top-level async/await)
> 
> (async function() {
> // await here
> })();
> 
> Dmitry 
>

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Legitimate uses of IIFEs?

[bread]

I believe await* has gone from the spec. The correct form would be (at the 
top-level):

```js


Promise.all(asyncFn1(...), asyncFn2(...),...).then(...)
```


The mistake in Dimitry's example is that the async body was not resolved, not 
that anonymous async functions are in some way invalid - they're just fine.
On 19 December 2015 20:47:57 -00:00, Fabrício Matté  wrote:

> Good call, Dmitry. Async IIFEs are also useful to parallelize different 
> sequences of async operations. E.g.:
> 
> ```js
> async function main() {
> await* [
> (async () => await seq1op2(await seq1op1()))(),
> (async () => {
> await seq2op1();
> await seq2op2();
> })(),
> ];
> }
> ```
> 
> Here is a more solid example 
> .
>
> /fm
>

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss