The current JS argument order is a mess too because you'd ideally want your collection last so you can partially apply the parts you'd normally apply and compose transformations for that collection, but most function arguments aren't in this order. Elixir is the 'weird' language piping the first argument instead of the last, so I guess that is a solution, but it doesn't fit the 'normal' compositional style from ML-family languages. This might be a requirement for languages with variadic functions.
The spec points to the `%` placeholder-y thing from Hack which shows how weird piping gets in an uncurried language like JavaScript. I think these issues illustrate how nontrivial adding piping would actually be in JavaScript.
Currying is the obvious, simplest solution because it's always one parameter in and only one thing is returned (often a function awaiting one new argument). But this would require massive fundamental changes to the builtins probably requiring something like "use currying" to tell the user agent to flip the argument order and curry all the functions. I'd be pretty into this though.
> But this would require massive fundamental changes to the builtins probably requiring something like "use currying" to tell the user agent to flip the argument order and curry all the functions. I'd be pretty into this though.
Could you just clone them and expose versions with swapped arguments under a different namespace?
I'm familiar with currying. In the real world, unless you have a certain type of parse transform, that's not the same as composition, due to lambda overheads.
Currying is the answer to your question, regardless of any possible real world overhead, which can be optimized out. This is a proposal to modify the language we're discussing, so I'm assuming they can do the latter as part of the proposal if that were necessary.
Given
f :: a -> b
g :: (b, c) -> d
h = uncurry ((curry g) . f)
It isn't just "real world overhead", it's the ambiguities or pessimal behaviors you encounter if you try to bodge currying on to a language that wasn't designed for it.
For currying, for instance, you need to know exactly when to execute the function and return the results, vs. when to return another curried function expecting more results. This is messy in the face of optional arguments, and in Javascript, all arguments are always optional.
"But I can solve that with more syntax!"
Perhaps so. But then you have the problem, what if you want to take advantage of optional arguments to add another argument to a widely used function? Do some of your invocations of the function that previously considered the function "done" now return functions expecting one more argument? Probably, unless your syntax forced explicit specifications of when to curry. Dynamic languages kinda have that sort of problem all over the place anyhow, but this would be a new manifestation for people to deal with. That's getting ugly and complicated.
You're probably better off just using the lambdas the language already has rather than blundering your way through this mindfield. I don't think I can name a single case of a language solving this problem after the fact; by all means upgrade my knowledge by naming one that did (no sarcasm, I'd be interested in seeing it).
