Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97873
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.65 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAESVnVoBrtfWGF-Be+uXWwLNO3=JzuLBXyhW0Dpo-NvoskofQw@mail.gmail.com>
References: <CAESVnVoBrtfWGF-Be+uXWwLNO3=JzuLBXyhW0Dpo-NvoskofQw@mail.gmail.com>
Date: Thu, 19 Jan 2017 05:54:41 -0700
Message-ID: <CAFMT4Np4zPjDKswAcjA_TkJ70yMEzrRH2SJk_h1k26HnjMyuoA@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Pipe Operator v2
From: levim@php.net (Levi Morrison)

On Wed, Jul 20, 2016 at 5:42 PM, Sara Golemon <pollita@php.net> wrote:
> With the branching of 7.1, and after some reflection on the previous
> feedback, I'd like to reopen discussion of the Pipe Operator RFC
> https://wiki.php.net/rfc/pipe-operator which I had previously put on
> hold.  I've changed much of the argument wording of the proposal, but
> not the substantive feature set.  If you still feel it's unworkable,
> I'd like to encourage you to respond with what you think would make it
> workable (if anything).  Thanks.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

I've talked to you about this RFC off-list, but I figured I should
mention it on-list as well. I think we should make `|>` and `$$` two
independent operators that work well together (rather than only
together).

The `|>` symbol would be the piping operator with these semantics:

    1. Evaluate the left-hand side.
    2. Evaluate the right-hand side. Assert that the result is callable.
    3. Pass the result from 1. as the single argument to 2.

The `$$` symbol would be the partial function application operator
with these semantics:

    1. When function application has `$$` as a parameter it becomes a
partial application instead. This result of a partial application is a
closure.
    2. Each non-`$$` parameter is evaluated and then bound at that position.
    3. Each `$$` will become a parameter to the closure which will be
passed to the inner function call at its original position.
    4. Each parameter and closed variable will be done by reference or
by value depending on the function being called. The type will also be
inherited.
    5. The return type of the closure will be inherited from the
function it is calling.

As an optimization when `|>` and `$$` are used in conjunction there is
no need to create closures. This would make the outlined semantics be
equivalent to the currently proposed RFC when used together.

What do the rest of you think about this instead?