On 06/03/2025 07:49, Edmond Dantes wrote:
> Defining new syntax would encourage us to define a minimum top-level > behaviour, such as "inside an async{} block, these things are possible, > and these things are guaranteed to be true"True. This is precisely the main reason not to change the syntax. The issue is not even about how many changes need to be made in the code, but rather about how many agreements need to be considered.
Quite the opposite: with a function-and-object approach everything needs a name, an API, and a way of being described in relation to how the language already works. In a syntax-and-semantics approach, we only need to describe the things people actually need.
The generator implementation doesn't have a name or API for where the value on the right of a "yield" goes, or where the value on its left comes from; we just describe the behaviour: values passed to yield somehow end up in the calling scope's Generator object, and values passed to that object somehow end up back at the yield statement. We don't have to define the API for a GeneratorContext object, and the semantics of what happens when users pass it around and store it in different scopes.
In the same way, do we actually need to design what an "async context" looks like to the user? Do we actually want the user to be able to have access to two (nested) async contexts at once, and choose which one to spawn a task into? Or would we prefer, at least in the minimum implementation, to say "when you spawn a task, it spawns in the current async context, and if there is no current async context, an error is thrown"?
-- Rowan Tommins [IMSoP]
