Currying and partial application.

In Haskell, every function takes exactly one argument. tourPrice :: Int -> Int -> Int looks like a function of two arguments. But the arrow groups to the right, so the type means Int -> (Int -> Int): tourPrice takes the hours and returns a function, and that function takes the number of people and returns the price. Writing a function of several arguments as a chain of one-argument functions is called currying.

Application groups to the left, so tourPrice 2 3 means (tourPrice 2) 3. That is why tourPrice 2 on its own is a complete expression. It is a partial application: a value of type Int -> Int that keeps the 2 and waits for the people. You can name it, pass it to another function, and apply it later, as often as you need.

GHC checks how many arguments you give. With one missing where a printable value is needed, as in print twoHours, GHC reports No instance for (Show (Int -> Int)) arising from a use of ‘print’, and adds (maybe you haven't applied a function to enough arguments?). print cannot show a function. With one argument too many, as in tourPrice 2 5 1, GHC reports Couldn't match expected type ‘t0 -> a0’ with actual type ‘Int’, and then: The function ‘tourPrice’ is applied to three value arguments, but its type ‘Int -> Int -> Int’ has only two.

Every Haskell function takes one argument; a function of two arguments returns a function, and applying it to one argument gives that function.

A partial application always fills the first parameter. So the order of the parameters decides which partial applications you can write. shareOf people total = total `div` people shares a tour’s total among the people; `div` divides whole numbers and drops the remainder. shareOf 4 means “a quarter of any total”, which suits map (shareOf 4) [120, 200].

To share one total of 120 among groups of 2 and of 3, shareOf 120 is wrong: it makes 120 the people. Both parameters are Int, so GHC accepts it, and map (shareOf 120) [2, 3] gives [0,0].

A common rule is to put the argument that changes least first. A rate, a fee, or a setting usually comes first, and the value that changes at each use, such as each price in a list, comes last. The Prelude follows this rule: map and filter take the function first and the list last.

When one use needs the other order, flip swaps the first two arguments: flip f x y is f y x. flip shareOf 120 is a function of the people with 120 as the total. A lambda that names the parameter says the same thing: \people -> shareOf people 120.

A partial application fills the first parameter; put the argument that changes least first, and use flip or a lambda when one use needs the other order.

An operator such as / takes two arguments, one on each side. Map, filter, and reduce used operator sections such as (+ 10): an operator in parentheses with one side filled in. For an operator whose result depends on the order, the side you fill matters. (/ 2) fills the right side, so (/ 2) 8 is 8 / 2, which is 4.0. (2 /) fills the left side, so (2 /) 8 is 2 / 8, which is 0.25. Each argument goes into the gap.

A function name between backticks is used as an operator, so it has sections too: (`div` 2) 9 is 9 `div` 2, which is 4. An operator alone in parentheses, such as (-) or (/), is an ordinary function of two arguments, and a partial application of it fills the left side: (-) 10 is the function that gives 10 minus its argument.

Minus is the exception to sections. (- 1) is not a section: Haskell reads it as the number minus one. In map (- 1) fees, GHC reports No instance for (Num (Double -> Double)) arising from a use of syntactic negation. The message means that GHC tried to make a negative number out of something that must be a function. Write subtract 1 instead: subtract 1 fee is fee - 1. subtract takes the amount to subtract first, so that it can be partially applied.

A section fills one side of an operator, and each argument goes into the gap; (- 1) is a number, so write subtract 1.

A tuple groups a fixed number of values: (2, 3) is one value, a pair. A function can take a pair instead of two arguments. priceOf (hours, people) = … takes one argument, a pair, and its type is (Int, Int) -> Int. Such a function cannot be partially applied, because it has only one argument. Giving a pair to a curried function is a type error: tourPrice (2, 3) gives Couldn't match expected type ‘Int’ with actual type ‘(a0, b0)’.

uncurry turns a curried function into one that takes a pair: uncurry tourPrice (2, 3) is tourPrice 2 3. curry goes the other way: curry priceOf 2 3 is priceOf (2, 3). Their types say it: uncurry :: (a -> b -> c) -> (a, b) -> c, and curry :: ((a, b) -> c) -> a -> b -> c.

uncurry is useful when values already come in pairs, such as a list of bookings, or the pairs that zip makes from two lists: zip [2, 3] [3, 1] is [(2,3),(3,1)]. map (uncurry tourPrice) gives the first part of each pair to the first parameter. zipWith tourPrice [2, 3] [3, 1] gives the same result without making the pairs.

A function on a pair takes one argument; uncurry and curry convert between the two forms, and the first part of a pair always fills the first parameter.

When a definition’s last parameter appears only at the end of both sides, it can be left out. halveAll fees = map (/ 2) fees and halveAll = map (/ 2) define the same function: both sides are applied to fees, so removing fees from both changes nothing. This is called point-free style; “point” is an old word for an argument.

Point-free style is clear when what remains is one partial application or one section, as in halveAll. It soon becomes hard to read. The . operator joins two functions: (f . g) x is f (g x). The topic Composition and data transformation, later in this section, covers it. With . and sections, splitCost = (. length) . div . sum is a correct definition, but few readers can say what it computes. With its parameters named, it is splitCost costs people = sum costs `div` length people.

A useful test: if a reader must work out the type to know what a definition does, name the parameters. Keep a type signature on every point-free definition, because it tells the reader what the missing arguments are.

Leave out the last argument when one partial application or section remains; name the parameters when the reader would need the type to follow the code.

Four mistakes with partial application are common in real Haskell code.

A section the wrong way round. map (/ 2) prices halves each price; map (2 /) prices divides 2 by each price and still type-checks. The same holds for (`div` n) and (n `div`). Read the gap as the place each element goes.

(- 1) used as a function. map (- 1) counts does not subtract one: (- 1) is the number minus one, and GHC reports No instance for (Num (Int -> Int)) arising from a use of syntactic negation. The message names negation and Num, not the section, so it is easy to misread. Write subtract 1.

A partial application stored with its arguments in the wrong order. Below, fromHotel was meant as “800 metres from the hotel, at any speed”. walkMinutes takes the speed first, so fromHotel 80 is 80 `div` 800, which is 0. Both are Int, so GHC accepts it, and the stored name is used far from the definition. When you define such a function, put the argument that changes least first, and give the parameters names that say their role.

Point-free code nobody can read. A chain of . and sections that saves one name costs every later reader time. When a review needs the type to explain a line, give the line its parameters back.

Read the gap in each section, write subtract for minus, check the parameter order before you store a partial application, and name the parameters when point-free code needs its type to be read.

Decide which parameter each partial application fills, and which side each section fills, before you predict.