Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126343
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 07 Feb 2025 23:54:47 +0100
To: internals@lists.php.net
Message-ID: <040da4e2-2595-42ad-ab94-a0e87aed1a79@app.fastmail.com>
In-Reply-To: <bd93bbb9-e970-4211-af59-4ccd643dc52f@app.fastmail.com>
References: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
 <5a584219f120385e7e30f6d0a46cc108@bastelstu.be>
 <bd93bbb9-e970-4211-af59-4ccd643dc52f@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
Content-Type: multipart/alternative;
 boundary=d236eb7ceedd475db39514d2b95b7db2
From: rob@bottled.codes ("Rob Landers")

--d236eb7ceedd475db39514d2b95b7db2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Feb 7, 2025, at 22:04, Larry Garfield wrote:
> Merging a few replies together here, since they overlap.  Also reorder=
ing a few of Tim's comments...
>=20
> On Fri, Feb 7, 2025, at 7:32 AM, Tim D=C3=BCsterhus wrote:
> > Hi
> >
> > Am 2025-02-07 05:57, schrieb Larry Garfield:
> >> It is now back with a better implementation (many thanks to Ilija f=
or=20
> >> his help and guidance in that), and it's nowhere close to freeze, s=
o=20
> >> here we go again:
> >>=20
> >> https://wiki.php.net/rfc/pipe-operator-v3
> >
> > There's some editorial issues:
> >
> > 1. Status: Draft needs to be updated.
> > 2. The RFC needs to be added to the overview page.
> > 3. List formatting issues in =E2=80=9CFuture Scope=E2=80=9D and =E2=80=
=9CPatches and Tests=E2=80=9D.
> >
> > Would also help having a closed voting widget in the =E2=80=9CPropos=
ed Voting=20
> > Choices=E2=80=9D section to be crystal clear on what is being voted =
on (see=20
> > below the next quote).
>=20
> I split pipes off from the Composition RFC late last night right befor=
e posting; I guess I missed a few things while doing so. :-/  Most notab=
ly, the Compose section is now removed from pipes, as it is not in scope=
 for this RFC.  (As noted, it's going to be more work so has its own RFC=
.)  Sorry for the confusion.  I think it should all be handled now.
>=20
> > 5. The =E2=80=9CReferences=E2=80=9D (as in reference variables) sect=
ion would do well=20
> > with an example of what doesn't work.
>=20
> Example block added.
>=20
> > 9. In the =E2=80=9CWhy in the engine?=E2=80=9D section: The RFC make=
s a claim about=20
> > performance.
> >
> > Do you have any numbers?
>=20
> Not currently.  The statements here are based on simply counting the n=
umber of function calls necessary, and PHP function calls are sadly non-=
cheap.  In previous benchmarks of my own libraries using my Crell/fp lib=
rary, I did find that the number of function calls involved in some tigh=
t pipe operations was both a performance and debugging concern, but I do=
n't have any hard numbers laying about at present to share.
>=20
> If you think that's critical, please advise on how to best get meaning=
ful numbers here.
>=20
> Regarding the equivalency of pipes:
>=20
> Tim D=C3=BCsterhus wrote:
> > 4. =E2=80=9CThat is, the following two code fragments are also exact=
ly=20
> > equivalent:=E2=80=9D.
> >
> > I do not believe this is true (specifically referring to the =E2=80=9C=
exactly=E2=80=9D=20
> > word in there), since the second code fragment does not have the sho=
rt=20
> > closures, which likely results in an observable behavioral differenc=
e=20
> > when throwing Exceptions (in the stack trace) and also for debuggers=
. Or=20
> > is the implementation able to elide the the extra closure? (Of cours=
e=20
> > there's also the difference between the temporary variable existing,=20
> > with would be observable for `get_defined_vars()` and possibly=20
> > destructors / object lifetimes).
>=20
> Thomas Hruska wrote:
> > The repeated assignment to $temp in your second example is _not_=20
> > actually equal to the earlier example as you claim.  The second exam=
ple=20
> > with all of the $temp variables should, IMO, just be:
> >
> > $temp =3D "Hello World";
> > $result =3D array_filter(array_map('strtoupper',=20
> > str_split(htmlentities($temp))), fn($v) { return $v !=3D 'O'; });
>=20
> Juris Evertovskis wrote:
> > 3. Does the implementation actually turn `1 |> f(...) |> g(...)` int=
o=20
> > `$=CF=80 =3D f(1); g($=CF=80)`? Is `g(f(1))` not performanter? Or is=
 the engine=20
> > clever enough with the var reuse anyways?
>=20
> There's some subtlety here on these points.  The v2 RFC used the lexer=
 to mutate $a |> $b |> $c into the same AST as $c($b($a)), which would t=
