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).
