Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109898
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-ID: <46adaf3a-be5b-4eaf-b2fd-7243d00200e1@www.fastmail.com>
In-Reply-To: <b13c0d2c-9407-4651-8ec7-0dd9b6550901@www.fastmail.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>
 <b13c0d2c-9407-4651-8ec7-0dd9b6550901@www.fastmail.com>
Date: Tue, 28 Apr 2020 19:34:57 -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")

On Tue, Apr 21, 2020, at 9:43 AM, Larry Garfield wrote:

> 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.

Just an update: I've tweaked the patch based on feedback from a few folks.  The precedence now seems to be where it is most logical (to me), and I've changed what the flag is on the AST node based on a recommendation from Nikita (assuming I understood him correctly).  I think it's in an acceptable final state at the moment baring any further feedback on GitHub.

It sounds like the only negative pushback at the moment is "can we do partial application first?"  Which... I'd love to but we need help on that. :-)  (Volunteers welcome.)  Is there any other pushback?

How do people feel about putting this to a vote sometime next week?  I don't know how long I want to sit on it waiting to see if we can pull off partial application.  I also want the partial application RFC, for reasons stated, but still feel that both are beneficial enough to stand on their own and it doesn't really matter which happens first.

--Larry Garfield