hen compile as though that had been written in the first place.  However=
, that made addressing references much harder, and there's an important =
caveat around order of operations. (See below.)  The v3 RFC instead uses=
 a compile function to take the AST of $a |> $b |> $c and produce opcode=
s that are effectively equivalent to $t =3D $b($a); $t =3D $c($t);  I ha=
ve not compared to see if they are the precise same opcodes, but they ne=
t effect is the same.  So "effectively equivalent" may be a more accurat=
e statement.
>=20
> In particular, Tim is correct that, technically, the short lambdas wou=
ld be used as-is, so you'd end up with the equivalent of:
>=20
> $temp =3D (fn($x) =3D> array_map(strtoupper(...), $x))($temp);
>=20
> I'm not sure if there's a good way to automatically unwrap the closure=
 there.  (If someone knows of one, please share; I'm fine with including=
 it.)  However, the intent is that it would be largely unnecessary in th=
e future with a revised PFA implementation, which would obviate the need=
 for the explicit wrapping closure.  You would instead write
>=20
> $a |> array_map(strtoupper(...), ?);
>=20
> Alternatively, one can use higher order user-space functions already. =
 In trivial cases:
>=20
> function amap(Closure $fn): Closure {
>   return fn(array $x) =3D> array_map($fn, $x);
> }
>=20
> $a |> amap(strtoupper(...));
>=20
> Which I am already using in Crell/fp and several libraries that levera=
ge it, and it's quite ergonomic.
>=20
> There's a whole bunch of such simple higher order functions here:
> https://github.com/Crell/fp/blob/master/src/array.php
> https://github.com/Crell/fp/blob/master/src/string.php
>=20
> Which leads to the subtle difference between that and the v2 implement=
ation, and why Thomas' statement is incorrect.  If the expression on the=
 right side that produces a Closure has side effects (output, DB interac=
tion, etc.), then the order in which those side effects happen may chang=
e with the different restructuring.  With all pure functions, that won't=
 make a practical difference, and normally one should be using pure func=
tions, but that's not something PHP can enforce.
>=20
> I don't think there would be an appreciable performance difference bet=
ween the two compiled versions, either way, but using the temp-var appro=
ach makes dealing with references easier, so it's what we're doing.
>=20
> Juris Evertovskis wrote:
> > 1. Do you think it would be hard to add some shorthand for `|>=20
> > $condition ? $callable : fn($=F0=9F=98=90) =3D> $=F0=9F=98=90`?
>=20
> I'm not sure I follow here.  Assuming you're talking about "branch in =
the next step", the standard way of doing that is with a higher order us=
er-space function.  Something like:
>=20
> function cond(bool $cond, Closure $t, Closure $f): Closure {
>   return $cond ? $t : $f;
> }
>=20
> $a |> cond($config > 10, bigval(...), smallval(...)) |> otherstuff(...=
);
>=20
> I think it's premature to try and bake that logic into the language, e=
specially when I don't know of any other function-composition-having lan=
guage that does so at the language level rather than the standard librar=
y level.  (There are a number of fun operations people build into pipeli=
nes, but they are all generally done in user space.)
>=20
> --Larry Garfield
>=20

Put another way, what is the order of operations for this new operator?

For example, what is the output of

$x ? $y |> strlen(=E2=80=A6) : $z

$x + $y |> sqrt(=E2=80=A6) . EOL

Etc.

I noticed this seems to be missing from the RFC. As a new operator, I th=
ink it should be important to specify that.=20

=E2=80=94 Rob
--d236eb7ceedd475db39514d2b95b7db2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Fri, Feb 7, 2025, at 22:04, Larry Garfield wrote:<br><=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Merging a few r=
eplies together here, since they overlap.&nbsp; Also reordering a few of=
 Tim's comments...<br></div><div><br></div><div>On Fri, Feb 7, 2025, at =
7:32 AM, Tim D=C3=BCsterhus wrote:<br></div><div>&gt; Hi<br></div><div>&=
gt;<br></div><div>&gt; Am 2025-02-07 05:57, schrieb Larry Garfield:<br><=
/div><div>&gt;&gt; It is now back with a better implementation (many tha=
nks to Ilija for&nbsp;<br></div><div>&gt;&gt; his help and guidance in t=
hat), and it's nowhere close to freeze, so&nbsp;<br></div><div>&gt;&gt; =
here we go again:<br></div><div>&gt;&gt;&nbsp;<br></div><div>&gt;&gt;&nb=
sp;<a href=3D"https://wiki.php.net/rfc/pipe-operator-v3">https://wiki.ph=
p.net/rfc/pipe-operator-v3</a><br></div><div>&gt;<br></div><div>&gt; The=
re's some editorial issues:<br></div><div>&gt;<br></div><div>&gt; 1. Sta=
tus: Draft needs to be updated.<br></div><div>&gt; 2. The RFC needs to b=
e added to the overview page.<br></div><div>&gt; 3. List formatting issu=
es in =E2=80=9CFuture Scope=E2=80=9D and =E2=80=9CPatches and Tests=E2=80=
=9D.<br></div><div>&gt;<br></div><div>&gt; Would also help having a clos=
ed voting widget in the =E2=80=9CProposed Voting&nbsp;<br></div><div>&gt=
; Choices=E2=80=9D section to be crystal clear on what is being voted on=
 (see&nbsp;<br></div><div>&gt; below the next quote).<br></div><div><br>=
