Pipeline Champions
2025-08-06
plaintext logs
prev next
source on github
02:57
<Ashley Claymore>
The fact we advanced Iterator helpers, which also depends on ad hoc arrows, weakens that argument, IMO.

But iterator helpers work on the receiver. So there is only one closure.

i.filter(f) vs filter(f)(i)

02:58
<Ashley Claymore>
Engines aren't saying we can't have any APIs that take a callback
03:05
<rbuckton>
If PFAs are inlined in the presence of a |>, then the only other place they would have utility are places where you're already using =>.
03:07
<rbuckton>
In which case, ? vs => doesn't really change the math.
03:09
<rbuckton>
If I am doing [1, 2, 3].map(x => add(x, 1)) today, then [1, 2, 3].map(add(?, 1)) saves a few characters but is functionally similar.
03:12
<rbuckton>

There are more than a few interesting cases, but most boil down to something you could do with either => or .bind() without some of the caveats. For example, you could do

const MyLogger = Logger("output.log", ...);
...
const logger = new MyLogger(Severity.Info);
logger.log("hi");

You can't new an arrow, so its functionally similar to .bind, except that you can put placeholders anywhere in the argument list.

18:56
<Justin Ridgewell>
I think having PFA would be neat, and I do like that it meshes nicely with pipeline. But I'm more aligned with Chrome's performance concerns, and I think it encourages functions-returning-closures style of programing that will be a huge bottleneck in applications.
18:56
<Justin Ridgewell>
If people only did foo |> bar(?, 1) with the PFA as the literal RHS of the pipe, I think it wouldn't be a concern.
18:57
<Justin Ridgewell>
But it's going to turn into foo |> filter(bar) in a lot of code, and that's not easy to statically elminate
18:59
<Justin Ridgewell>
Hack style foo | filter(bar)(%%) isn't immune to it, but it feels so foreign to have fn(a)(b) that I think it'd discourage the bad patterns, or at least subtly push people to write filter(bar, %%)
19:09
<TabAtkins>
Yup, exactly
20:36
<jschoi>
But it's going to turn into foo |> filter(bar) in a lot of code, and that's not easy to statically elminate

I recall that this was the explicit intent of RxJS and why they had been excited for the pipe operator before Hack pipes.

RxJS’s design was to have named HoFs return one-off closures that then would be used with the pipe operator, just like s |> filter(x). Backlash to Hack pipes came precisely because this precise approach was no longer tacit. Same went for Ramda, etc.

They wanted complete tacitness, and tacitness for n-ary functions necessarily means HoFs returning new closures.

For many of these people, even PFA syntax would not be tacit FP either. After all, it marks the argument(s) to fill…