Yes, and many imperative languages allow you to use, in an idiomatic manner, a functional style that avoids mutable state, even though these languages aren't designed around the functional paradigm, and don't require you to adhere purely, in the colloquial sense that means "strictly" or "completely" but has fewer letters, to it. And the reason for this is that people have taken ideas from languages that were designed to be functional rather than imperative.
If you want to bring up map and reduce, what's their genealogy? Did the imperative world get the idea from ALGOL? Maybe they did, but I'd be surprised.
It still isn't great. To avoid stepping outside the paradigm, you have to be willing to curry every function that needs multiple parameters. And I don't know what that recursion is doing there - presumably I don't know what I'm talking about again, but it seems to me that the entire body of `xToYPower` could be replaced with `return y => x y`.
Genealogy is that it's a pattern from the functional world. It's usually unused in procedural languages because they have special syntax for it like the for loop. However there is no restriction to implement map using a for loop. Therefore it is not part of the paradigm similar to how using functions in a procedural language does not mean you are doing functional programming from a stylistic perspective.
>To avoid stepping outside the paradigm, you have to be willing to curry every function that needs multiple parameters
For compose yes you are correct, it has to be done.
>And I don't know what that recursion is doing there
The recursion is doing x^y. That is the meaning of the function name.
2^3 = 8
3^2 = 9
xToY(2)(3) = 8
xToY(3)(2) = 9
x y with a space inbetween looks like a syntax error. I don't think it will even run.