Why currying

If not, you owe it to yourself and your colleagues to consider it. What is currying, and why is it so damn tasty? To my mind, the two main ones are: Little pieces can be configured and reused with ease, without clutter; Functions are used throughout. Functions through and through Another advantage of this approach is that it encourages the creation of functions; rather than of methods.

You can never provide more than 1 argument, it's one or zero. Finally, Closure is the process of capturing a function and data together as a single unit. A function closure can take 0 to infinite number of arguments, but it's also aware of data not passed to it. Meaning that f' can read the value of x that's inside f. Currying, partial application and closures are all somewhat similar in that they decompose a function into more parts. Currying decomposes a function of multiple arguments into nested functions of single arguments that return functions of single arguments.

There's no point in currying a function of one or less argument, since it doesn't make sense. Partial application decomposes a function of multiple arguments into a function of lesser arguments whose now missing arguments were substituted for the supplied value. Closure decomposes a function into a function and a dataset where variables inside the function that were not passed in can look inside the dataset to find a value to bind against when asked to evaluate.

What's confusing about all these is that they can kind of each be used to implement a subset of the others. So in essence, they're all a bit of an implementation detail.

They all provide similar value in that you don't need to gather all values upfront and in that you can reuse part of the function, since you've decomposed it into discreet units. Currying partial application lets you create a new function out of an existing function by fixing some parameters. It is a special case of lexical closure where the anonymous function is just a trivial wrapper which passes some captured arguments to another function.

We can also do this by using the general syntax for making lexical closures, but partial application provides a simplified syntactic sugar. This is why Lisp programmers, when working in a functional style, sometimes use libraries for partial application. This op macro will make you a function which takes some arguments x y z In many purely functional languages, partial application is ingrained into the syntax so that there is no op operator.

To trigger partial application, you simply call a function with fewer arguments than it requires. Instead of producing an "insufficient number of arguments" error, the result is a function of the remaining arguments. What currying is doing here is transforming a function that takes two agreements into one that only takes one returning a result. Partial evaluation. Say x on the RHS isn't just a regular int, but instead a complex computation that takes a while to complete, for augments, sake, two seconds.

For the above the result of twoSecondsComputation is evaluated every single time. This means it takes 6 seconds for this computation. The twoSecondsComputation only needs to be evaluated once. To up the scale, replace two seconds with 15 minutes, or any hour, then have a map against numbers. Summary : Currying is great when using with other methods for higher level functions as a tool of partial evaluation. Its purpose cannot really be demonstrated by itself.

I made up a function "curry". In this context, I don't care what kind of logger I get or where it comes from. I don't care what the action is or where it comes from. All I care about is processing my input. The builder variable is a function that returns a function that returns a function that takes my input that does my work.

This is a simple useful example and not an object in sight. Currying is an advantage when you don't have all of the arguments for a function. If you happen to be fully evaluating the function, then there's no significant difference.

Currying lets you avoid mentioning not-yet-needed parameters. It is more concise, and doesn't require finding a parameter name that doesn't collide with another variable in scope which is my favorite benefit. For example, when using functions that take functions as arguments, you'll often find yourself in situations where you need functions like "add 3 to input" or "compare input to variable v".

The lambda expressions are twice as long, and have a small amount of busy work related to picking a name besides x if there's already an x in scope. A side benefit of languages based on currying is that, when writing generic code for functions, you don't end up with hundreds of variants based on the number of parameters.

The primary reasoning I can think of and I'm not an expert on this subject by any means begins to show its benefits as the functions move from trivial to non-trivial. In all trivial cases with most concepts of this nature you'll find no real benefit. However, most functional languages make heavy use of the stack in processing operations. Consider PostScript or Lisp as examples of this. By making use of currying, functions can be stacked more effectively and this benefit becomes apparent as the operations grow less and less trivial.

In the curried manner, the command and arguments can be thrown on the stack in order and popped off as needed so they are run in the proper order. That you can partially apply arguments and get back a re-usable function bound to those arguments that you did supply is quite useful and DRY. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams?

Learn more. What is the advantage of currying? In the normal function definition code, you would call the function like this:. In the curried approach, I pass the first variable 10 as the first parameter. The import part is that the function is assigned to a new variable called add After add10 is defined, I can omit passing 10 to add ever again. I can now simply use add10 any time I want to add 10 to something. If you only need to apply add10 once, then currying can be a bit of an overkill.

Another benefit of currying is that your code can become easier to understand. As long as you follow good naming conventions, your code can be written in a more declarative style, e. For a more real-world problem, let's say you have a web form and you have a helper function that creates field inputs for you, like a textbox.

Maybe with this? Let's start with a non-curried example. We want to calculate the sum of the arguments given to a function:. How would we implement currying then? Well, let's try something like this:. Ok, let's break the curried function down a bit. It takes 2 arguments, the first is the function to be called at the end sum in our case , the second is the arity we expect the number of arguments we want before calling sum. This IIFE takes a empty array as a parameter on its first call.

It returns another function with the next argument in our curry sequence as an argument and the function adds it to our collection of arguments.

On the first call, our array is empty so the variable args is equal to [ 1 ]. We check if we have enough arguments to call our original function.

If not, we create another curried function and keep collecting arguments. If we do, we call sum with all of our arguments. Let's imagine we are in a restaurant.