Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114777
User-Agent: Cyrus-JMAP/3.5.0-alpha0-519-g27a961944e-fm-20210531.001-g27a96194
Mime-Version: 1.0
Message-ID: <9c271680-da84-4de1-9f28-c6507f4f557f@www.fastmail.com>
In-Reply-To: <68DF0F38-621F-407F-ABEE-FEF388122EC9@newclarity.net>
References: <d50eaa78-21c7-46e7-9da6-629ba5694d3f@www.fastmail.com>
 <68DF0F38-621F-407F-ABEE-FEF388122EC9@newclarity.net>
Date: Mon, 07 Jun 2021 20:39:25 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Pipe Operator, take 2
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jun 7, 2021, at 8:09 PM, Mike Schinkel wrote:
> 
> > On Jun 7, 2021, at 3:00 PM, Larry Garfield <larry@garfieldtech.com> 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.
> 
> In general, much nicer with PFA than before.
> 
> A few questions though, although #1 is probably best answered by Derick Rethans:
> 
> 1. Will PHP consider a piped sequence a single expression?  More 
> specifically, will XDEBUG consider it a single expression, or could 
> XDEBUG be able to set a breakpoint at each pipe assuming they are on 
> separate lines?  
> 
> I ask because if pipes were an indivisible expression from the 
> standpoint of XDEBUG and breakpoints I would not want to see them 
> included in PHP. Alternately if included in PHP I would avoid using 
> them like the plague just like I avoid using fluent interfaces because 
> of their inability to be breakpointed at each step in XDEBUG.

$foo |> bar(?) |> baz(?);

will produce the same AST as

baz(bar($foo));

So whatever Xdebug can do with that AST, it should still be able to do.

> 2. Besides `throw` will there be a way to short-circuit evaluation 
> mid-way through the pipes without having to write all of the callables 
> to respect said short-circuiting and just return? 
> 
> For example, could returning an instance of an object that implements a 
> `ShortCircuitPipeInterface` allow the pipe to short-circuit, or some 
> other way to short-circuit and then determine after the pipe if it was 
> short-circuited?

What you're describing is effectively monads.  (There's that scary word again.)  That is not covered here, although I mention it in the future scope section.  There's a couple of ways it could be implemented, although you can already do so today in user-space with a method instead of a dedicated operator.  The caveat is monads essentially have to be either untyped or use generics, so for now we're stuck with untyped monads.

Alternatively, you can wrap each callable in another function that wraps the short-circuiting behavior around it.  That's essentially "railroad oriented programming", a term coined by Scott Wlaschin:

https://fsharpforfunandprofit.com/rop/

In other words, "I want that, but it comes later, via something more robust."

--Larry Garfield