Merging a few replies together here, since they overlap. Also reordering a few of Tim's
comments...
On Fri, Feb 7, 2025, at 7:32 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-02-07 05:57, schrieb Larry Garfield:
>> It is now back with a better implementation (many thanks to Ilija for
>> his help and guidance in that), and it's nowhere close to freeze, so
>> here we go again:
>>
>> https://wiki.php.net/rfc/pipe-operator-v3
>
> There's some editorial issues:
>
> 1. Status: Draft needs to be updated.
> 2. The RFC needs to be added to the overview page.
> 3. List formatting issues in “Future Scope” and “Patches and Tests”.
>
> Would also help having a closed voting widget in the “Proposed Voting
> Choices” section to be crystal clear on what is being voted on (see
> below the next quote).
I split pipes off from the Composition RFC late last night right before posting; I guess I missed a
few things while doing so. :-/ Most notably, the Compose section is now removed from pipes, as it
is not in scope for this RFC. (As noted, it's going to be more work so has its own RFC.)
Sorry for the confusion. I think it should all be handled now.
> 5. The “References” (as in reference variables) section would do well
> with an example of what doesn't work.
Example block added.
> 9. In the “Why in the engine?” section: The RFC makes a claim about
> performance.
>
> Do you have any numbers?
Not currently. The statements here are based on simply counting the number of function calls
necessary, and PHP function calls are sadly non-cheap. In previous benchmarks of my own libraries
using my Crell/fp library, I did find that the number of function calls involved in some tight pipe
operations was both a performance and debugging concern, but I don't have any hard numbers
laying about at present to share.
If you think that's critical, please advise on how to best get meaningful numbers here.
Regarding the equivalency of pipes:
Tim Düsterhus wrote:
> 4. “That is, the following two code fragments are also exactly
> equivalent:”.
>
> I do not believe this is true (specifically referring to the “exactly”
> word in there), since the second code fragment does not have the short
> closures, which likely results in an observable behavioral difference
> when throwing Exceptions (in the stack trace) and also for debuggers. Or
> is the implementation able to elide the the extra closure? (Of course
> there's also the difference between the temporary variable existing,
> with would be observable for get_defined_vars() and possibly
> destructors / object lifetimes).
Thomas Hruska wrote:
> The repeated assignment to $temp in your second example is _not_
> actually equal to the earlier example as you claim. The second example
> with all of the $temp variables should, IMO, just be:
>
> $temp = "Hello World";
> $result = array_filter(array_map('strtoupper',
> str_split(htmlentities($temp))), fn($v) { return $v != 'O'; });
Juris Evertovskis wrote:
> 3. Does the implementation actually turn 1 |> f(...) |> g(...) into
> $π = f(1); g($π)? Is g(f(1)) not performanter? Or is the engine
> clever enough with the var reuse anyways?
There's some subtlety here on these points. The v2 RFC used the lexer to mutate $a |> $b
|> $c into the same AST as $c($b($a)), which would then compile as though that had been written
in the first place. However, that made addressing references much harder, and there's an
important caveat around order of operations. (See below.) The v3 RFC instead uses a compile
function to take the AST of $a |> $b |> $c and produce opcodes that are effectively equivalent
to $t = $b($a); $t = $c($t); I have not compared to see if they are the precise same opcodes, but
they net effect is the same. So "effectively equivalent" may be a more accurate
statement.
In particular, Tim is correct that, technically, the short lambdas would be used as-is, so
you'd end up with the equivalent of:
$temp = (fn($x) => array_map(strtoupper(...), $x))($temp);
I'm not sure if there's a good way to automatically unwrap the closure there. (If someone
knows of one, please share; I'm fine with including it.) However, the intent is that it would
be largely unnecessary in the future with a revised PFA implementation, which would obviate the need
for the explicit wrapping closure. You would instead write
$a |> array_map(strtoupper(...), ?);
Alternatively, one can use higher order user-space functions already. In trivial cases:
function amap(Closure $fn): Closure {
return fn(array $x) => array_map($fn, $x);
}
$a |> amap(strtoupper(...));
Which I am already using in Crell/fp and several libraries that leverage it, and it's quite
ergonomic.
There's a whole bunch of such simple higher order functions here:
https://github.com/Crell/fp/blob/master/src/array.php
https://github.com/Crell/fp/blob/master/src/string.php
Which leads to the subtle difference between that and the v2 implementation, and why Thomas'
statement is incorrect. If the expression on the right side that produces a Closure has side
effects (output, DB interaction, etc.), then the order in which those side effects happen may change
with the different restructuring. With all pure functions, that won't make a practical
difference, and normally one should be using pure functions, but that's not something PHP can
enforce.
I don't think there would be an appreciable performance difference between the two compiled
versions, either way, but using the temp-var approach makes dealing with references easier, so
it's what we're doing.
Juris Evertovskis wrote:
> 1. Do you think it would be hard to add some shorthand for `|>
> $condition ? $callable : fn($😐) => $😐`?
I'm not sure I follow here. Assuming you're talking about "branch in the next
step", the standard way of doing that is with a higher order user-space function. Something
like:
function cond(bool $cond, Closure $t, Closure $f): Closure {
return $cond ? $t : $f;
}
$a |> cond($config > 10, bigval(...), smallval(...)) |> otherstuff(...);
I think it's premature to try and bake that logic into the language, especially when I
don't know of any other function-composition-having language that does so at the language level
rather than the standard library level. (There are a number of fun operations people build into
pipelines, but they are all generally done in user space.)
--Larry Garfield