Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93272
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kalpe.com from 209.85.223.172 cause and error)
MIME-Version: 1.0
In-Reply-To: <CANaX5nekRmhNKmY78tHRrev0_B3a-faRsQ8Jf=yA-jCkEP5-Ew@mail.gmail.com>
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
 <39071a01-a42c-0952-b3a8-b4769c79b56b@fleshgrinder.com> <CAESVnVpwbYdeENZ4CW1m8KiLSZv87x5TO3+72uYYR262rgYL3Q@mail.gmail.com>
 <0ac3be89-6fb4-610a-ef89-0928f264f96c@fleshgrinder.com> <CAESVnVpBn2fpK-BQXj2261mTMG7ZUK1XwOS6jZn1wiYBEs61mg@mail.gmail.com>
 <71379db5-b7b8-78b3-ada5-eee34e6e22d6@fleshgrinder.com> <CAObuZdtS-gn3gT6L2bwshF4H9KzxZSaCsu41CYtyeT+=SOCSyg@mail.gmail.com>
 <a25612f2-fb09-c25e-ca30-daf850acaa96@fleshgrinder.com> <CAObuZduo2-mnZMbgKFEWN1=yxqgqh_8RCN7GSpCTYCNXVjWJ_w@mail.gmail.com>
 <fe837e8b-2a6e-516e-33f0-cfcca172d565@fleshgrinder.com> <CAGa2bXaKWu+WJ7unZ2TfG03KUYY3JyNG=FK3cUbR3PL244znyA@mail.gmail.com>
 <ddcfc338-a2fb-a06f-36ef-30e105772779@gmail.com> <CAESVnVr07J9UF3Dh7a1rMudMmQjeYuayvoT8Rmde+rfCBK6vnQ@mail.gmail.com>
 <452ddb93-1f47-1d0f-4f24-bedbff506b27@gmail.com> <CAESVnVqohR7rkaJASZ0rFuAD6GEiasqbAak-fJB3+K2vSKqHFQ@mail.gmail.com>
 <98.61.11104.A1D41375@pb1.pair.com> <7c94ca37-e188-dd2b-a66f-bb63bf03041a@gmail.com>
 <1463008795.1856219.605250569.74618FC4@webmail.messagingengine.com> <CANaX5nekRmhNKmY78tHRrev0_B3a-faRsQ8Jf=yA-jCkEP5-Ew@mail.gmail.com>
Date: Thu, 12 May 2016 14:33:49 +0200
Message-ID: <CAKrrN64bu+T0Sv4V6mo7i1cRYAh1W8Kx8tQ_rqQmZagXBTqKuQ@mail.gmail.com>
To: Davey Shafik <davey@php.net>
Cc: Larry Garfield <larry@garfieldtech.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ecdbef7ce710532a45f60
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: quim@kalpe.com (Quim Calpe)

--001a113ecdbef7ce710532a45f60
Content-Type: text/plain; charset=UTF-8

On Thu, May 12, 2016 at 12:33 PM, Davey Shafik <davey@php.net> wrote:

> On Thu, May 12, 2016 at 1:19 AM, Larry Garfield <larry@garfieldtech.com>
> wrote:
>
> > On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
> > > Hi!
> > >
> > > > |> seems like a common symbol to use, but it admittedly does look a
> > >
> > > So, usage in one semi-obscure language (F#) and one completely obscure
> > > one (Elixir) - Clojure doesn't use |> - and one proposal for Javascript
> > > now qualifies for "common". And that counting the fact that neither of
> > > them actually uses the worst part of proposed syntax - magic variable
> $$.
>

Is $0 being considered? It's not ideal but is used as "pattern match
reference" in preg_replace, so we have a (sort of) precedent here. Same for
$1 (first capturing subpattern).


>
> > > --
> > > Stas Malyshev
> > > smalyshev@gmail.com
> >
> > If the issue is $$ feels too Perl like, what is the alternative?  Is
> > there another way to chain methods cleanly?
> >
> > In a sense, what we're really talking about here is continuations.
> > Continuations (over-simplified) are a clean way of setting up "run this
> > function, pass its result to this function, pass its result to this
> > function, etc."  That makes composition really easy.  |> is essentially
> > a continuation syntax.  The $$ is to work around the fact that PHP
> > function can have an arbitrary number of parameters, whereas
> > continuations work best with single-parameter functions.
> >
> > Of course, with currying any multi-parameter function can be reduced to
> > a series of single parameter functions.  So what if we were to limit the
> > concurrency syntax to single-parameter functions?  And if you want to
> > reduce a multi-parameter function to a single parameter function, yay
> > closures.
> >
> > Would that limitation help or hinder?
> >
> > Either way, I firmly believe that more functional-friendly capabilities
> > like continuations, promises, etc. are a direction that PHP needs to
> > move, and syntax in that direction is valuable.
>
>
> I wonder if it's possible to use $$ only when it's necessary to pass in the
> argument positionally, that is, if it's not used on the right hand side,
> it's passed in magically as the first argument, otherwise it's passed in
> wherever the $$ (or whatever other placeholder you want) is used.
>
> _OR_ we just prepend it to the argument list used on the RHS. I noticed
> that Closure also have ->> for passing in the argument last, vs -> for
> first. I'm not sure I would like to have |>> for example.
>
> I think that $$ as a positional placeholder gives us the most flexibility.
> $$ is super easy to type, apparently is possible with little conflict to
> existing syntax, etc.
>
> I'm +1 on |> and $$.
>
> - Davey
>

--001a113ecdbef7ce710532a45f60--