Re: Enable async/await to work on functions that don't just return promises.

[Florian Bösch]

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> 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> wrote:
>
>> On Sat, Feb 25, 2017 at 11:55 PM, Codefined <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
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>

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