Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115286
MIME-Version: 1.0
In-Reply-To: <63aa426c-30bc-4f00-8740-532fa0bef6f2@www.fastmail.com>
References: <d50eaa78-21c7-46e7-9da6-629ba5694d3f@www.fastmail.com> <63aa426c-30bc-4f00-8740-532fa0bef6f2@www.fastmail.com>
Date: Sun, 4 Jul 2021 09:18:32 +0200
Message-ID: <CAJpLVh3pZ8Wn6ZNctBxA-mt47-dVN7p7r6W5GP4anMCYb77Z1w@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Pipe Operator, take 2
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2021-07-04 4:12 GMT+02:00, Larry Garfield <larry@garfieldtech.com>:
> On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
>> Hi folks. Me again.
>>
>> A year ago, I posted an RFC for a pipe operator, |>, aka function
>> concatenation.  At the time, the main thrust of the feedback was "cool,
>> like, but we need partial function application first so that the syntax
>> for callables isn't so crappy."
>>
>> The PFA RFC is winding down now and is looking quite good, so it's time
>> to revisit pipes.
>>
>> https://wiki.php.net/rfc/pipe-operator-v2
>>
>> Nothing radical has changed in the proposal since last year.  I have
>> updated it against the latest master.  I also updated the RFC to use
>> more examples that assume PFA, as the result is legit much nicer.  i
>> also tested it locally with a combined partials-and-pipes branch to
>> make sure they play nicely together, and they do.  (Yay!)  Assuming PFA
>> passes I will include those tests in the pipes branch before this one
>> goes to a vote.
>
> Hi again.
>
> With PFA being declined, I've again reworked the Pipes RFC.
>
> 1) It now does not use PFA in any examples, but it does use Nikita's
> first-class-callables RFC that looks like it's going to pass easily.
>
> 2) With major hand-holding from Levi Morrison and Joe Watkins, the
> implementation has shifted a bit.  It now evaluates left-to-right, always,
> whereas the previous version evaluated right-to-left.  That is, instead of
> $a |> $b |> $c desugaring into $c($b($a)), it now becomes effectively $tmp =
> $a; $tmp = $b($tmp); $tmp = $c($tmp);  That matters if $b or $c are function
> calls that return a callable, as they are then only called when the pipeline
> gets to that part of the expression.

Hi! Can you flesh out an example for this, please? Not sure I get the
use-case where it matters. Couldn't find any example inside the PR
either (the tests) that show-cased this particular implementation
detail. Did I miss it?

Olle