On Mon, Jun 7, 2021, at 8:09 PM, Mike Schinkel wrote:
> 
> > On Jun 7, 2021, at 3:00 PM, Larry Garfield <la...@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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to