Re: Pipe precedence challenges

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