Curried functions are probably one of the first new things you come across if you go from an imperative language to a functional language. In purely functional languages, the convention is to define an n-parameter function inductively by staggering the parameters: applying the function to argument #1 returns a function that takes parameters 2..n, which in turn can be applied to argument #2 to return a function that takes parameters 3..n, etc. until all the arguments are given and the result is returned. For instance, we can define a 3-parameter add function that adds three numbers:

add x y z = x + y + z

add = \x -> (\y -> (\z -> x + y + z))

add :: Int -> (Int -> (Int -> Int))


((add 1) 2) 3 

We make the arrow -> right-associative, so we can write Int -> Int -> Int -> Int. Additionally, we make function application left-associative, so we can write add 1 2 3 and minimize our use of parentheses.

I want to argue that when you define functions in this style, although it is nice and elegant, there are also some things that are lost.

There are roughly three different "styles" that programming languages offer for writing multi-parameter function definitions with. Firstly, there is the imperative style which I will call the "parameter list" style. Here, multiple parameters is a baked-in feature of functions. This is the default in imperative languages like Rust:

fn f(p1: P1, p2: P2, p3: P3) -> R { ... } 
f(a1, a2, a3)                             
f : fn(P1, P2, P3) -> R                   

Another form is the "curried" style, offered in pure functional languages like Haskell:

f p1 p2 p3 = ...         
f a1 a2 a3               
f :: P1 -> P2 -> P3 -> R 

Finally, there is the "tuple" style. It looks similar to the parameter list style, but the multiple parameters are not part of the functions itself. The function just has one parameter, but that parameter is a tuple so it effectively carries multiple values. This is usually possible in functional languages like Haskell as well but not the standard:

f(p1, p2, p3) = ...    
f(a1, a2, a3)          
f :: (P1, P2, P3) -> R 

Note that some imperative languages also offer these functional styles, but it gets a bit unwieldy. For instance, we can do the curried style in JavaScript:

const f = p1 => p2 => p3 => ...;
f(a1)(a2)(a3)

We can also do the tuple style in Rust:

fn f((p1, p2, p3): (P1, P2, P3)) -> R { ... }
f((a1, a2, a3))
f : fn((P1, P2, P3)) -> R

Ultimately, even though these styles have different practical use cases, they are equivalent in theory: the types (P1, P2) -> R and P1 -> P2 -> R are isomorphic, which means there is a one-to-one mapping between functions of those types. So, what's the reason for preferring the currying style to the others?

Partial Application

When you ask the internet why we do curried functions, the main response is "because it makes partial application straightforward". Partial application is a mechanism where you fix one of the parameters of a multi-argument function to a certain value, and get a new function that only takes the rest of the parameters as input. It is true that partial application is very natural and elegant for the currying style; for instance, if we take our 3-parameter add from before, you can do the following in Haskell:

add' = add 1

add' :: Int -> Int -> Int

add'' = add' 2

add'' :: Int -> Int

add'' 3 

This is especially nice when we have higher-level functions like map and fold. For instance, we can do pretty crazy cool things with partial applications and function composition:

length = foldr (+) 0 . map (const 1)
length2d = foldr (+) 0 . map length
length2d [[1, 4, 2], [], [7, 13]] 

However, it is often wrongly assumed that the option of doing partial application is a special property of curried functions! We can totally do partial application for functions in the parameter list style or tuple style. If we redefine add in the tuple style, we get something like the following:

add(x, y, z) = x + y + z
add :: (Int, Int, Int) -> Int

add' = let x = 1 in \(y, z) -> add(x, y, z)
add'' = let y = 2 in \z -> add'(y, z)
add''(3) 

"But," I hear you say, "this clearly looks horrible." Or maybe not, I don't want to put words in your mouth. But we can easily define a bit of syntactic sugar to make it look nice, for instance by defining a $ "hole operator":

add' = add(1, $, $)
add'' = add'(2, $)
add''(3) 

In my opinion, this is actually a bit more readable. The more complicated example now looks as follows:

length = foldr((+), 0, $) . map(const(1), $)
length2d = foldr((+), 0, $) . map(length, $)
length2d([[1, 4, 2], [], [7, 13]]) 

I actually find this form more clear. It kinds of shows the "flow" of the data that you feed into length or length2d: first into the second parameter of map, then the result of that is fed into the third parameter of foldr.

Additionally, such a feature allows partial applications of not just the first parameter, which does not work by default for the curried style. For instance if we want to fix the second parameter of map:

allColors = ["red", "green", "blue"]
forEachColor = map($, allColors)

This feature does have some limitations, for instance when we have multiple nested function calls, but in those cases an explicit lambda expression is always still possible.

So, despite its elegance, the curried function style doesn't really make partial application more powerful; with a little bit of syntactic sugar we can easily emulate its powers. However, I suspect there is another, more "vibe-based" reason why functional programmers have a dependence on curried functions stronger than water or sleep.

