On 03/04/2025 18:06, Larry Garfield wrote:
So if we expect higher order functions to be common (and I would probably
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.
From this angle, auto-first-arg is a very limited compiler optimisation
for partial application.
With auto-first-arg, you have a parser rule that matches this:
$foo |> bar($baz);
and results in the same AST/opcodes as this:
bar($foo, $baz);
With PFA and one-arg-callable pipes, you could add a parser rule that
matches this, with the same output:
$foo |> bar(?, $baz);
But you'd also be able to do this:
$baz |> bar($foo, ?);
And maybe the compiler could optimise that case too.
Neither helps with the performance of higher order functions which are
doing more than partial application, like map and filter themselves. I
understand there's a high cost to context-switching between C and PHP;
presumably if there was an easy solution for that someone would have
done it already.
On 03/04/2025 18:39, Ilija Tovilo wrote:
To me, pipes improve readability when they behave like methods, i.e.
they perform some operation on a subject. This resembles Swift's
protocol extensions or Rust's trait default implementations, except
using a different "method" call operator.
[...]
If we decide not to add an iterator API that works well with
first-arg, then I agree that this is not the right approach. But if we
do, then neither of your examples are problematic.
I guess those two things go together quite well as a mental model: pipes
as a way to implement extension methods, and new functions designed for
use as extension methods.
I think I'd be more welcoming of it if we actually implemented extension
methods instead of pipes, and then the new iterator API was
extension-method-only. It feels less like "one of the arguments is
missing" if that argument is *always* expressed as the left-hand side of
an arrow or some sort.
--
Rowan Tommins
[IMSoP]
