Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126851
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------GKTKy7SPNIbyln0yeVqm1rkx"
Message-ID: <743c84d4-28db-4f68-80e5-3cad2dac6e68@rwec.co.uk>
Date: Wed, 19 Mar 2025 23:04:49 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2
To: internals@lists.php.net
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>
Content-Language: en-GB
In-Reply-To: <CAMW7n8CmaAFmUVgeJ+Xcxo52yS7O3KjU_LfRx8E6-KZqDxGVEg@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------GKTKy7SPNIbyln0yeVqm1rkx
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 19/03/2025 19:24, Edmond Dantes wrote:
> > Yes, that would probably be a bad choice as well. Which is why I've 
> repeatedly suggested a different keyword, and AFAIK you still haven't 
> actually voiced an opinion on that.
>
>
> Does this concern the syntax of `spawn block {}` or did I miss something?


We're talking around in circles a lot here, I think, let's try to reset 
and list out a load of different options, as abstractly as possible.

I'm going to use the word "keyword" in place of "spawn", just to 
separate *syntax* from *naming*; and where possible, I'm going to use 
the names from the current grammar, not any other placeholders.


1: keyword expr
2: keyword function_call
3: keyword expr_except_function_call
4: keyword inline_function
5: keyword_foo expr
6: keyword_bar function_call
7: keyword '{' inner_statement_list '}'


#1 is the most flexible: you have some way of specifying a callable 
value, which you pass to the engine, maybe with some arguments (concrete 
example: "spawn $my_closure;")

