Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128553
Content-Type: text/plain; charset=utf-8
Message-ID: <1756139234402.3228698536.3461950202@yahoo.de>
To: internals@lists.php.net
Cc: rob@bottled.codes
Subject: Re: [PHP-DEV] Pipe precedence challenges
Date: Mon, 25 Aug 2025 16:31:57 +0000
In-Reply-To: <a5d120d2-0c5b-4391-ab26-2e3e0fade66e@app.fastmail.com>
References: <a5d120d2-0c5b-4391-ab26-2e3e0fade66e@app.fastmail.com>
User-Agent: Vivaldi Mail/7.5.3735.64
Content-Transfer-Encoding: quoted-printable
Precedence: list
MIME-Version: 1.0
From: hanskrentel@yahoo.de (Hans Krentel)




On Friday 22 August 2025 11:40:46 (+02:00), Rob Landers wrote:
> 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');

Hi Rob, thanks for jumping in and thinking about this! I really
appreciate it.

You've correctly grasped the goal: reducing the `fn($x) =3D>` boilerplate.
However, the syntax I had in mind is a bit different and is designed
specifically to avoid the parsing ambiguity altogether by making the
structure unambiguous.

The proposal is for a self-contained "canned pipe" where the `fn($x) =3D>`
applies to the entire subsequent pipeline, like this:

    // 'Canned pipe' creating a reusable function
    $processor =3D fn($x) =3D>
        |> array_map(strtoupper(...), $x)
        |> array_filter($x, fn($v) =3D> $v !=3D 'O');
   =20
    // This $processor can then be used anywhere, including in a pipe:
    $result =3D $input |> $processor;


The key difference is that the `|>` lines are not *inside* the closure's
expression body. Instead, they *are* the body, in a dedicated gram-
matical form. This is why it avoids the greedy parsing issue=E2=80=94the =
parser
would see `fn($x) =3D> |>` as a single unit defining a pipeline, not a
closure that contains pipe expressions.

Your example mixes the outer pipe `$input |>` with the inner pipe=20
`|> array_map(...)`, which is a really interesting idea for a more
advanced integration!  However, that likely reintroduces the very pre-
cedence conflict we're trying to solve, as the parser would have to un-
tangle which `|>` belongs to which level.

By keeping the proposal focused on this self-contained form, we get a
clean win for the "pipes-in-closure" case without adding new complexity
to the grammar for parsing nested pipes. It's very much inspired by how
Haskell's `do` notation provides a clean syntax for a sequence of
actions within a context.

Thanks again for the feedback=E2=80=94it helped me clarify the concept!

Best,
Hans