</div><div>I split pipes off from the Composition RFC late last night ri=
ght before posting; I guess I missed a few things while doing so. :-/&nb=
sp; Most notably, the Compose section is now removed from pipes, as it i=
s not in scope for this RFC.&nbsp; (As noted, it's going to be more work=
 so has its own RFC.)&nbsp; Sorry for the confusion.&nbsp; I think it sh=
ould all be handled now.<br></div><div><br></div><div>&gt; 5. The =E2=80=
=9CReferences=E2=80=9D (as in reference variables) section would do well=
&nbsp;<br></div><div>&gt; with an example of what doesn't work.<br></div=
><div><br></div><div>Example block added.<br></div><div><br></div><div>&=
gt; 9. In the =E2=80=9CWhy in the engine?=E2=80=9D section: The RFC make=
s a claim about&nbsp;<br></div><div>&gt; performance.<br></div><div>&gt;=
<br></div><div>&gt; Do you have any numbers?<br></div><div><br></div><di=
v>Not currently.&nbsp; The statements here are based on simply counting =
the number of function calls necessary, and PHP function calls are sadly=
 non-cheap.&nbsp; In previous benchmarks of my own libraries using my Cr=
ell/fp library, I did find that the number of function calls involved in=
 some tight pipe operations was both a performance and debugging concern=
, but I don't have any hard numbers laying about at present to share.<br=
></div><div><br></div><div>If you think that's critical, please advise o=
n how to best get meaningful numbers here.<br></div><div><br></div><div>=
Regarding the equivalency of pipes:<br></div><div><br></div><div>Tim D=C3=
=BCsterhus wrote:<br></div><div>&gt; 4. =E2=80=9CThat is, the following =
two code fragments are also exactly&nbsp;<br></div><div>&gt; equivalent:=
=E2=80=9D.<br></div><div>&gt;<br></div><div>&gt; I do not believe this i=
s true (specifically referring to the =E2=80=9Cexactly=E2=80=9D&nbsp;<br=
></div><div>&gt; word in there), since the second code fragment does not=
 have the short&nbsp;<br></div><div>&gt; closures, which likely results =
in an observable behavioral difference&nbsp;<br></div><div>&gt; when thr=
owing Exceptions (in the stack trace) and also for debuggers. Or&nbsp;<b=
r></div><div>&gt; is the implementation able to elide the the extra clos=
ure? (Of course&nbsp;<br></div><div>&gt; there's also the difference bet=
ween the temporary variable existing,&nbsp;<br></div><div>&gt; with woul=
d be observable for `get_defined_vars()` and possibly&nbsp;<br></div><di=
v>&gt; destructors / object lifetimes).<br></div><div><br></div><div>Tho=
mas Hruska wrote:<br></div><div>&gt; The repeated assignment to $temp in=
 your second example is _not_&nbsp;<br></div><div>&gt; actually equal to=
 the earlier example as you claim.&nbsp; The second example&nbsp;<br></d=
iv><div>&gt; with all of the $temp variables should, IMO, just be:<br></=
div><div>&gt;<br></div><div>&gt; $temp =3D "Hello World";<br></div><div>=
&gt; $result =3D array_filter(array_map('strtoupper',&nbsp;<br></div><di=
v>&gt; str_split(htmlentities($temp))), fn($v) { return $v !=3D 'O'; });=
<br></div><div><br></div><div>Juris Evertovskis wrote:<br></div><div>&gt=
; 3. Does the implementation actually turn `1 |&gt; f(...) |&gt; g(...)`=
 into&nbsp;<br></div><div>&gt; `$=CF=80 =3D f(1); g($=CF=80)`? Is `g(f(1=
))` not performanter? Or is the engine&nbsp;<br></div><div>&gt; clever e=
nough with the var reuse anyways?<br></div><div><br></div><div>There's s=
ome subtlety here on these points.&nbsp; The v2 RFC used the lexer to mu=
tate $a |&gt; $b |&gt; $c into the same AST as $c($b($a)), which would t=
hen compile as though that had been written in the first place.&nbsp; Ho=
wever, that made addressing references much harder, and there's an impor=
tant caveat around order of operations. (See below.)&nbsp; The v3 RFC in=
stead uses a compile function to take the AST of $a |&gt; $b |&gt; $c an=
d produce opcodes that are effectively equivalent to $t =3D $b($a); $t =3D=
 $c($t);&nbsp; I have not compared to see if they are the precise same o=
