# Difference between revisions of "Currying"

BrettGiles (talk | contribs) (HaWiki conversion) |
Uchchwhash (talk | contribs) m (minor explanation) |
||

Line 7: | Line 7: | ||

− | You'll notice that the notation for types reflects this: you can read <haskell>Int -> Int -> Int</haskell> incorrectly as "takes two <hask>Int</hask>s and returns an <hask>Int</hask>", but what it's ''really'' saying is "takes an <hask>Int</hask> and returns something of the type <hask>Int -> Int</hask>--that is, it returns a function that takes an <hask>Int</hask> and returns an <hask>Int</hask>. (One can write the type as <hask>Int x Int -> Int</hask> if you really mean the former--but since all functions in Haskell are curried, that's not legal Haskell.) |
+ | You'll notice that the notation for types reflects this: you can read <haskell>Int -> Int -> Int</haskell> incorrectly as "takes two <hask>Int</hask>s and returns an <hask>Int</hask>", but what it's ''really'' saying is "takes an <hask>Int</hask> and returns something of the type <hask>Int -> Int</hask>--that is, it returns a function that takes an <hask>Int</hask> and returns an <hask>Int</hask>. (One can write the type as <hask>Int x Int -> Int</hask> if you really mean the former--but since all functions in Haskell are curried, that's not legal Haskell. Alternatively, using tuples, you can write <hask>(Int, Int) -> Int</hask>, but keep in mind that the tuple constructor <hask>(,)</hask> itself can be curried.) |

Much of the time, currying can be ignored by the new programmer. The major advantage of considering all functions as curried is theoretical: formal proofs are easier when all functions are treated uniformly (one argument in, one result out). Having said that, there ''are'' Haskell idioms and techniques for which you need to understand currying. |
Much of the time, currying can be ignored by the new programmer. The major advantage of considering all functions as curried is theoretical: formal proofs are easier when all functions are treated uniformly (one argument in, one result out). Having said that, there ''are'' Haskell idioms and techniques for which you need to understand currying. |

## Revision as of 22:56, 18 October 2006

Currying is the process of transforming a function that takes multiple arguments into a function that takes just a single argument and returns another function if any arguments are still needed. In Haskell, *all* functions are considered curried: that is, *all functions in Haskell take just single arguments.*

```
div :: Int -> Int -> Int
```

`div 11 2`

unsurprisingly evaluates to `5`

.
But there's more that's going on than immediately meets the untrained eye. It's a two-part process. First, ```
div 11
```

*returns a function*of type

```
Int -> Int
```

`2`

, and yields `5`

.

```
Int -> Int -> Int
```

`Int`

s and returns an `Int`

", but what it's *really*saying is "takes an

`Int`

and returns something of the type `Int -> Int`

--that is, it returns a function that takes an `Int`

and returns an `Int`

. (One can write the type as `Int x Int -> Int`

if you really mean the former--but since all functions in Haskell are curried, that's not legal Haskell. Alternatively, using tuples, you can write `(Int, Int) -> Int`

, but keep in mind that the tuple constructor `(,)`

itself can be curried.)
Much of the time, currying can be ignored by the new programmer. The major advantage of considering all functions as curried is theoretical: formal proofs are easier when all functions are treated uniformly (one argument in, one result out). Having said that, there *are* Haskell idioms and techniques for which you need to understand currying.

Currying provides a convenient way of writing some functions without having to explicitly name them:

`(1+)`

(unsugared:`(+) 1`

) is the "increment" function,`(2*)`

is the "double" function,`("\t"++)`

is the "indent" function,`(`elem` "AEIOU")`

is the "is-capital-vowel-in-English" function (ignoring the "sometimes Y").

These are examples of partial application (and of "section" notation).

Sometimes it's valuable to think about functions abstractly without specifically giving all their arguments: this is the point free style.

Sometimes half the work of the function can be done looking only at the first argument (but there really *is* only one argument, remember?): see functional dispatch.