Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126961
Precedence: bulk
MIME-Version: 1.0
References: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
In-Reply-To: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
Date: Thu, 27 Mar 2025 15:30:26 +0100
Message-ID: <CAPyj-LBvmUfhakS+Z9wDYQ-J7Bypk9bbTupPqv-kvfPp8r_qnA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Larry

Sorry for the late response.

On Fri, Feb 7, 2025 at 5:58=E2=80=AFAM Larry Garfield <larry@garfieldtech.c=
om> wrote:
>
> https://wiki.php.net/rfc/pipe-operator-v3

We have already discussed this topic extensively off-list, so let me
bring the list up-to-date.

The current pipes proposal is elegantly simple. This has many upsides,
but it comes with an obvious limitation:
It only works well when the called function takes only a single argument.

$sourceCode |> lexer(...) |> parser(...) |> compiler(...) |> vm(...)

Such code is nice, but is also quite niche. I have argued off-list
that the predominant use-case for pipes are arrays and iterators
(including strings immediately split into chunks), and it seems most
agree. However, most array/iterator functions (e.g. filter, map,
reduce, first, all, etc.) don't fall into the one-parameter category.

A slightly simplified example from the RFC:

$result =3D "Hello World"
    |> str_split(...)
    |> fn($x) =3D> array_map(strtoupper(...), $x)
    |> fn($x) =3D> array_filter($x, fn($v) =3D> $v !=3D 'O');

IMO, this is harder to understand than the alternative of using
multiple statements with a temporary variable.

$tmp =3D "Hello World";
$tmp =3D str_split($tmp);
$tmp =3D array_map(strtoupper(...), $tmp);
$result =3D array_filter($tmp, fn($v) =3D> $v !=3D 'O');

The RFC has a solution for this: Partial function application [1].

$result =3D "Hello World"
    |> str_split(...)
    |> array_map(strtoupper(...), ?)
    |> array_filter(?, fn($v) =3D> $v !=3D 'O');

This still causes more cognitive overhead than it should, at least to me.

* The placement of ? is hard to detect, especially when it's not the
first argument.
* The user now has to think about immediately-invoked closures that
exist solely for argument-reordering. The closure can be elided
through the optimizer, but we cannot elide the additional cognitive
overhead in the user.
* The implementation of ? is significantly more complex than that of
pipes, making the supposed simplicity of pipes somewhat misleading.

If my assumption is correct that the primary use-case for pipes are
arrays, it might be worth investigating the possibility of introducing
a new iterator API, which has been proposed before [2], optimized for
pipes. Specifically, this API would ensure consistent placement of the
subject, i.e. the iterable in this case, as the first argument. Pipes
would no longer have the form of expr |> expr, where the
right-hand-side is expected to return a callable. Instead, it would
have the form of expr |> function_call, where the left-hand-side is
implicitly inserted as the first parameter of the call.

namespace Iter {
    function map(iterable $iterable, \Closure $callback): \Iterator;
    function filter(iterable $iterable, \Closure $callback): \Iterator;
}

namespace {
    use function Iter\{map, filter};

    $result =3D "Hello World"
        |> str_split()
        |> map(strtoupper(...))
        |> filter(fn($v) =3D> $v !=3D 'O');
}

This is the same approach taken by Elixir [3]. It has a few benefits:

* We don't need to think about closures that are immediately invoked,
because there are none. The code is exactly the same as if you had
written it through nested function calls. This simplifies things
significantly for both the engine and the user.
* It closely resembles code that would be written in an
object-oriented manner, making it more familiar.
* It is the shortest and most readable of all the proposed options.

As with everything, there are downsides.

* It only works well for subject-first APIs. There are not an
insignificant number of existing functions that do not follow this
convention (e.g. explode(), preg_match(), etc.). That said, explode('
', $s) |> filter($c1) |> map($c2) still composes well, given explode()
is usually first first in the chain, while preg_match() is rarely
chained at all.
* People have voiced concerns for potential confusion regarding the
right-hand-side. It may not be any arbitrary expression, but is
restricted to a function call. Hence, `$param |> $myClosure` is not
valid code, requiring additional braces: `$param |> $myClosure()`.
This approach resembles the -> operator, where at least conceptually,
the left-hand-side is implicitly passed as a $this parameter. However,
the spaces between |> do not signal this fact as well, making it look
like the right-hand-side is evaluated separately. Potentially, a
different symbol might work better.

Internal reactions to this idea were mixed, so I'm interested to hear
what the community thinks about it.

Ilija

[1] https://wiki.php.net/rfc/partial_function_application
[2] https://externals.io/message/118896
[3] https://elixirschool.com/en/lessons/basics/pipe_operator