From a language design viewpoint, I wonder whether the current crop of async implementations - eg 'def' -> 'async def', f(x) -> 'await f(x)', 'return 1' -> 'async return 1' are making a mistake analogous to the decades-long opposition to type deduction, ostensibly for "clarity".
Let me phrase this as a question to prevent "social" arguments against a homogenous syntax for coroutine: if coroutines were await-invoked using the same syntax as regular functions were invoked, would that create some unresolvable ambiguity for an important use-case (and similarly for the other syntactic forms)?
My gut feeling is that the answer is no. Consider what a C++ compiler does with an awaitable function (this may be specific to stackless coroutines): they are transformed into state machines, each state lowers into something akin to a regular function, local variables accessed across states are stored in a dynamic environment. Ok, but then isn't a regular function simply a coroutine whose lowered state machine has a single state? And that being so, why distinguish syntactically between the two?
It seems silly, to my mind, to do all this "work" (in the compiler) to create an abstraction which allows the programmer to forget whether 'f(x)' returns synchronously or asynchronously, only to introduce a syntax which requires them to know or look up which of the two it is. What does it matter which of the two it is, if the whole point of the exercise was to turn callback spaghetti into linear code (and allow to leverage automatic variable lifetimes aka RAII)?
seertaak•1h ago
From a language design viewpoint, I wonder whether the current crop of async implementations - eg 'def' -> 'async def', f(x) -> 'await f(x)', 'return 1' -> 'async return 1' are making a mistake analogous to the decades-long opposition to type deduction, ostensibly for "clarity".
Let me phrase this as a question to prevent "social" arguments against a homogenous syntax for coroutine: if coroutines were await-invoked using the same syntax as regular functions were invoked, would that create some unresolvable ambiguity for an important use-case (and similarly for the other syntactic forms)?
My gut feeling is that the answer is no. Consider what a C++ compiler does with an awaitable function (this may be specific to stackless coroutines): they are transformed into state machines, each state lowers into something akin to a regular function, local variables accessed across states are stored in a dynamic environment. Ok, but then isn't a regular function simply a coroutine whose lowered state machine has a single state? And that being so, why distinguish syntactically between the two?
It seems silly, to my mind, to do all this "work" (in the compiler) to create an abstraction which allows the programmer to forget whether 'f(x)' returns synchronously or asynchronously, only to introduce a syntax which requires them to know or look up which of the two it is. What does it matter which of the two it is, if the whole point of the exercise was to turn callback spaghetti into linear code (and allow to leverage automatic variable lifetimes aka RAII)?