Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126841
Feedback-ID: id5114917:Fastmail
Date: Wed, 19 Mar 2025 13:43:56 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2
User-Agent: K-9 Mail for Android
In-Reply-To: <CAMW7n8DYBf73h2maPPcrPAGfEgdEdjeDoYrrD17fmxp9v_gx+g@mail.gmail.com>
References: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com> <72bd5401-53a9-409f-ad45-687333401961@rwec.co.uk> <CAMW7n8De15X4xDNOBULKeKkpeCeNo-tDWVWZ+Zer8vMa3U-vQg@mail.gmail.com> <d50b892b-9372-45c0-81ad-1ce818385b75@rwec.co.uk> <CAMW7n8C16d14earerxvCPe_kyym09GOa8mh4qwPz8AKVKQjHsw@mail.gmail.com> <e05cee9d-7901-4b18-b71c-24ad56266534@rwec.co.uk> <CAMW7n8AtLZOof54uJNFG+P4VVwbq65i79x-JDFKPJocDj-w91Q@mail.gmail.com> <DBDD7E90-DE94-4A9D-91F2-5CA9E712AE33@rwec.co.uk> <CAMW7n8DYBf73h2maPPcrPAGfEgdEdjeDoYrrD17fmxp9v_gx+g@mail.gmail.com>
Message-ID: <6987D912-CE46-4145-A8CE-732CA590A522@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 19 March 2025 11:27:11 GMT, Edmond Dantes <edmond=2Eht@gmail=2Ecom> wro=
te:
>>
>> You're cheating again - you've put an extra pair of brackets around one
>> expression and not the other, and assumed they'll work differently, but
>that's
>> not the grammar you proposed=2E
>>
>
>Why am I cheating?

"Cheating" in the sense that you wrote out a "general syntax", and then dr=
opped in examples that contradicted that syntax=2E Saying "it follows this =
grammar, except when it doesn't" isn't very enlightening=2E



>> spawn (getClosure());
>This is an honest statement, provided that the second parentheses are
>optional=2E The full notation would be:
>> spawn (getClosure())();

That's not the problem; the problem is that the following are all equivale=
nt expressions:

foo()
(foo())
((foo()))
(((foo())))

But you want these to mean different things:=20

spawn foo();
spawn (foo());

I think that would be achievable with a new grammar rule for "expression o=
ther than function call", so you could have:=20

spawn_statement:
    'spawn' function_call { compile_function_spawn }
    | 'spawn' expression_not_function_call { compile_closure_spawn }

But from a user's point of view, I hate rules like that which mean subtle =
changes completely change the meaning of the code, in a very specific conte=
xt=2E


>The reverse meaning is that if `spawn` is not followed by the `function`
>keyword, then it must be a valid expression that can be enclosed in
>parentheses=2E
>
>There are some doubts about whether all situations are correct, but so fa=
r,
>this is how it works for me:


All of these are examples of the keyword being followed by *a function cal=
l*, not *any expression*=2E Which honestly I think is the right way to go=
=2E

The "expression" part came into the conversation because I think it's weir=
d to force the user to write "function() { =2E=2E=2E }" as though it's a Cl=
osure declaration, but not let them perform obvious refactoring like moving=
 that declaration into a variable=2E=20

If it's going to be a special case for an "inline coroutine", just use a k=
eyword other than "function", so it doesn't look like an expression when it=
's not, like "spawn block { =2E=2E=2E }"; or no keyword at all, just "spawn=
 { =2E=2E=2E }"


Rowan Tommins
[IMSoP]