Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127036
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------eH0Gz2iZB29rxETD3FYiKLjB"
Message-ID: <51df1d77-33ce-414e-b489-8a62f9768811@rwec.co.uk>
Date: Thu, 3 Apr 2025 22:06:15 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
To: internals@lists.php.net
References: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
 <CAPyj-LBvmUfhakS+Z9wDYQ-J7Bypk9bbTupPqv-kvfPp8r_qnA@mail.gmail.com>
 <5efa2f02-dd1d-4d59-ae07-c75f193b4096@app.fastmail.com>
 <92b7f1ea-900b-4438-bed7-3fd766bb2d61@rwec.co.uk>
 <7e2a3dea-aaaf-4427-b1b2-32c568af8b77@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <7e2a3dea-aaaf-4427-b1b2-32c568af8b77@app.fastmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------eH0Gz2iZB29rxETD3FYiKLjB
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 03/04/2025 18:06, Larry Garfield wrote:
> So if we expect higher order functions to be common (and I would probably mainly use them myself), then it would be wise to figure out some way to make them more efficient.  Auto-first-arg is one way.


 From this angle, auto-first-arg is a very limited compiler optimisation 
for partial application.

With auto-first-arg, you have a parser rule that matches this:

$foo |> bar($baz);

and results in the same AST/opcodes as this:

bar($foo, $baz);


With PFA and one-arg-callable pipes, you could add a parser rule that 
matches this, with the same output:

$foo |> bar(?, $baz);

But you'd also be able to do this:

$baz |> bar($foo, ?);

And maybe the compiler could optimise that case too.


Neither helps with the performance of higher order functions which are 
doing more than partial application, like map and filter themselves. I 
understand there's a high cost to context-switching between C and PHP; 
presumably if there was an easy solution for that someone would have 
done it already.



On 03/04/2025 18:39, Ilija Tovilo wrote:
> To me, pipes improve readability when they behave like methods, i.e.
> they perform some operation on a subject. This resembles Swift's
> protocol extensions or Rust's trait default implementations, except
> using a different "method" call operator.
> [...]
> If we decide not to add an iterator API that works well with
> first-arg, then I agree that this is not the right approach. But if we
> do, then neither of your examples are problematic.


I guess those two things go together quite well as a mental model: pipes 
as a way to implement extension methods, and new functions designed for 
use as extension methods.

I think I'd be more welcoming of it if we actually implemented extension 
methods instead of pipes, and then the new iterator API was 
extension-method-only. It feels less like "one of the arguments is 
missing" if that argument is *always* expressed as the left-hand side of 
an arrow or some sort.


-- 
Rowan Tommins
[IMSoP]

--------------eH0Gz2iZB29rxETD3FYiKLjB
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 03/04/2025 18:06, Larry Garfield
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:7e2a3dea-aaaf-4427-b1b2-32c568af8b77@app.fastmail.com">
      <pre class="moz-quote-pre" wrap="">So if we expect higher order functions to be common (and I would probably mainly use them myself), then it would be wise to figure out some way to make them more efficient.  Auto-first-arg is one way.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>From this angle, auto-first-arg is a very limited compiler
      optimisation for partial application. </p>
    <p>With auto-first-arg, you have a parser rule that matches this:<br>
    </p>
    <p>$foo |&gt; bar($baz);</p>
    <p>and results in the same AST/opcodes as this:<br>
    </p>
    <p>
      bar($foo, $baz);</p>
    <p><br>
    </p>
    <p>With PFA and one-arg-callable pipes, you could add a parser rule
      that matches this, with the same output:<br>
    </p>
    <p>$foo |&gt; bar(?, $baz);</p>
    <p>But you'd also be able to do this:</p>
    <p>$baz |&gt; bar($foo, ?);</p>
    <p>And maybe the compiler could optimise that case too.</p>
    <p><br>
    </p>
    <p>Neither helps with the performance of higher order functions
      which are doing more than partial application, like map and filter
      themselves. I understand there's a high cost to context-switching
      between C and PHP; presumably if there was an easy solution for
      that someone would have done it already.<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 03/04/2025 18:39, Ilija Tovilo
      wrote:<span style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
cite="mid:CAPyj-LDnq3GM3A5hpO4-Cmq3TD3SC1L_29ViQiu1umuF6_jNSA@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">To me, pipes improve readability when they behave like methods, i.e.
they perform some operation on a subject. This resembles Swift's
protocol extensions or Rust's trait default implementations, except
using a different "method" call operator. 
[...]
If we decide not to add an iterator API that works well with
first-arg, then I agree that this is not the right approach. But if we
do, then neither of your examples are problematic.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>I guess those two things go together quite well as a mental
      model: pipes as a way to implement extension methods, and new
      functions designed for use as extension methods.</p>
    <p>I think I'd be more welcoming of it if we actually implemented
      extension methods instead of pipes, and then the new iterator API
      was extension-method-only. It feels less like "one of the
      arguments is missing" if that argument is *always* expressed as
      the left-hand side of an arrow or some sort.<br>
    </p>
    <p><br>
    </p>
    <p></p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------eH0Gz2iZB29rxETD3FYiKLjB--