Why use function currying

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? Ask Question. Asked 8 years, 9 months ago. Active 6 years, 7 months ago.

Viewed 83k times. Improve this question. Mad Scientist. Mad Scientist Mad Scientist 2, 2 2 gold badges 15 15 silver badges 18 18 bronze badges.

Currying alone is essentially useless, but having all functions curried by default makes a lot of other features much nicer to use. It's hard to appreciate this until you've actually used a functional language for a while. Something that was mentioned in passing by delnan in a comment on JoelEtherton's answer, but that I thought I would mention explicitly, is that at least in Haskell you can partially apply with not only functions but also type constructors -- this can be quite handy; this might be something to think on.

All have given examples of Haskell. One may wonder currying is useful only in Haskell. ManojR All have not given examples in Haskell. The question generated a fairly interesting discussion on Reddit. Show 3 more comments. Active Oldest Votes. Improve this answer. Boris Boris 1, 1 1 gold badge 7 7 silver badges 8 8 bronze badges. It's worth noting that, because of this, the argument order used for functions in Haskell is often based on how likely partial application is, which in turn makes the benefits described above apply ha, ha in more situations.

Currying by default thus ends up being even more beneficial than is apparent from specific examples like the ones here. MateenUlhaq It is a continuation of the previous sentence, where I suppose that we want to get a value based on a key, and we have two ways of doing that. The sentence enumerates those two ways. It might help to look at the code immediately following the sentence. Add a comment. Even with a minimal lambda syntax, it's something of a win; compare: map add 1 [ This becomes especially important once you generalize map to types other than list.

This is actually a very useful distinction that I wish other languages would have because it makes it very natural to write something like: map f [ 1,2,3 , 4,5,6 , 7, 8, 9 ] You couldn't easily do this with languages that have the idea of multiple arguments baked right in!

Tikhon Jelvis Tikhon Jelvis 5, 1 1 gold badge 22 22 silver badges 20 20 bronze badges. Giorgio: Yeah. I know some Haskell and I am learning SML right now, so it is interesting to see differences and similarities between the two languages. Great answer, and if you're still not convinced just think about Unix pipelines which are similar to lambda streams — Sridhar Sarnobat. The "practical" answer is not relevant much because the verbosity is usually avoided by partial application , not currying.

And I'd argue here the syntax of lambda abstraction despite the type declaration is uglier than that at least in Scheme as it needs more built-in special syntactic rules to parse it correctly, which bloats the language spec without any gain about semantic properties.

Alex R Alex R 1 1 silver badge 4 4 bronze badges. While the motivation here is theoretical, I think simplicity is almost always a practical advantage as well. Not worrying about multi-argument functions makes my life easier when I program, just as it would if I was working with semantics.

TikhonJelvis When you're programming, though, currying gives you other things to worry about, like the compiler not catching the fact that you passed too few arguments to a function, or even getting a bad error message in that case; when you don't use currying, the error is much more apparent.

I've never had problems like that: GHC, at the very least, is very good in that regard. The compiler always catches that sort of issue, and has good error messages for this error as well. I can't agree that the error messages qualify as good. 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.

We can order one dish and a dessert. We have four different components to our order, the customer's id, its table number, the dish and the dessert. Nothing fancy here. Let's curry this with the function we created earlier:.

The first reason to use a technique like currying is that you can separate in your codebase when and where your arguments are specified. You may not have all the arguments necessary to call the sum function right away, or all the order informations to print them out. The client gets in the restaurant, you don't know where she is going to sit yet. The concept of currying is a key part of functional programming. The main aim of functional programming is to favour writing small, well-defined functions.

Currying is the process of converting a function that takes multiple arguments and then converting it into one or more function that takes one argument at a time instead. When I first read about currying, I didn't really see the benefit and struggled to grasp why people used it.

I decided to write this article to prevent people from going through the same confusion. The aim of this post is to be a practical guide as to when you would use currying. Let us start with a very basic comparison of what curried code looks like. This is a simple javascript function that is not curried. It takes two parameters and adds them together:.

If that doesn't impress you, then welcome to my world. The benefit of currying isn't really in the function definition, the benefit of currying comes in the area of code where that function is called. In the normal function definition code, you would call the function like this:.