Yeah very good points! As long as you designed the functions to be used for the pipeline, then we’re fine. However, you might force the programmer to write unnecessary functions (almost boil-plate code of switching arguments around) based on already existing optimized functions scattered everywhere so they fit with the pipeline unless you do them on the fly (lambda function) which has its drawbacks as well. 1 -> add(2) -> ((y, x) => pow(x, y))(3) is way less readable than 1 -> add(2) -> pow(3, _) The above is just an example. It could be written better using operators 3 ** (1 + 2) Abdulla Sent from my iPhone
On 2 Dec 2021, at 12:42 PM, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
Abdulla Al Kathiri writes:
Thanks for the clarification. Yeah I agree it will look ugly if we use it not as a first argument many times in a row but what if there is one or two functions in the middle that they are not playing along and don’t have teamwork ethics,
Function definitions or lambdas are cheap.
1 -> add(2) -> pow(3, _) equivalent to 1 -> add(_, 2) -> pow(3, _). _ is where your output goes into. _ as a first argument can be omitted.
def rpow(x, y): return pow(y, x) 1 -> add(2) -> rpow(3)
But in many cases it won't be necessary because you will be defining functions for the pipeline, rather than fitting the pipeline to preexisting functions.