On Sat, Oct 1, 2011 at 2:40 PM, Petar Radosevic wrote:

Peter Hall wrote the following on Sat, Oct 01, 2011 at 10:49:31AM +0100:

...

I think this sentence isn't right:

"Curried functions are functions that only take one parameter."

The way I understand it, a non-curried function takes only one parameter. Currying is syntactic sugar so you don't have to use higher-order functions every time you want multiple parameters.

Without currying, if you wanted a function like:

    f a b c = 2 * a + b - c

, you'd have to write it something like:

  f a = f1       where f1 b = f2           where f2 c = 2 * a + b - c

or

   f a = (\b -> (\c ->  2*a + b -c))

You are right, I changed the sentence to better reflect wat currying really is. Thank you for your input.

Sorry but you are mistaken on the sense of currying. Basically to curry the function f is to transform it from the type "(a,b) -> c" to the type "a -> (b -> c)", in other words instead of function from a cartesian product to a set, you get a function from the first element of the product to the set of function from the second element of the product to the original final set. This is a mathematical transformation that Curry noted was always possible whatever the function. In a CS context, this transformation is only possible in languages that handle functions as first-class data types, Haskell (or the ML family) is only special in that it encourage you to write every functions in an already curried style instead of the uncurried fashion that is used in most other languages. Every single example you give in your blog is curried, uncurried would be :

sumTwo :: (Int,Int) -> Int sumTwo (x,y) = x + y

and

f :: (Int,Int,Int) -> Int f (a,b,c) = 2 * a + b - c

See the function "curry" and "uncurry" to see that passing from one style to another can be automated (though only elegantly for two parameters). Still it is true that currying functions ease the partial application of function (at least if your parameters are ordered sensibly). -- Jedaï

On Sun, Oct 2, 2011 at 12:04 AM, Rustom Mody wrote:

How would you classify a function of type (Int, Int) -> Int -> Int ?

It's curried. Uncurried would be: ((Int, Int), Int) -> Int

Likewise if we have a polymorphic foo: Int -> a and we instantiate a to Int -> Int  does foo suddenly get curried?

Int -> a is both curried and uncurried. Int -> Int -> Int is just curried. -- Felipe.

Chaddaï Fouché wrote the following on Sun, Oct 02, 2011 at 12:48:31AM +0200:

On Sat, Oct 1, 2011 at 2:40 PM, Petar Radosevic wrote:

...

Peter Hall wrote the following on Sat, Oct 01, 2011 at 10:49:31AM +0100:

...

I think this sentence isn't right:

"Curried functions are functions that only take one parameter."

The way I understand it, a non-curried function takes only one parameter. Currying is syntactic sugar so you don't have to use higher-order functions every time you want multiple parameters.

Without currying, if you wanted a function like:

    f a b c = 2 * a + b - c

, you'd have to write it something like:

  f a = f1       where f1 b = f2           where f2 c = 2 * a + b - c

or

   f a = (\b -> (\c ->  2*a + b -c))

You are right, I changed the sentence to better reflect wat currying really is. Thank you for your input.

Sorry but you are mistaken on the sense of currying. Basically to curry the function f is to transform it from the type "(a,b) -> c" to the type "a -> (b -> c)", in other words instead of function from a cartesian product to a set, you get a function from the first element of the product to the set of function from the second element of the product to the original final set. This is a mathematical transformation that Curry noted was always possible whatever the function. In a CS context, this transformation is only possible in languages that handle functions as first-class data types, Haskell (or the ML family) is only special in that it encourage you to write every functions in an already curried style instead of the uncurried fashion that is used in most other languages. Every single example you give in your blog is curried, uncurried would be :

...

sumTwo :: (Int,Int) -> Int sumTwo (x,y) = x + y

and

...

f :: (Int,Int,Int) -> Int f (a,b,c) = 2 * a + b - c

See the function "curry" and "uncurry" to see that passing from one style to another can be automated (though only elegantly for two parameters).

Still it is true that currying functions ease the partial application of function (at least if your parameters are ordered sensibly).

Thank you for your explanation. I was also corrected on reddit[1] on the matter. Since my post is wrong on the subject I have decided chuck it and write a new one. I'm collecting all the comments people made as we speak and am going to make good use of them in a post which hopefully _does_ explain currying. [1]: http://www.reddit.com/r/haskell/comments/kxdh7/curry_and_its_partial_applica... -- Petar Radošević, Programmer wunki.org | @wunki