Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126858
Feedback-ID: id5114917:Fastmail
Date: Thu, 20 Mar 2025 08:11:37 +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: <CAMW7n8DUZyoEMfYCV=P61hvN12DetYFee3E4S8O1gFfYu05okA@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> <6987D912-CE46-4145-A8CE-732CA590A522@rwec.co.uk> <CAMW7n8BJcTuTQj_AB4ha-RUF_AY5oKp1y0TaN-+CZOSLpmEoZw@mail.gmail.com> <2F013672-9937-4AB1-BC46-86F3D342BE6B@rwec.co.uk> <CAMW7n8CmaAFmUVgeJ+Xcxo52yS7O3KjU_LfRx8E6-KZqDxGVEg@mail.gmail.com> <743c84d4-28db-4f68-80e5-3cad2dac6e68@rwec.co.uk> <CAMW7n8DUZyoEMfYCV=P61hvN12DetYFee3E4S8O1gFfYu05okA@mail.gmail.com>
Message-ID: <C8ACD74F-D046-4C08-B68D-65C078F2565E@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 20 March 2025 07:06:16 GMT, Edmond Dantes <edmond=2Eht@gmail=2Ecom> wro=
te:


I forgot to include some relevant text to quote, but I absolutely agree th=
at syntax #2 should be our default=2E=20

I think the only thing I'm still unsure of is whether we need anything els=
e on top of it, and if so what=2E


>
>>  4: keyword inline_function
>>
>This option can be considered a special case of option #2=2E And that=E2=
=80=99s
>exactly the case=2E


In terms of the grammar, it is a special case of #1, because the inline_fu=
nction is evaluated in full as an expression, and then we *fabricate* a zer=
o-argument function call to the resulting value=2E

Or to use your breakdown, #2 includes both elements we need: the callable,=
 and the parameter list; #1, #3 and #4 all include just one element, the ca=
llable, and make the assumption that the argument list is empty=2E=20



>>  This is less confusing, but has one surprising effect: if you refactor
>>the inline function to be a variable, you have to replace it with "$foo(=
)"
>>not just "$foo", so that you hit rule #2
>
>A completely logical transformation that does not contradict anything=2E


This example maybe helps explain why this might be surprising:

```
function foo() {
    yield  function() { whatever(); };
    spawn  function() { whatever(); };
    return function() { whatever(); };
}
```

Three identical values, so let's replace with a shared variable:

```
function foo() {
    $action =3D function() { whatever(); }
    yield $action;
    spawn $action;
    return $action;=20
}
```

Looks right, but isn't - we needed to write "spawn $action()"=2E Not a hug=
e rule to learn, but a fairly arbitrary one from the point of view of the u=
ser=2E



>The meaning of option #4 is different:
>
>   1=2E I want to define a closure at point A=2E
>   2=2E I want to use it at point A=2E
>   3=2E Point A knows what the closure looks like, so there is no need to
>   define arguments =E2=80=94 it's the same place in the code=2E



This feels like a stretch to me: it's not that anything knows what argumen=
ts to pass, it's just that the syntax is restricted to passing no arguments=
=2E (You could presumably define a closure that *expects* arguments, but co=
uldn't actually pass any, within the shorthand syntax=2E)



>Therefore, the `keyword closure` does not break the clarity of the
>description, whereas the `keyword $something` does=2E


From=20the user's point of view, it might be just as obvious that the closur=
e put into a variable two lines above can also be called with zero argument=
s=2E It's only as unclear as any other code involving a variable - if it's =
badly named and defined 100 lines away, you'll have a problem, but no synta=
x can solve that=2E



>>  6: keyword_bar function_call
>>
>This contains even more characters than the original and yet adds nothing
>useful=2E


I tried to make clear that the keywords could stand in for anything=2E The=
re's no reason that "two different keywords" has to mean "more characters"=
=2E It could be "go foo();" and "run $closure;", and the point I was trying=
 to illustrate would still hold=2E



>>  But I do want to come back to the question I asked in my last e-mail:
>what is the use case we're trying to cater for?
>>
>Goal #1: Improve code readability=2E Make it easier to understand=2E
>Goal #2: Reduce the number of characters=2E


That's answering a different question, I want to know *what code* we are o=
ptimizing the readability of=2E What is the user trying to do, which we wan=
t to make readable and shorter?

Specifically, what is the use case where syntax #2, "spawn function_call" =
is not good enough, leading us to add a special case into the grammar=2E


>The advantage of option #4 is not just that it removes parentheses, but
>also that it keeps the code readable=2E


One is a consequence of the other=2E I don't disagree, but I personally fi=
nd that introducing a temporary variable has much the same effect, without =
any special case grammar=2E



>The second reason why option #4 makes sense: it will be used frequently=
=2E


Will it? By who, when? Honest question, and comes back to my point about i=
dentifying the use case=2E


>For example, `spawn fn() =3D> file_get_content()` won=E2=80=99t be, becau=
se it
>doesn=E2=80=99t make sense=2E


If return values end up somewhere, I  don't think it would be hard to come=
 up with examples that were slightly more than one function call, but still=
 fit in a single-expression closure=2E


Rowan Tommins
[IMSoP]