Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94648
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
To: PHP internals <internals@lists.php.net>
References: <CAESVnVoBrtfWGF-Be+uXWwLNO3=JzuLBXyhW0Dpo-NvoskofQw@mail.gmail.com>
 <71557808-5718-0406-3df9-830bc2e03006@gmail.com>
 <CAESVnVosKc=-yfF3oAP3Oo9Z4F9_Fcv9Nu12S6SOPWykO6ZX5w@mail.gmail.com>
 <5024e8b2-4a4d-4a12-99f3-a539c9930337@gmail.com>
 <CAESVnVp9JeHjODR6vTiYAOsOOs7dw6D95zgxQ3yVhCvKGDr7xw@mail.gmail.com>
Message-ID: <b4fe9f42-3cf0-26d9-60db-782a4ac3d125@gmail.com>
Date: Sat, 23 Jul 2016 16:15:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAESVnVp9JeHjODR6vTiYAOsOOs7dw6D95zgxQ3yVhCvKGDr7xw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Pipe Operator v2
From: rowan.collins@gmail.com (Rowan Collins)

On 22/07/2016 06:52, Sara Golemon wrote:
> Ah! I understand your point now.  Indeed, in terms of code-scan,
> there's something of a whiplash effect going on. Now I understand the
> motivation behind $> assignment and/or using a terminal like `return
> $$` at the end.
>
> Adding in support for some terminals (like return) could make sense,
> it's an exception to a rule, but it's a reasonable looking one (at
> first glance, anyway).

Glad it makes sense. :) I realise "return $$" would have to have some 
special handling, but it would feel more natural to me. I guess the only 
concern is what happens when a pipeline has a return terminal and is 
used in expression context:

$foo = bar() |> baz($$) |> return $$;
// theoretically translates to this invalid PHP:
$foo = return baz(bar());

I'm not sure how easily the compiler would be able to pick up that 
that's an illegal construction.


I was going to say that "yield" would be worth considering at the same 
time, but presumably that's already legal, because yield can appear as 
an expression (to receive variables sent into a co-routine).

It's a shame neither "echo" nor "print" is useful for getting $$ out to 
screen and leaving it unchanged (echo doesn't work in expression context 
at all; print doesn't have a useful return value).


> The assign to var at the end however, is something I'd rather handle
> with the following:
>
> foo() |> bar($$) |> $baz = qux($$);
>
> Which is both legal with the syntax as-is, and entirely readable
> without adding an extra operator.

Yes, on reflection I think "|> $foo = $$" is probably easier to follow 
than extra syntax. I quite like the idea of a whole language where data 
always flows left-to-right, but we're used to that being what assignment 
looks like.

It might be worth coming up with some examples to add to the RFC where 
$$ is used in an expression other than a function call, because I wasn't 
entirely sure when I read it if that was even allowed. It might also 
clear up some of the confusion around this being anything to do with OO.

Off the top of my head, how about some maths:

$foo * $bar
     |> 2 ** $$
     |> sin($$ + 1)
     |> $$ / 20
     |> $result = $$;

Compiles to:

$result = sin((2 ** ($foo * $bar)) + 1) / 20;

Or:

$temp = $foo * $bar;
$temp = 2 ** $temp;
$temp = sin($temp + 1);
$result = $temp / 20;

Regards,

-- 
Rowan Collins
[IMSoP]