re: Currying in Haskell (With Some JavaScript) VIEW POST


Perhaps historically, when first introduced, currying added value to a language. The same concepts can now be applied in any language that allows lambdas, without the misleading syntax.


I would tend to agree. Originally currying seems to have come more from the math/logic side of things, where it was useful to show from a theoretical point of view that more complex models of computation could be reduced to the much simpler lambda calculus. It also appears to come into play in type theory and category theory.

In terms of programming languages, I don't see any value in going out of one's way to use currying. I'm guessing that Haskell could probably be modified to forgo currying altogether, but since lazy evaluation is such a fundamental aspect of the language, it kind of makes sense to me that they decided to apply currying to function calls too: It feels consistent with their overall approach...

Here's an example of how I think it does kind of make sense in Haskell:

import Data.List  

numUniques :: (Eq a) => [a] -> Int  
numUniques = length . nub 

numUniques just returns a thunk which you can then pass an actual list to. Note how in the body of the function the list that's passed in as a parameter is never even mentioned!

nub filters out duplicate values from a list and . does function composition, so the above code is equivalent to:

import Data.List  

numUniques :: (Eq a) => [a] -> Int  
numUniques items = length(nub items) 

There's kind of a minimalist elegance to the first version, but on the other hand the second sample seems to be more clear about what is going on! Maybe it’s worth noting though that the code is equally lazy in both cases.


Hello, this is an interesting and non-typical article. I enjoyed reading it.

However, I would not agree that Haskell can forgo currying nor would I agree that currying is not fundamental to functional programming.

Lambda calculus defines all functions (abstractions) to take exactly one input and produce exactly one output. Thus, currying is a fundamental property of any lambda calculus and the only tool it has to work with functions taking multiple arguments.

Since Haskell is built on lambda calculus and is semantically a typed lambda calculus itself, currying is not really an optional feature, but rather a fundamental property of the language. As you mentioned in the article, all functions in Haskell are single input functions (hence the strange type signatures). This means that it is actually impossible to apply any function without currying coming into play. For example, let's take a look at the following code:

sub :: (Num a) => a -> a -> a
sub first second = first - second

main = print (sub 7 2) 

The function sub is not called using two arguments. This is what actually happens:

main = print ((sub 7) 2) 

The function is applied to the number 7. This application returns a new function which is applied to the number 2 finally returning the number 9. All functions (and their applications) in Haskell work like this.

Taking currying away from Haskell would render it useless. You can, of course, allow functions to take more than one argument in the first place. However, by doing this, Haskell would seize to be a lambda calculus and a purely functional language. I would not say that they "decided to apply currying to function calls". Functions and function calls are where currying comes from and it is actually inevitable.

If by saying that Haskell could forgo currying you meant that currying doesn't really have any practical applications aside from providing consistent conceptual purity, I would also have to disagree :). The main use case of currying is partial application of functions. I believe this concept is as important to functional programming as inheritance is to OOP.

P.S. I realize some of the things I mentioned here are explained in the article or in one of the prior comments. I've decided to reiterate them for the sake of completeness and clarity :)

Code of Conduct Report abuse