Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126598
Feedback-ID: id5114917:Fastmail
Message-ID: <36cee7e3-2ef8-4f96-a72e-e67a99e5f9bb@rwec.co.uk>
Date: Thu, 6 Mar 2025 09:17:28 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] PHP True Async RFC
To: internals@lists.php.net
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <9964db8c-0ffe-43d5-8246-47fc76b07180@app.fastmail.com>
 <CAMW7n8CM7oBfXCDsKtV4hTFs40UmLCU3183WjYE2exLNqKDWLQ@mail.gmail.com>
 <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com>
 <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
 <23e162f6-54b0-4564-9d79-7b3bdc3d1ab5@rwec.co.uk>
 <CAMW7n8A_KM6W0NHk_Ypd2PGdJZbi0quxwGvM27pf-U-YOe-RGw@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAMW7n8A_KM6W0NHk_Ypd2PGdJZbi0quxwGvM27pf-U-YOe-RGw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

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]