<p>In several functional languages like Haskell and OCaml, functions are automatically curried. This means that a function taking two arguments (<code>lambda x, y: x + y</code>) is actually a function that returns a function (<code>lambda x: lambda y: x + y</code>).</p>
<p>But most programming languages, even many functional languages, like Elixir, don't do this.</p>
<p>What are the advantages and disadvantages of this approach to functions?</p>

<functions><functional-programming><currying>
What are the pros and cons of automatically curried functions?
CC BY-SA 4.0
2024-08-08T20:42:11.753Z
This is not enough to substantiate an answer, but I read [a paper](https://antonlorenzen.de/mode-inference.pdf) recently that mentioned currying as a heavy impediment to the notions of ownership and locality they were introducing. In general it seemed they had difficulty with enforce something like "this function may be used only once" in the presence of partial application.
apropos
<p>Most languages do allow this just not as concisely:</p>
<pre><code>fn Add10(addMe: i32) -&gt; i32:
  return Add(10, addMe)
</code></pre>
<p>So, why would you add the extra complexity to a language by having special operators when there is a much simpler method?</p>

CC BY-SA 4.0
2023-05-18T14:04:46.000Z
2023-05-28T13:00:21.693Z
2023-05-28T13:00:21.693Z
mczarnek
CC BY-SA 4.0
2023-05-18T14:30:43.710Z
Isn't the point of OP that there's no operator or syntax involved?
Adám
CC BY-SA 4.0
2023-07-05T11:02:57.920Z
Yes it is...@Adám
Starship
<p>Some pros:</p>
<ol>
<li>Being concise. It has less arguments and is more readable. It also enables partial functions.</li>
<li>Flexibility. It allows for more flexibility in function composition and permits creation of more complex functions.</li>
</ol>
<p>Some cons:</p>
<ol>
<li><p>Complexity. Always important. Adding this makes the language more complex to learn.</p>
</li>
<li><p>Performance. Adding automatic currying worsens performance. In some situations, it is negligible; in others, it is a real problem.</p>
</li>
</ol>

CC BY-SA 4.0
2023-05-17T23:00:35.253Z
2024-07-28T06:46:15.487Z
2024-07-28T06:46:15.487Z
Starship
CC BY-SA 4.0
2023-05-17T23:38:25.097Z
In addition for at least Haskell's case, it might not be correct to consider it a "feature" since it's actually a side effect of Haskell functions not accepting multiple arguments. Every language that supports some sort of closures actually supports this, for example Javascript:
```javascript
let fn = (a => (b => a+b));
console.log(fn(1)(2));
```
kouta-kun
CC BY-SA 4.0
2023-05-18T01:52:49.197Z
@kouta-kun Haskell could easily have not added dedicated syntax for defining curried functions, and people could write it just fine by passing multiple arguments through product types instead, like the ML family tends to prefer. The "automatic currying" that the question asks about is a very intentional feature.
Unrelated String
CC BY-SA 4.0
2023-05-18T06:11:32.453Z
By "partial functions" do you mean "partially applied functions"?
kaya3
CC BY-SA 4.0
2023-05-18T07:49:57.660Z
@kouta-kun I think it's worth talking about etymology when we discuss the language Haskell and the term "currying" and why the Haskell language decided to opt for it. There is a mathematician that came up with the concept of a function that only takes a single parameter and instead of multiple parameters, it just returns a function. This allows for using some nice properties that work on single parameter functions and makes computing them easier and more in some cases. The concept of "currying" is thus named after the mathematician: [Haskell Curry](https://en.wikipedia.org/wiki/Haskell_Curry).
VLAZ
CC BY-SA 4.0
2024-07-28T11:02:30.910Z
Welcome back to the site!
mousetail 'he-him'
CC BY-SA 4.0
2024-07-28T11:08:10.367Z
Thank you. By the way, are what would formally have been pros-cons tagged questions now banned?@mousetail
Starship
<p>It introduces the limitation that a single function cannot take a variable number of arguments, since giving fewer than the maximum number of arguments will simply curry and return a function, rather than do the computation on the given number of arguments.</p>

CC BY-SA 4.0
2023-05-18T05:46:27.313Z
2023-05-18T05:46:27.313Z
Adám
CC BY-SA 4.0
2023-05-18T14:11:24.677Z
To be fair, you [can do](https://hackage.haskell.org/package/base-4.18.0.0/docs/Text-Printf.html) variadic functions in Haskell. But to be even more fair, `Text.Printf` is not really a shining example of good Haskell code.
Silvio Mayolo
<h1>Worse error messages</h1>
<p>In a non-curried language, if you forget an argument to a function, you get an error message saying so. In a curried language, this may silently create a partially-applied function and then the error will pop up as a type error in a different place.</p>

CC BY-SA 4.0
2024-08-08T18:57:40.143Z
2024-08-08T18:57:40.143Z
xigoi
CC BY-SA 4.0
2024-08-08T23:23:38.180Z
This is particularly a problem in dynamically typed languages. Partially-applied functions can propagate throughout the program until finally raising a runtime error, far from the site of the error. Without static types to catch accidentally partially applied functions early, this can be a pain to track down.
apropos
# What are the pros and cons of automatically curried functions?
Posted by: username_0 on 2023-05-17
In several functional languages like Haskell and OCaml, functions are automatically curried. This means that a function taking two arguments (`lambda x, y: x + y`) is actually a function that returns a function (`lambda x: lambda y: x + y`).

But most programming languages, even many functional languages, like Elixir, don't do this.

What are the advantages and disadvantages of this approach to functions?
**Tags:** functions functional-programming currying
> **Comments:**
> **username_1**: This is not enough to substantiate an answer, but I read [a paper](https://antonlorenzen.de/mode-inference.pdf) recently that mentioned currying as a heavy impediment to the notions of ownership and locality they were introducing. In general it seemed they had difficulty with enforce something like "this function may be used only once" in the presence of partial application.  
---
## 4 answers
### Answer by username_4 on 2023-05-17. Score: 12 | Accepted answer
Some pros:

1. Being concise. It has less arguments and is more readable. It also enables partial functions.
2. Flexibility. It allows for more flexibility in function composition and permits creation of more complex functions.

Some cons:

1. Complexity. Always important. Adding this makes the language more complex to learn.
2. Performance. Adding automatic currying worsens performance. In some situations, it is negligible; in others, it is a real problem.
> **Comments:**
> **username_5** (2023-05-17): In addition for at least Haskell's case, it might not be correct to consider it a "feature" since it's actually a side effect of Haskell functions not accepting multiple arguments. Every language that supports some sort of closures actually supports this, for example Javascript:
```javascript
let fn = (a => (b => a+b));
console.log(fn(1)(2));
```  
> **username_6** (2023-05-18): @kouta-kun Haskell could easily have not added dedicated syntax for defining curried functions, and people could write it just fine by passing multiple arguments through product types instead, like the ML family tends to prefer. The "automatic currying" that the question asks about is a very intentional feature.  
> **username_7** (2023-05-18): By "partial functions" do you mean "partially applied functions"?  
> **username_8** (2023-05-18): @kouta-kun I think it's worth talking about etymology when we discuss the language Haskell and the term "currying" and why the Haskell language decided to opt for it. There is a mathematician that came up with the concept of a function that only takes a single parameter and instead of multiple parameters, it just returns a function. This allows for using some nice properties that work on single parameter functions and makes computing them easier and more in some cases. The concept of "currying" is thus named after the mathematician: [Haskell Curry](https://en.wikipedia.org/wiki/Haskell_Curry).  
> **username_9** (2024-07-28): Welcome back to the site!  
> **username_4** (2024-07-28): Thank you. By the way, are what would formally have been pros-cons tagged questions now banned?@mousetail  
---
### Answer by username_3 on 2023-05-18. Score: 16
It introduces the limitation that a single function cannot take a variable number of arguments, since giving fewer than the maximum number of arguments will simply curry and return a function, rather than do the computation on the given number of arguments.
> **Comments:**
> **username_10** (2023-05-18): To be fair, you [can do](https://hackage.haskell.org/package/base-4.18.0.0/docs/Text-Printf.html) variadic functions in Haskell. But to be even more fair, `Text.Printf` is not really a shining example of good Haskell code.  
---
### Answer by username_11 on 2024-08-08. Score: 4
# Worse error messages

In a non-curried language, if you forget an argument to a function, you get an error message saying so. In a curried language, this may silently create a partially-applied function and then the error will pop up as a type error in a different place.
> **Comments:**
> **username_1** (2024-08-08): This is particularly a problem in dynamically typed languages. Partially-applied functions can propagate throughout the program until finally raising a runtime error, far from the site of the error. Without static types to catch accidentally partially applied functions early, this can be a pain to track down.  
---
### Answer by username_2 on 2023-05-18. Score: -1
Most languages do allow this just not as concisely:
fn Add10(addMe: i32) -> i32:
  return Add(10, addMe)

So, why would you add the extra complexity to a language by having special operators when there is a much simpler method?
> **Comments:**
> **username_3** (2023-05-18): Isn't the point of OP that there's no operator or syntax involved?  
> **username_4** (2023-07-05): Yes it is...@Adám  
---
