Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126846
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <6987D912-CE46-4145-A8CE-732CA590A522@rwec.co.uk>
Date: Wed, 19 Mar 2025 17:51:38 +0200
Message-ID: <CAMW7n8BJcTuTQj_AB4ha-RUF_AY5oKp1y0TaN-+CZOSLpmEoZw@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000dbace60630b3ff6c"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000dbace60630b3ff6c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
>  "Cheating" in the sense that you wrote out a "general syntax",
>
I got it.

> That's not the problem; the problem is that the following are all
equivalent expressions:
>  (((foo())))

In principle, this is not a problem because the expression in parentheses
preceded by `spawn` is unambiguously a call expression.
That is, from an analysis perspective, everything is fine here because the
expression `spawn ()` is a syntax error.

On the other hand, the expression `spawn (())` is also an error, but a
semantic one, because there is nothing to call.

The expression spawn ((), (), ()) is also an error because it attempts to
specify a list of parameters without a call expression.

It seems I didn't make any mistakes anywhere?

>
> 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
context.
>

From the user's perspective, what is the difference between these two
expressions?

```php
spawn function(): string { ... };
spawn (function(): string { ... });
```

>
>  All of these are examples of the keyword being followed by *a function
call*, not *any expression*. Which honestly I think is the right way to go.
>

I created these examples according to the syntax rules from the Bison file
for `function_call`.
Of course, I might have missed something, but overall, the list above
essentially represents what `function_call` should expand into.

If we define the rule `spawn function_call`, then `spawn` acts as a prefix
in this expression. However, everything that is already defined for
`function_call` in PHP must remain valid.

If we take the most complex part:
```bison
|   callable_expr { $<num>$ =3D CG(zend_lineno); } argument_list {
        $$ =3D zend_ast_create(ZEND_AST_CALL, $1, $3);
        $$->lineno =3D $<num>2;
    }

callable_expr:
    callable_variable       { $$ =3D $1; }
  | '(' expr ')'           { $$ =3D $2; }
  | dereferenceable_scalar { $$ =3D $1; }
  | new_dereferenceable    { $$ =3D $1; }
;
```

we can see that the expression (((some()))) corresponds to the second line,
and arguments must follow.
However, in this case, arguments become *mandatory*. This means that after
(((some()))), there must also be ().

And another good thing about this syntax: a coroutine is an execution
context, and a function call is a transition to a block of code.
This means that the expression `spawn function_call` can be understood
literally as:

* Create a new execution context
* Execute `function_call`

The syntax for `function_call` is already defined in PHP, and nothing
changes in it.

The second form of the `spawn` expression is:
```php
spawn inline_function
```

where inline_function is a definition from bison:

```bison
inline_function:
function returns_ref backup_doc_comment '(' parameter_list ')' lexical_vars
return_type
...;
```

Another advantage of this solution is that if `function_call` constructs
change in the future, we won=E2=80=99t need to modify the definitions for `=
spawn`.

>
>  If it's going to be a special case for an "inline coroutine", just use a
keyword other than "function", so it doesn't look like an expression when
it's not, like "spawn block { ... }"; or no keyword at all, just "spawn {
... }"
>

Well, yes, but here we again face the issue with `returnType` syntax, which
ends up hanging in the air...

--000000000000dbace60630b3ff6c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;<br>&gt;=C2=A0

&quot;Cheating&quot; in the sense that you wrote out a &quot;general syntax=
&quot;,<br>&gt;<br>I got it.<div><br></div><div>&gt; That&#39;s not the pro=
blem; the problem is that the following are all equivalent expressions:<br>=
&gt;=C2=A0

(((foo())))<br><br>In principle, this is not a problem because the expressi=
on in parentheses preceded by `spawn` is unambiguously a call expression.=
=C2=A0</div><div>That is, from an analysis perspective, everything is fine =
here because the expression `spawn ()` is a syntax error. <br><br>On the ot=
her hand, the expression `spawn (())` is also an error, but a semantic one,=
 because there is nothing to call.</div><div><br></div><div>The expression =
