Hey Florian,

Why do we even need to do that?
async function someAsync() { something(() => { return "hello"; }); } let d = 
function() { return await someAsync(); } let c = function() { return d(); }
Because `d()` is no longer an asynchronous function, you can call it like 
normal, surely?


On 26/02/2017 12:44:01, Florian Bösch <pya...@gmail.com> wrote:
It would be nice if there even was an argument, but there isn't. There isn't 
because async/await naturally devolves into implicit coroutines, so any 
argument would be moot.

To illustrate, suppose you have these 4 functions:

let a = function(){
  return b();
}

let b = function(){
  return c();
}

let c = function(){
   return d();
}

let d = function(){
  return whatever();
}

Call chains like this are typical. It's the staple of software engineering (for 
reasons of proper separation of concerns, reuse of utility code, etc.). If you 
believe that there is an argument about this being exemplary, it would be 
impossible to have an argument with you about software engineering at all. Of 
course real-world examples are more complex and don't just return whatever the 
underlying function produced, but as a control flow example it suffices. These 
chains are often much deeper than 4 levels, it's not uncommon to encounter call 
chains 10, 15, 20 or 30 layers deep.

Now let's suppose you figure that function d wants to do something asynchronous.

So you go and do:

let d = function(){
  return xhr();
}

But of course that doesn't work, because d is not async. So you go and do:

let d = async function(){
  return await xhr();
}

Of course that doesn't work because c is not async, and so forth, so eventually 
your code looks like that.

let a = async function(){
  return await b();
}

let b = async function(){
  return await c();
}

let c = async function(){
   return await d();
}

let d = async function(){
  return await xhr();
}

In essence, you've applied to following two regular expression: 
s/function/await function/g and s/.+?\(\)/await ()/ . Of course that'd be 
horrid to do, so in reality you'd please use a proper JS parser. How did your 
code look before you applied these regular expressions? Well, it looks exactly 
like at the start.

let a = function(){
  return b();
}

let b = function(){
  return c();
}

let c = function(){
   return d();
}

let d = function(){
  return xhr();
}

But it isn't like at the start, because now it can trigger race conditions and 
is asynchronous. It is in fact now idempotent with true co-routines, except 
some unnecessary code transmoglification.

This conclusively proves that await/async is an inconvenient clutch that 
naturally devolves into true co-routines. Now you might try to argue, that 
real-world code isn't just going to prefix every function call with await and 
every function body with async and stay that way.

However, this would be in invalid argument for actual real-world code, because. 
People don't just constantly switch back and forth and re-engineer their code 
just because they want something async to happen underneath. You don't go and 
bicycle repair every call and function definition if you should decide to 
toggle synchronous or asynchronous. Therefore, since prefixing everything works 
no matter if it is asynchronous or synchronous, you will stay with the prefixes 
once you've added them. Which not only guarantees that async/await devolves 
into true co-routines, but it also gurantees that they proliferate everything 
and once they're in, they're never going out.

And that's why it isn't an argument.

On Sun, Feb 26, 2017 at 12:05 PM, Alexander Jones <a...@weej.com 
[mailto:a...@weej.com]> wrote:

Florian, you shouldn't pass the argument of explicit vs implicit coroutines off 
as being so simple. There are many compelling arguments for both! Please Google 
them!


On Sun, 26 Feb 2017 at 00:01, Florian Bösch <pya...@gmail.com 
[mailto:pya...@gmail.com]> wrote:

On Sat, Feb 25, 2017 at 11:55 PM, Codefined <codefi...@debenclipper.com 
[mailto:codefi...@debenclipper.com]> wrote:

This seems to be so very confusing for anybody new studying this language, 
almost everyone I talk to gets stuck up on some part of it.
Promises are bad, and mixing them with async/await is worse. Should never have 
been added to any kind of standard.
async function asyncFunction() { let [err, data] = await asyncFunction() }
function asyncFunction(){
  return otherAsyncFunction();
}

Even simpler, you'd just need co-routines.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org [mailto:es-discuss@mozilla.org]
https://mail.mozilla.org/listinfo/es-discuss 
[https://mail.mozilla.org/listinfo/es-discuss]

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

Reply via email to