When you first learn functional programming and finally understand curried function types, it's like you're looking inside the matrix. It's so cool that when you make -> right-associative and function application left-associative, successively applying a curried function to multiple parameters unfolds beautifully! We don't even have to write parentheses when doing function application. And we get partial application completely for free, so we can write convoluted definitions for calculating the length of a 2D list and feel very clever.

Even more beautifully, it's essentially an inductive "shape", which reflects the dichotomy between imperative languages and functional languages: they've got their parameter lists, which are more like arrays (iterative), but we have curried functions, which are more like lists (inductive). It makes me feel all warm and fuzzy inside just thinking about the elegance! This is clearly meant to be!

Just because you can, doesn't mean you should. There are some good reasons to prefer the tuple style.

First of all, performance is a bit of a concern. When you call a curried function like add 2 3, the add 2 first evaluates to a new function expression \y -> add 2 y, which is then applied to 3. Every call to a multi-parameter function creates a bunch of intermediate functions. However, I'm sure a good enough optimizer can eliminate that overhead, so this is not really the greatest concern.

More importantly, curried function types have a weird shape. The whole idea about functions is that they take an input and give back an output, so they have types like In -> Out. When you unify this with a curried function type like P1 -> P2 -> P3 -> R, you get In = P1 and Out = P2 -> P3 -> R. When you unify it with a tupled function type like (P1, P2, P3) -> R, you get In = (P1, P2, P3) and Out = R, which seems more logical.

A consequence of this weird shape is a kind of asymmetry: if a function returns multiple outputs, it returns a tuple, but if it takes multiple inputs, you instead stagger them. As a result, curried functions often don't compose nicely.

sayHi name age = "Hi I'm " ++ name ++ " and I'm " ++ show age
people = [("Alice", 70), ("Bob", 30), ("Charlotte", 40)]

conversation = intercalate "\n" (map sayHi people)

The real issue here is that map is very generic and expects a function of the form In -> Out but curried functions don't have this shape. To make this work we have to instead pass uncurry sayHi as our mapping function. In this 2-parameter example that isn't so bad, but it gets worse with more parameters.

I personally faced another consequence while doing a project involving predicates that said something about monad-returning functions in the Rocq proof assistant. The predicate looked something like the following (parameters in {} are implicit type parameters):

Definition P {In Out : Type} (f : In -> State Out) :=
    ...some proposition about f...

If you define a function the "recommended" way, in a curried style, you get something like f : P1 -> ... -> Pn -> State R. This does not unify with In -> State Out at all, so P(f) is not even well-typed! I had to manually uncurry the function every time. :(

I realize that functional languages are not suddenly going to switch to the tuple style all of a sudden; millions of lines of Haskell have been written and curried functions are just how it's done right now. Nobody is going to change all of that because someone on the internet thought it would be a good idea :). However, if you ever happen to be writing a functional language or standard library, consider experimenting with the tuple style and an alternative syntax for partial application.

Don't take the article too seriously or as an absolute judgment that the tupled style is always better. I admit that for some higher-order functions, like map and fix, a curried definition just seems too nice to resist. I just think for most purposes the tuple style makes a lot more sense.

I'd also love to hear if you know any (dis)advantages of curried functions other than the ones mentioned. I've written a fair bit of functional code, but I'm by no means an expert on the topic and would always love to learn more. And it's possible I just wrote this article because I was salty that I kept having to uncurry functions during my proof assistant projects.

I did want to mention one case where the curried style is superior, although it is not very common. If you live in a dependently typed language like Gallina (the language of the Rocq/Coq proof assistant) or Agda, you can have the return type of a function depend on one of the inputs (not one of the input types, one of the input values), or you can have the type of the second parameter of a function depend on the value of the first. For instance, a common example of a dependent type is a natural number that is guaranteed to be upper-bounded by another natural number n:

Definition fin (n : nat) := { x : nat & x < n }.
Definition plus1 (n : nat) (i : fin n) : fin (n + 1) :=
    (i.1 + 1 ; ).

Here, plus1 has type forall n : nat, fin n -> fin (n + 1), which is a curried dependent function type with two parameters: n and i. The forall specifies that other parameters and the return type may depend on the value of the first parameter n. Say you had a version of this in the tupled style. Then the parameters would have to be a dependent tuple, where the type of the second tuple element may depend on the value of the first tuple element:

Definition plus1 (n : nat ; i : fin n) : fin (n + 1) :=
    (i.1 + 1 ; ).

This would have a type like forall arg : { n : nat & fin n }, fin (arg.1). Not the worst thing in the world, but I would say definitely more unwieldy.

Dependent types are famously immensely difficult to work with and make type inference undecidable, so even when you're working in a language with this capability, it's best to avoid dependent types in function parameters. Having said that, some people swear by them [1] and manage to write large codebases that make extensive use of them.

[1] The introduction chapter of the Cpdt book. Citation for the book:

Adam Chlipala. Certified Programming with Dependent Types. URL: http://adam.chlipala.net/cpdt/html/toc.html

Also on MIT Press.

Copyright emilia-h 2025-2026 licensed under CC BY-SA 4.0