Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128524
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 22 Aug 2025 11:40:46 +0200
To: internals@lists.php.net
Message-ID: <a5d120d2-0c5b-4391-ab26-2e3e0fade66e@app.fastmail.com>
In-Reply-To: <08a0d032-b2f9-4bc6-b44d-f5a02b6ab376@app.fastmail.com>
References: <d9a8a677-46be-4ed1-8d74-5adf52f935d2@app.fastmail.com>
 <1755766483699.1651677569.3151523711@yahoo.de>
 <08a0d032-b2f9-4bc6-b44d-f5a02b6ab376@app.fastmail.com>
Subject: Re: [PHP-DEV] Pipe precedence challenges
Content-Type: multipart/alternative;
 boundary=dc22a09666954d77af335b521250769c
From: rob@bottled.codes ("Rob Landers")

--dc22a09666954d77af335b521250769c
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 21, 2025, at 15:53, Larry Garfield wrote:
> On Thu, Aug 21, 2025, at 4:07 AM, Hans Krentel wrote:
> > On Thursday 14 August 2025 21:30:08 (+02:00), Larry Garfield wrote:
> >
> >> Does anyone have a better solution to suggest?
> >
> > I've been following the discussion on the pipe/short-closure precede=
nce
> > issue, and while the parentheses-based solution works, it does lead =
to
> > syntactic noise that undermines the readability benefits of pipes.
> >
> > I'd like to suggest an alternative that turns this problem into an
> > opportunity for a more elegant syntax.
> >
> > Inspired by prior art like Haskell's `do` notation, I propose what I
> > call "short closure canned pipes." The idea is to leverage the greedy
> > nature of short closures to define a clean, linear pipe chain within=
 a
> > closure context.  Instead of fighting the precedence, we embrace it =
to
> > create a new form:
> >
> >
> > Current problematic example (even with parentheses):
> > ----------------------------------------------------
> >
> >     fn($x) =3D> ($x
> >     |> (fn($x) =3D> array_map(strtoupper(...), $x))
> >     |> (fn($x) =3D> array_filter($x, fn($v) =3D> $v !=3D 'O'))
> >     );
> >
> > Proposed "canned pipes" syntax:
> > -------------------------------
> >
> >     fn($x) =3D>
> >     |> array_map(strtoupper(...), $x)
> >     |> array_filter($x, fn($v) =3D> $v !=3D 'O')
> >     ;
> >
> >
> > This syntax:
> >
> > * Resolves the ambiguity: The `fn($x) =3D>` explicitly "cans" the va=
lue
> >   for the entire pipe chain, making the precedence clear without
> >   parentheses.
> > =20
> > * Reduces boilerplate: It eliminates the repetition of `fn($x) =3D>`=
 and
> >   nested parentheses, making the code more readable and maintainable.
> > =20
> > * Aligns with intent: It reads as a simple sequence of transformatio=
ns,
> >   which is the core goal of the pipe operator.
> > =20
> > This approach effectively provides syntactic sugar for the common ca=
se
> > of processing a value through a pipe chain within a closure. It turns
> > the late-discovered defect into a win for developer ergonomics and
> > future-proofing.
> >
> > I understand that implementation feasibility needs to be assessed, b=
ut
> > if possible, this could be a more satisfying solution than mandatory
> > parentheses.  Thanks to the team for highlighting this issue -- it's
> > sparked a creative way to enhance the feature.
> >
> > Would love to hear thoughts on this.
> >
> > Best,
> > hakre
>=20
> That's an interesting idea, but I don't think it solves the problem.
>=20
> It would make the syntax for pipes-in-closures nicer, yes.  However:
>=20
> 1. Ideally, I'm hoping such a pipe-in-closure is replaced with a Compo=
sition operator soon enough (https://wiki.php.net/rfc/function-compositi=
on), so that wouldn't even be necessary.
> 2. The main problem is not when a pipe is inside a closure, but when a=
 closure is inside a pipe, which is likely the far more common case.
