Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115334
MIME-Version: 1.0
References: <d50eaa78-21c7-46e7-9da6-629ba5694d3f@www.fastmail.com>
 <63aa426c-30bc-4f00-8740-532fa0bef6f2@www.fastmail.com> <48bc0d19-ba92-4dbf-b2d4-a32688ed4e25@www.fastmail.com>
 <b3ca5c43-dd13-443f-9822-081c03ed653d@www.fastmail.com>
In-Reply-To: <b3ca5c43-dd13-443f-9822-081c03ed653d@www.fastmail.com>
Date: Wed, 7 Jul 2021 01:16:42 +0200
Message-ID: <CAOwTYAuba3P-dQ+=Qr4QKyR=Xg8oBU_3oPtyBWHauRY4n_UkKw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000d44a205c67c9e2c"
Subject: Re: [PHP-DEV] [RFC] Pipe Operator, take 2
From: krakjoe@gmail.com (Joe Watkins)

--0000000000000d44a205c67c9e2c
Content-Type: text/plain; charset="UTF-8"

Just to clarify,

I said it didn't look like it could be a pure AST implementation, and that
it looks like you may need one additional instruction.

It does look that way to me - if only to throw a sensible error
specifically for pipes but also because it makes the imposition of specific
behaviour for pipes a little easier, but it doesn't make it a super
complicated thing.

I also said I didn't know what the right answer was with regard to refs. I
still don't, although I lean towards blocking them at the moment having
spent a little more time looking at it.

I don't really think we've had long enough to have this conversation
properly.

Cheers
Joe

On Tue, 6 Jul 2021 at 19:05, Larry Garfield <larry@garfieldtech.com> wrote:

> On Mon, Jul 5, 2021, at 11:05 AM, Larry Garfield wrote:
> > On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote:
> > > 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.
> (If
> > > all the functions involved are pure functions, then it doesn't make a
> > > difference in practice.)
> > >
> > > 3) I included references to several existing PHP libraries that
> > > implement similar logic, in mostly complex and ugly ways.
> > >
> > > 4) Of note, Brent posted a Twitter poll last week about pipes, and the
> > > response was overwhelmingly in favor.
> > > (https://twitter.com/brendt_gd/status/1408271132650885123)  Naturally
> a
> > > Twitter poll is extremely unscientific, but I think between the
> > > existing libraries and the response there the answer to the question
> > > "is there actually a demand for this feature?" is unquestionably yes.
> > >
> > > 5) Examples have been reworked to be a bit prettier.
> > >
> > > 6) Added another language reference that has a pipe operator that
> works
> > > basically like described here. (OCaml)
> > >
> > > I am planning to take this version of the RFC to a vote on Monday or
> > > Tuesday, as Tuesday is the last day possible to start a vote for 8.1
> > > features.
> > >
> > > --Larry Garfield
> >
> > Based on feedback on the PR, I've updated the RFC to forbid functions
> > that pass or return by reference.  They're not really useful in pipes
> > at all, and were only supported before because the implementation
> > happened to allow it.
> >
> > The PR hasn't been updated for that yet, but I figure that's easy
> > enough to update post-vote if it passes.
>
> Sorry for the noise, but after some discussion with Joe it looks like
> blocking references in pipes is actually much harder than it sounded like,
> and would require a completely opcode based implementation rather than the
> completely AST-based implementation.  References on pipes are not really
> useful but in practice they don't hurt anything.  I've instead added more
> tests to validate that they behave "as expected" and noted that in the RFC
> instead.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--0000000000000d44a205c67c9e2c--