On Fri, Feb 7, 2025, at 22:04, Larry Garfield wrote:
> 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
>
Put another way, what is the order of operations for this new operator?
For example, what is the output of
$x ? $y |> strlen(…) : $z
$x + $y |> sqrt(…) . EOL
Etc.
I noticed this seems to be missing from the RFC. As a new operator, I think it should be important
to specify that.
— Rob