>=20
> $input
>      |> fn($x) =3D> array_map(strtoupper(...), $x)
>      |> fn($x) =3D> array_filter($x, fn($v) =3D> $v !=3D 'O')
> ;
>=20
> The problem is this gets interpreted "backwards", with the first closu=
re wrapping around second, rather than being a sibling of it in a pipe c=
hain.  A short-hand for pipes-in-closures wouldn't address this issue, w=
hich is the more pressing concern.
>=20
> The annoying extra parens there would also be resolved using PFA, whic=
h side steps the arrow function in the common case.  As the issue is the=
 syntactic parsing of arrow functions, not having arrow functions would =
also resolve the issue.  (As would using higher-order functions instead,=
 which frankly is what I am likely to do 90% of the time myself.)
>=20
> --Larry Garfield
>=20

I think the point Hans was making is that the fn($x) becomes implicit so=
 you don't even need it, so your example would be something like this in=
 this case:

$input |> fn($x) =3D> |> array_map(strtoupper(...), $x) |> array_filter(=
$x, fn($v) =3D> $v !=3D 'O');



=E2=80=94 Rob
--dc22a09666954d77af335b521250769c
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Thu, Aug =
21, 2025, at 15:53, Larry Garfield wrote:</div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><div>On Thu, Aug 21, 2025, at 4:07 AM, Hans Krente=
l wrote:</div><div>&gt; On Thursday 14 August 2025 21:30:08 (+02:00), La=
rry Garfield wrote:</div><div>&gt;</div><div>&gt;&gt; Does anyone have a=
 better solution to suggest?</div><div>&gt;</div><div>&gt; I've been fol=
lowing the discussion on the pipe/short-closure precedence</div><div>&gt=
; issue, and while the parentheses-based solution works, it does lead to=
</div><div>&gt; syntactic noise that undermines the readability benefits=
 of pipes.</div><div>&gt;</div><div>&gt; I'd like to suggest an alternat=
ive that turns this problem into an</div><div>&gt; opportunity for a mor=
e elegant syntax.</div><div>&gt;</div><div>&gt; Inspired by prior art li=
ke Haskell's `do` notation, I propose what I</div><div>&gt; call "short =
closure canned pipes." The idea is to leverage the greedy</div><div>&gt;=
 nature of short closures to define a clean, linear pipe chain within a<=
/div><div>&gt; closure context.&nbsp; Instead of fighting the precedence=
, we embrace it to</div><div>&gt; create a new form:</div><div>&gt;</div=
><div>&gt;</div><div>&gt; Current problematic example (even with parenth=
eses):</div><div>&gt; --------------------------------------------------=
--</div><div>&gt;</div><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp; fn($x) =3D&gt; =
($x</div><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp; |&gt; (fn($x) =3D&gt; array_m=
ap(strtoupper(...), $x))</div><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp; |&gt; (f=
n($x) =3D&gt; array_filter($x, fn($v) =3D&gt; $v !=3D 'O'))</div><div>&g=
t;&nbsp;&nbsp;&nbsp;&nbsp; );</div><div>&gt;</div><div>&gt; Proposed "ca=
nned pipes" syntax:</div><div>&gt; -------------------------------</div>=
<div>&gt;</div><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp; fn($x) =3D&gt;</div><di=
v>&gt;&nbsp;&nbsp;&nbsp;&nbsp; |&gt; array_map(strtoupper(...), $x)</div=
><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp; |&gt; array_filter($x, fn($v) =3D&gt;=
 $v !=3D 'O')</div><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp; ;</div><div>&gt;</d=
iv><div>&gt;</div><div>&gt; This syntax:</div><div>&gt;</div><div>&gt; *=
 Resolves the ambiguity: The `fn($x) =3D&gt;` explicitly "cans" the valu=