#2 is the most concise for the common case of using an existing 
function, because you don't need to make a callable / closure pointing 
to the function first (concrete example: "spawn my_function('my 
argument');")

BUT these two rules conflict: any function_call is also an expr, so we 
can't say "if it's an expr, do this; if it's a function_call, do that", 
because both are true at once.


The next four are compromises to work around that conflict:

#3 is a version of #1 which doesn't conflict with #2 - introduce a new 
grammar rule which has all the things in expr, but not function_call. 
This is technically fine, but maybe confusing to the user, because 
"spawn $foo == spawn $foo()", but "spawn foo() != spawn foo()()", and 
"spawn $obj->foo != $obj->foo()".

#4 is really the same principle, but restricted even further - the only 
expression allowed is the declaration of an inline function. 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

#5 and #6 are the "different keywords" options: they don't conflict with 
each other, and #1 could be used with #6, or #2 with #5. In concrete 
terms, you can have "spawn_func_call $foo() == spawn_closure $foo", or 
"spawn $foo() == spawn_closure $foo", or "spawn_func_call $foo() == 
spawn $foo".


#7 is the odd one out: it hides the closure from the user completely. It 
could be combined with any of the others, but most likely with #2



> In PHP, code blocks are not all the same.
> - `if` / `then` / `else` / `try` / `switch` **do not create a new 
> scope**.
> - `function` **does create a new scope**.
>
> When a programmer writes:
> ```php
> $x = 5;
> spawn {$x++};
> ```
> Will they easily understand that |$x++| is not modifying the same |$x| 
> as before?
> No, they won’t. They will have to remember that |spawn {}| creates a 
> closure, just like |function| creates a closure with a separate scope.


OK, thanks; I think this is the point that I was missing - I was 
thinking that the engine creating a closure was just an implementation 
detail, which could be made invisible to the user. But you're right, the 
way variable scope works would be completely unlike anything else in the 
language. That probably rules out #7

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?

If the aim is "a concise way to wrap a few statements", we've already 
failed if the user's writing out "function" and a "use" clause.

If the aim is "a readable way to use a closure", rule #2 is fine.

Yes, it means some extra parentheses if you squeeze it all into one 
statement, but it's probably more readable to assign the closure to a 
temporary variable anyway:

// Legal under rule #2, but ugly
spawn (function() use($whatever) {
     do_something($whatever);
})();

// Requires rule #4, saves a few brackets
spawn function() use($whatever) {
     do_something($whatever);
};

// Only needs rule #2, and perfectly readable
$foo = function() use($whatever) {
     do_something($whatever);
}
spawn $foo();


-- 
Rowan Tommins
[IMSoP]

--------------GKTKy7SPNIbyln0yeVqm1rkx
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 19/03/2025 19:24, Edmond Dantes
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMW7n8CmaAFmUVgeJ+Xcxo52yS7O3KjU_LfRx8E6-KZqDxGVEg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>&gt; 
          Yes, that would probably be a bad choice as well. Which is why
          I've repeatedly suggested a different keyword, and AFAIK you
          still haven't actually voiced an opinion on that.<span
            class="gmail-im" style="color:rgb(80,0,80)"><br>
          </span><br>
        </div>
        <div><br>
        </div>
        <div>Does this concern the syntax of `spawn block {}` or did I
          miss something?  <br>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>We're talking around in circles a lot here, I think, let's try to
      reset and list out a load of different options, as abstractly as
      possible.<br>
    </p>
    <p>I'm going to use the word "keyword" in place of "spawn", just to
      separate *syntax* from *naming*; and where possible, I'm going to
      use the names from the current grammar, not any other
      placeholders.<br>
    </p>
    <p><br>
    </p>
    <p>1: keyword expr<br>
      2: keyword function_call<br>
      3: keyword expr_except_function_call<br>
      4: keyword inline_function<br>
      5: keyword_foo expr<br>
      6: keyword_bar function_call<br>
      7: keyword '{' inner_statement_list '}'<br>
    </p>
    <p><br>
    </p>
    <p>#1 is the most flexible: you have some way of specifying a
      callable value, which you pass to the engine, maybe with some
      arguments (concrete example: "spawn $my_closure;")<br>
    </p>
    <p>#2 is the most concise for the common case of using an existing
      function, because you don't need to make a callable / closure
      pointing to the function first (concrete example: "spawn
      my_function('my argument');")<br>
    </p>
    <p>BUT these two rules conflict: any function_call is also an expr,
      so we can't say "if it's an expr, do this; if it's a
      function_call, do that", because both are true at once.</p>
    <p><br>
    </p>
    <p>The next four are compromises to work around that conflict:<br>
    </p>
    <p>#3 is a version of #1 which doesn't conflict with #2 - introduce
      a new grammar rule which has all the things in expr, but not
      function_call. This is technically fine, but maybe confusing to
      the user, because "spawn $foo == spawn $foo()", but "spawn foo()
      != spawn foo()()", and "spawn $obj-&gt;foo != $obj-&gt;foo()".</p>
    <p>#4 is really the same principle, but restricted even further -
      the only expression allowed is the declaration of an inline
      function. 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<br>
    </p>
    <p>#5 and #6 are the "different keywords" options: they don't
      conflict with each other, and #1 could be used with #6, or #2 with
      #5. In concrete terms, you can have "spawn_func_call $foo() ==
      spawn_closure $foo", or "spawn $foo() == spawn_closure $foo", or
      "spawn_func_call $foo() == spawn $foo".</p>
    <p><br>
    </p>
    <p>#7 is the odd one out: it hides the closure from the user
      completely. It could be combined with any of the others, but most
      likely with #2<br>
    </p>
    <br>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMW7n8CmaAFmUVgeJ+Xcxo52yS7O3KjU_LfRx8E6-KZqDxGVEg@mail.gmail.com">
      <div dir="ltr">
        <div>In PHP, code blocks are not all the same.  <br>
          - `if` / `then` / `else` / `try` / `switch` **do not create a
          new scope**.  <br>
          - `function` **does create a new scope**.  <br>
          <br>
          When a programmer writes:  <br>
          ```php<br>
          $x = 5;<br>
          spawn {$x++};<br>
        </div>
        <div>```</div>
        <div>Will they easily understand that <code>$x++</code> is not
          modifying the same <code>$x</code> as before?<br>
          No, they won’t. They will have to remember that <code>spawn
            {}</code> creates a closure, just like <code>function</code>
          creates a closure with a separate scope. <br>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>OK, thanks; I think this is the point that I was missing - I was
      thinking that the engine creating a closure was just an
      implementation detail, which could be made invisible to the user.
      But you're right, the way variable scope works would be completely
      unlike anything else in the language. That probably rules out #7<br>
    </p>
    <p>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?</p>
    <p>If the aim is "a concise way to wrap a few statements", we've
      already failed if the user's writing out "function" and a "use"
      clause.<br>
    </p>
    <p>If the aim is "a readable way to use a closure", rule #2 is fine.<br>
    </p>
    <p>Yes, it means some extra parentheses if you squeeze it all into
      one statement, but it's probably more readable to assign the
      closure to a temporary variable anyway:</p>
    <p>// Legal under rule #2, but ugly<br>
      spawn (function() use($whatever) {<br>
          do_something($whatever);<br>
      })();</p>
    <p>// Requires rule #4, saves a few brackets<br>
      spawn function() use($whatever) {<br>
          do_something($whatever);<br>
      };</p>
    <p>// Only needs rule #2, and perfectly readable<br>
      $foo = function() use($whatever) {<br>
          do_something($whatever);<br>
      }<br>
      spawn $foo();</p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------GKTKy7SPNIbyln0yeVqm1rkx--