Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100726
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.216.175 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <alpine.DEB.2.20.1709201751560.21802@singlemalt.home.derickrethans.nl>
References: <CAESVnVo4axBD86qLbXvq4Mb39Dgdx_RQ1rH3KEG8ToaF7CbDag@mail.gmail.com>
 <CAF+90c85W1O6fso9GT9AgAw3fSx9+eM_p6aRfSdhRKzDr-LKBA@mail.gmail.com> <alpine.DEB.2.20.1709201751560.21802@singlemalt.home.derickrethans.nl>
Date: Wed, 20 Sep 2017 13:37:40 -0400
Message-ID: <CAESVnVqeXQHUV9VFcAm5UY+y1DCrcUPiNCrJWVBh1ceiM=v2Tg@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2
From: pollita@php.net (Sara Golemon)

On Wed, Sep 20, 2017 at 12:52 PM, Derick Rethans <derick@php.net> wrote:
> On Wed, 20 Sep 2017, Nikita Popov wrote:
>> > Future Scope: Short Lambdas `$x => $x + 1` and Partial Functions
>> > `someFunc('fixed val1', ..., 'fixed val2')`  would help make this
>> > functionality more useful and are worth discussing as a sub-thread,
>> > but are not required to be implemented at the same time.
>> >
>>
>> I think this feature makes very little sense if it's not introduced
>> together with a way of making partial application much more ergonomic than
>> it is now.
>>
I generally agree with this statement, and it's why the original
pipe-op (as with hacklang's version) included (a form of) pfa
implicitly.  If that means we should nail down the specifics of PFA
and/or Short-Lambdas before even bothering to move into full draft of
PipeOp, then that's fine.

Levi made the very solid argument that they can be independently
considered even if they compliment each other well, and given the
triviality of the pipe half of that equation, I put it together first
so that we have something to look at.

On the topic of pipe2 specifically:
The positive side of this diff is that it has zero impact on the
backend compiler or opcache since it doesn't produce any new AST
elements.  On the minus side, the AST it produces opaques the original
format.  In practice, this hack is only visible if you're using your
or my ast extensions, or if you use a failing assert.  This is what I
like the least about the approach I included in my link.  It's not the
first place we've hidden original intent behind AST transformations,
but it's certainly the most visually jarring when serialized.

> What do you mean here by "partial application"?
>
$trimX = trim($$, $x);

In this example, trim isn't invoked immediately, instead, $trimX
becomes a callable (closure) which takes a single argument and invokes
trim() with that argument and the captured $x variable.  We've
"partially applied" some arguments to the trim() function, but we
haven't finished forming a function call yet.

Essentially, the above turns into this:
$trimX = function($arg) use ($x) { return trim($arg, $x); };

The '$$' token used by HackLang's PipeOp works well enough because we
know that RHS is only ever going to receive one argument (the result
of LHS).  A more generic approach to PFA would probably involve
allowing for multiple positional arguments, perhaps like:

$myInArray = in_array($2, $1); // Reverse the arg order, effectively

PFA and ShortLambdas have the same scope capture issues however, which
make them thornier issues to tackle.

-Sara