e</div><div>&gt;&nbsp;&nbsp; for the entire pipe chain, making the prece=
dence clear without</div><div>&gt;&nbsp;&nbsp; parentheses.</div><div>&g=
t;&nbsp;&nbsp;</div><div>&gt; * Reduces boilerplate: It eliminates the r=
epetition of `fn($x) =3D&gt;` and</div><div>&gt;&nbsp;&nbsp; nested pare=
ntheses, making the code more readable and maintainable.</div><div>&gt;&=
nbsp;&nbsp;</div><div>&gt; * Aligns with intent: It reads as a simple se=
quence of transformations,</div><div>&gt;&nbsp;&nbsp; which is the core =
goal of the pipe operator.</div><div>&gt;&nbsp;&nbsp;</div><div>&gt; Thi=
s approach effectively provides syntactic sugar for the common case</div=
><div>&gt; of processing a value through a pipe chain within a closure. =
It turns</div><div>&gt; the late-discovered defect into a win for develo=
per ergonomics and</div><div>&gt; future-proofing.</div><div>&gt;</div><=
div>&gt; I understand that implementation feasibility needs to be assess=
ed, but</div><div>&gt; if possible, this could be a more satisfying solu=
tion than mandatory</div><div>&gt; parentheses.&nbsp; Thanks to the team=
 for highlighting this issue -- it's</div><div>&gt; sparked a creative w=
ay to enhance the feature.</div><div>&gt;</div><div>&gt; Would love to h=
ear thoughts on this.</div><div>&gt;</div><div>&gt; Best,</div><div>&gt;=
 hakre</div><div><br></div><div>That's an interesting idea, but I don't =
think it solves the problem.</div><div><br></div><div>It would make the =
syntax for pipes-in-closures nicer, yes.&nbsp; However:</div><div><br></=
div><div>1. Ideally, I'm hoping such a pipe-in-closure is replaced with =
a Composition operator soon enough (<a href=3D"https://wiki.php.net/rfc/=
function-composition">https://wiki.php.net/rfc/function-composition</a>)=
, so that wouldn't even be necessary.</div><div>2. The main problem is n=
ot when a pipe is inside a closure, but when a closure is inside a pipe,=
 which is likely the far more common case.</div><div><br></div><div>$inp=
ut</div><div>&nbsp;&nbsp;&nbsp;&nbsp; |&gt; fn($x) =3D&gt; array_map(str=
toupper(...), $x)</div><div>&nbsp;&nbsp;&nbsp;&nbsp; |&gt; fn($x) =3D&gt=
; array_filter($x, fn($v) =3D&gt; $v !=3D 'O')</div><div>;</div><div><br=
></div><div>The problem is this gets interpreted "backwards", with the f=
irst closure wrapping around second, rather than being a sibling of it i=
n a pipe chain.&nbsp; A short-hand for pipes-in-closures wouldn't addres=
s this issue, which is the more pressing concern.</div><div><br></div><d=
iv>The annoying extra parens there would also be resolved using PFA, whi=
ch side steps the arrow function in the common case.&nbsp; As the issue =
is the syntactic parsing of arrow functions, not having arrow functions =
would also resolve the issue.&nbsp; (As would using higher-order functio=
ns instead, which frankly is what I am likely to do 90% of the time myse=
lf.)</div><div><br></div><div>--Larry Garfield</div><div><br></div></blo=
ckquote><div><br></div><div>I think the point Hans was making is that th=
e fn($x) becomes implicit so you don't even need it, so your example wou=
ld be something like this in this case:<br></div><div><br></div><div>$in=
put |&gt; fn($x) =3D&gt; |&gt; array_map(strtoupper(...), $x) |&gt; arra=
y_filter($x, fn($v) =3D&gt; $v !=3D 'O');</div><div><br></div><div><br><=
/div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body><=
/html>
--dc22a09666954d77af335b521250769c--