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) => |> array_map(strtoupper(...), $x) |> array_filter
> ($x, fn($v) => $v != '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) =>` 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) =>`
applies to the entire subsequent pipeline, like this:
// 'Canned pipe' creating a reusable function
$processor = fn($x) =>
|> array_map(strtoupper(...), $x)
|> array_filter($x, fn($v) => $v != 'O');
// This $processor can then be used anywhere, including in a pipe:
$result = $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—the parser
would see `fn($x) => |>` 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
`|> 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—it helped me clarify the concept!
Best,
Hans