<code>spawn ((), (), ())</code> is also an error because it attempts to spe=
cify a list of parameters without a call expression.=C2=A0=C2=A0</div><div>=
<br></div><div>It seems I didn&#39;t make any mistakes anywhere?=C2=A0=C2=
=A0<br></div><div><br></div><div>&gt;<br>&gt; But from a user&#39;s point o=
f view, I hate rules like that which mean subtle changes completely change =
the meaning of the code, in a very specific context.=C2=A0</div><div>&gt;</=
div><div><br>From the user&#39;s perspective, what is the difference betwee=
n these two expressions? =C2=A0</div><div><br>```php<br>spawn function(): s=
tring { ... };<br>spawn (function(): string { ... });<br></div><div>```</di=
v><div><br></div><div>&gt;<br>&gt;=C2=A0

All of these are examples of the keyword being followed by *a function call=
*, not *any expression*. Which honestly I think is the right way to go.<br>=
&gt;</div><div><br></div><div>I created these examples according to the syn=
tax rules from the Bison file for `function_call`.=C2=A0</div><div>Of cours=
e, I might have missed something, but overall, the list above essentially r=
epresents what `function_call` should expand into. =C2=A0<br><br>If we defi=
ne the rule `spawn function_call`, then `spawn` acts as a prefix in this ex=
pression. However, everything that is already defined for `function_call` i=
n PHP must remain valid. =C2=A0<br><br>If we take the most complex part: =
=C2=A0<br>```bison<br>| =C2=A0 callable_expr { $&lt;num&gt;$ =3D CG(zend_li=
neno); } argument_list {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 $$ =3D zend_ast_cre=
ate(ZEND_AST_CALL, $1, $3);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 $$-&gt;lineno =
=3D $&lt;num&gt;2;<br>=C2=A0 =C2=A0 }<br></div><div><br></div><div>callable=
_expr:<br>=C2=A0 =C2=A0 callable_variable =C2=A0 =C2=A0 =C2=A0 { $$ =3D $1;=
 }<br>=C2=A0 | &#39;(&#39; expr &#39;)&#39; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 { $$ =3D $2; }<br>=C2=A0 | dereferenceable_scalar { $$ =3D $1; }<br>=C2=
=A0 | new_dereferenceable =C2=A0 =C2=A0{ $$ =3D $1; }<br>;<br></div><div>``=
`</div><div><br></div><div>we can see that the expression <code>(((some()))=
)</code> corresponds to the second line, and arguments must follow.=C2=A0</=
div><div>However, in this case, arguments become <strong>mandatory</strong>=
. This means that after <code>(((some())))</code>, there must also be <code=
>()</code>.=C2=A0=C2=A0</div><div><br></div><div>And another good thing abo=
ut this syntax: a coroutine is an execution context, and a function call is=
 a transition to a block of code.=C2=A0</div><div>This means that the expre=
ssion `spawn function_call` can be understood literally as: =C2=A0<br><br>*=
 Create a new execution context =C2=A0<br>* Execute `function_call` =C2=A0<=
br><br>The syntax for `function_call` is already defined in PHP, and nothin=
g changes in it.=C2=A0=C2=A0<br></div><div><br></div><div>The second form o=
f the `spawn` expression is: =C2=A0<br>```php<br>spawn inline_function<br><=
/div><div>```</div><div><br></div><div>where inline_function is a definitio=
n from bison:</div><div><br></div><div>```bison</div><div>inline_function:<=
/div><div>		function returns_ref backup_doc_comment &#39;(&#39; parameter_l=
ist &#39;)&#39; lexical_vars return_type<br>...;<br></div><div>```</div><di=
v><br></div><div>Another advantage of this solution is that if `function_ca=
ll` constructs change in the future, we won=E2=80=99t need to modify the de=
finitions for `spawn`.=C2=A0=C2=A0<br></div><div><br></div><div>&gt;<br>&gt=
;=C2=A0

If it&#39;s going to be a special case for an &quot;inline coroutine&quot;,=
 just use a keyword other than &quot;function&quot;, so it doesn&#39;t look=
 like an expression when it&#39;s not, like &quot;spawn block { ... }&quot;=
; or no keyword at all, just &quot;spawn { ... }&quot;<br>&gt;</div><div><b=
r></div><div>Well, yes, but here we again face the issue with `returnType` =
syntax, which ends up hanging in the air...=C2=A0=C2=A0<br></div></div>

--000000000000dbace60630b3ff6c--