Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109754
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-ID: <b13c0d2c-9407-4651-8ec7-0dd9b6550901@www.fastmail.com>
In-Reply-To: 
 <CAESVnVpzB-m8MCkCm-Nt1tRSUyZQ_320W3b5gyi3ymMPuvrU-g@mail.gmail.com>
References: <2677cdc6-309c-4e4e-9cd9-12ff2a90c1e1@www.fastmail.com>
 <93A509E9-E6BC-425C-A584-F49F094E75B0@benramsey.com>
 <CAESVnVpzB-m8MCkCm-Nt1tRSUyZQ_320W3b5gyi3ymMPuvrU-g@mail.gmail.com>
Date: Tue, 21 Apr 2020 09:43:22 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Function pipe operator
From: larry@garfieldtech.com ("Larry Garfield")

Replying to a couple of people at once.

On Mon, Apr 20, 2020, at 11:06 PM, Sara Golemon wrote:
> On Mon, Apr 20, 2020 at 9:39 PM Ben Ramsey <ben@benramsey.com> wrote:
> 
> > > On Apr 20, 2020, at 20:38, Larry Garfield <larry@garfieldtech.com>
> > wrote:
> > >
> > > I've been commenting on other RFCs enough lately that I should probably
> > put myself through the wringer, too.  I therefore offer this RFC to add a
> > function pipe operator, as seen in a number of other languages:
> > >
> > > https://wiki.php.net/rfc/pipe-operator-v2
> > >
> >
> Happy with the revival, and I do want to underline the "Future Work"
> section about Partial Functions.  PF will make this version of pipes 100%
> more readable and fluent, and I want to endorse both, but I'll take one at
> a time.
> 
> -Sara

On Mon, Apr 20, 2020, at 10:55 PM, Mike Schinkel wrote:
> A questions and a comment:
> 
> 1. How will XDEBUG handle a multiline construct such as this?  Will it 
> treat as one expression, or allow breakpoints at each "link" in the 
> pipe chain?
> 
> Maybe this is a better question for Derek Rethans?

I defer to Derek.  My gut feeling is that since all the executor sees is foo(bar(baz(beep($a))), it will behave the same as if you had that line and put a breakpoint on it.

On Tue, Apr 21, 2020, at 4:04 AM, Marco Pivetta wrote:
> Hey Larry,
> 
> This looks good!
> 
> One question arises: how do exception traces look like, if they happen
> mid-pipe? Is the pipe effectively attaching stack frames to the entire
> thing, or is it flattening the trace?

The pipe is literally translating at the AST level to foo(bar(baz(beep($a))), so if baz() throws an exception I presume it would look the same in the stack trace.

On Mon, Apr 20, 2020, at 11:20 PM, Stanislav Malyshev wrote:
> Just a small pedantry note - in a comparison section, the RFC compares
> this syntax to function composition. But this is not function
> composition. This is a syntax sugar for calling two functions one after
> another, not operator that produces a function. It sounds pedantic but
> it's rather important distinction - if |> is composition, than $foo |>
> $bar is a new callable provided $foo and $bar are callable (but no
> function is actually being called here!). If |> is call syntax, it's
> actually the result of calling $bar($foo).
> 
> So comparing it to function composition is a bit confusing. Otherwise it
> looks OK to me, except the syntax for calling functions and methods is a
> bit awkward, but it's not the problem of this RFC I imagine.

I'm not sure I follow.  The only place composition is mentioned is in the F# section, where it calls out specifically that we're implementing "pipe forward" and *not* the composition operators ( >> ).  Is that unclear?

And a bunch of people on this topic:

Mike Schinkel:
> 2. The exclusive use of callable seems problematic prior to an 
> inclusion a '::function' operator that can be applied to functions for 
> symbol resolution to function name as it will encourage more use of 
> strings that are not checked by PHP.  Maybe we could address that first?
> 
> Also #2 would be true for method names although how that might be 
> implemented is a bit more complicated.


On Tue, Apr 21, 2020, at 3:59 AM, Nikita Popov wrote:
> I like the basic idea, but don't think it makes sense to introduce the
> syntax *before* we have first-class support for partial function
> application. Without it, you're forced to use PHP's awkward callable
> syntax, which imho makes for a regression over writing things the normal
> way.
> 
> Nikita


On Mon, Apr 20, 2020, at 11:06 PM, Sara Golemon wrote:
> Happy with the revival, and I do want to underline the "Future Work"
> section about Partial Functions.  PF will make this version of pipes 100%
> more readable and fluent, and I want to endorse both, but I'll take one at
> a time.

I agree that the pipe operator relies on having a "good" (subjective) way to reference callables, which is a weakness of PHP right now.  We discussed that in depth a few months ago as well.

IMO, short-lambdas in 7.4 are "good enough" to make the pipe operator useful.  They're not ideal, but they're sufficient.

Levi's partial application RFC would be close enough to ideal; You could reference an already-single-parameter or multi-parameter function lexically without any string parsing silliness, which means namespace resolution works, and it could potentially be optimized to avoid an extra layer of function call.  It would be even better than ::function, IMO, because you can provide it with closed-over variables at the same time.  It sounds like we all want that.

I do not believe that should block the pipe operator, however.  This is a case where two independent RFCs should be able to stand on their own but create a "sum is greater than their parts" situation, which is a good thing.

If anyone has bandwidth, I'm happy to collaborate on the PF RFC as well.  It's out of my solo skillset right now (frankly so was pipe until this weekend), but if someone is able to provide hand-holding/pairing I'm willing to work on that, too, either now in parallel or after pipe lands.  Both should happen, but I don't think either should block the other.

--Larry Garfield