Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127034
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 03 Apr 2025 12:06:29 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <7e2a3dea-aaaf-4427-b1b2-32c568af8b77@app.fastmail.com>
In-Reply-To: <92b7f1ea-900b-4438-bed7-3fd766bb2d61@rwec.co.uk>
References: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
 <CAPyj-LBvmUfhakS+Z9wDYQ-J7Bypk9bbTupPqv-kvfPp8r_qnA@mail.gmail.com>
 <5efa2f02-dd1d-4d59-ae07-c75f193b4096@app.fastmail.com>
 <92b7f1ea-900b-4438-bed7-3fd766bb2d61@rwec.co.uk>
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Apr 3, 2025, at 6:58 AM, Rowan Tommins [IMSoP] wrote:
> On 03/04/2025 08:22, Larry Garfield wrote:
>> However, it also received significant pushback off-list from folks wh=
o felt it was too much magic.  I don't want to torpedo pipes on over-rea=
ching.  But without feedback from other voters, I don't know if this is =
over-reaching.  Is it?  Please, someone tell me which approach you'd be =
more willing to vote for. :-)
>
>
> At first, I thought Ilija's example looked pretty neat, but having=20
> thought about it a bit more, I think the "first-arg" approach makes a=20
> handful of cases nicer at the cost of a lot of magic, and making other=20
> cases worse.
>
>
> The right-hand side is magic in two ways:
>
> 1) it looks like an expression, but actually has to be a syntactic=20
> function call for the engine to inject an argument into
>
> 2) it looks like it's calling a function with the wrong arguments
>
> If we have a special case where the right-hand side *is* an expression=
,=20
> evaluated as a single-argument callable/Closure, that's even more scop=
e=20
> for confusion. [cf my thoughts in the async thread about keeping the=20
> right-hand side of "spawn" consistent]
>
>
> The cases it makes nicer are where you are chaining existing functions=20
> with the placeholder as first (but not only) parameter. If you want to=20
> pipe into a non-first parameter, you have a few options:
>
> a) Write a new function or explicit wrapper - equally possible with=20
> either option
>
> // for first-arg chaining:
> function swapped_explode(string $string, string $separator): string {=20
> return explode($separator, $string); }
> $someChain |> swapped_explode(':');
>
> // for only-arg chaining:
> function curried_explode(string $separator, string $string): callable =
{=20
> return fn(string $string) =3D> explode($separator, $string); }
> $someChain |> curried_explode(':');
>
> b) Use an immediate closure as the wrapper - only-arg chaining seems b=
etter
>
> // first-arg chaining
> $someChain |> fn($string) =3D> explode(':', $string)();
>
> // first-arg chaining with special case syntax for closures
> $someChain |> ( fn($string) =3D> explode(':', $string) );
>
> // for only-arg chaining:
> $someChain |> fn($string) =3D> explode(':', $string);
>
> c) Use a new partial application syntax - same problem as immediate cl=
osure
>
> // for first-arg chaining
> $someChain |> explode(':', ?)();
>
> // or with overloaded syntax
> $someChain |> ( explode(':', ?) );
>
> // for only-arg chaining
> $someChain |> explode(':', ?);
>
>
> It's also quite easy to write a helper for the special-case of=20
> "partially apply all except the first argument":
>
> function partial_first(callable $fn, mixed ...$fixedArgs): callable {
>  =C2=A0=C2=A0=C2=A0 return fn(mixed $firstArg) =3D> $fn($firstArg, ...=
$fixedArgs);
> }
>
> // first-arg chaining
> $someChain |> array_filter(fn($v, $k) =3D> $k =3D=3D=3D $v, ARRAY_FILT=
ER_USE_BOTH);
>
> // native partial application
> $someChain |> array_filter(?, fn($v, $k) =3D> $k =3D=3D=3D $v,=20
> ARRAY_FILTER_USE_BOTH);
>
> // workaround
> $someChain |> partial_first(array_filter(...), fn($v, $k) =3D> $k =3D=3D=
=3D $v,=20
> ARRAY_FILTER_USE_BOTH));

Writing higher order functions to simulate first-arg is indeed quite str=
aightforward.  The RFC has some simple examples, and I've written a whol=
e bunch of more robust ones here:

https://github.com/Crell/fp/blob/master/src/array.php
https://github.com/Crell/fp/blob/master/src/string.php

The issue is performance.  With foo(...), foo(?, 'bar'), or implicit fir=
st-arg, it's fairly straightforward to compile it down to a normal funct=
ion call so there's no runtime cost.  If you have an expression that pro=
duces a callable that gets used, that cannot be optimized away.

So we could get this resulting syntax with either higher order user-spac=
e functions or with auto-first-arg:

$foo=20
    |> map($fn1)=20
    |> filter($fn2)=20
    |> implode(',');

However, if map() is a higher order function that returns a unary callab=
le, there are two function invocations involved.  If it's custom syntax =
that turns into map($foo, $fn1), then it's only one function invocation.

So if we expect higher order functions to be common (and I would probabl=
y mainly use them myself), then it would be wise to figure out some way =
to make them more efficient.  Auto-first-arg is one way.  "Suck it up an=
d use PFA with the ?" is another way that would work, but be less ergono=
mic.  I'm not sure of other options off hand.

--Larry Garfield