pcodes, but they net effect is the same.&nbsp; So "effectively equivalen=
t" may be a more accurate statement.<br></div><div><br></div><div>In par=
ticular, Tim is correct that, technically, the short lambdas would be us=
ed as-is, so you'd end up with the equivalent of:<br></div><div><br></di=
v><div>$temp =3D (fn($x) =3D&gt; array_map(strtoupper(...), $x))($temp);=
<br></div><div><br></div><div>I'm not sure if there's a good way to auto=
matically unwrap the closure there.&nbsp; (If someone knows of one, plea=
se share; I'm fine with including it.)&nbsp; However, the intent is that=
 it would be largely unnecessary in the future with a revised PFA implem=
entation, which would obviate the need for the explicit wrapping closure=
.&nbsp; You would instead write<br></div><div><br></div><div>$a |&gt; ar=
ray_map(strtoupper(...), ?);<br></div><div><br></div><div>Alternatively,=
 one can use higher order user-space functions already.&nbsp; In trivial=
 cases:<br></div><div><br></div><div>function amap(Closure $fn): Closure=
 {<br></div><div>&nbsp; return fn(array $x) =3D&gt; array_map($fn, $x);<=
br></div><div>}<br></div><div><br></div><div>$a |&gt; amap(strtoupper(..=
.));<br></div><div><br></div><div>Which I am already using in Crell/fp a=
nd several libraries that leverage it, and it's quite ergonomic.<br></di=
v><div><br></div><div>There's a whole bunch of such simple higher order =
functions here:<br></div><div><a href=3D"https://github.com/Crell/fp/blo=
b/master/src/array.php">https://github.com/Crell/fp/blob/master/src/arra=
y.php</a><br></div><div><a href=3D"https://github.com/Crell/fp/blob/mast=
er/src/string.php">https://github.com/Crell/fp/blob/master/src/string.ph=
p</a><br></div><div><br></div><div>Which leads to the subtle difference =
between that and the v2 implementation, and why Thomas' statement is inc=
orrect.&nbsp; If the expression on the right side that produces a Closur=
e has side effects (output, DB interaction, etc.), then the order in whi=
ch those side effects happen may change with the different restructuring=
.&nbsp; With all pure functions, that won't make a practical difference,=
 and normally one should be using pure functions, but that's not somethi=
ng PHP can enforce.<br></div><div><br></div><div>I don't think there wou=
ld be an appreciable performance difference between the two compiled ver=
sions, either way, but using the temp-var approach makes dealing with re=
ferences easier, so it's what we're doing.<br></div><div><br></div><div>=
Juris Evertovskis wrote:<br></div><div>&gt; 1. Do you think it would be =
hard to add some shorthand for `|&gt;&nbsp;<br></div><div>&gt; $conditio=
n ? $callable : fn($=F0=9F=98=90) =3D&gt; $=F0=9F=98=90`?<br></div><div>=
<br></div><div>I'm not sure I follow here.&nbsp; Assuming you're talking=
 about "branch in the next step", the standard way of doing that is with=
 a higher order user-space function.&nbsp; Something like:<br></div><div=
><br></div><div>function cond(bool $cond, Closure $t, Closure $f): Closu=
re {<br></div><div>&nbsp; return $cond ? $t : $f;<br></div><div>}<br></d=
iv><div><br></div><div>$a |&gt; cond($config &gt; 10, bigval(...), small=
val(...)) |&gt; otherstuff(...);<br></div><div><br></div><div>I think it=
's premature to try and bake that logic into the language, especially wh=
en I don't know of any other function-composition-having language that d=
oes so at the language level rather than the standard library level.&nbs=
p; (There are a number of fun operations people build into pipelines, bu=
t they are all generally done in user space.)<br></div><div><br></div><d=
iv>--Larry Garfield<br></div><div><br></div></blockquote><div><br></div>=
<div>Put another way, what is the order of operations for this new opera=
tor?<br></div><div><br></div><div>For example, what is the output of<br>=
</div><div><br></div><div>$x ? $y |&gt; strlen(=E2=80=A6) : $z<br></div>=
<div><br></div><div>$x + $y |&gt; sqrt(=E2=80=A6) . EOL<br></div><div><b=
r></div><div>Etc.</div><div><br></div><div>I noticed this seems to be mi=
ssing from the RFC. As a new operator, I think it should be important to=
 specify that.&nbsp;<br></div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob<br></div></body></html>
--d236eb7ceedd475db39514d2b95b7db2--