## Currying

The term "currying" comes from Haskell Curry, a famous logician who worked in State College (Dept of Mathematics) and developed the Combinatory Logic, which, together with the Lambda Calculus (Alonzo Church) constitutes the foundation of Higher Order Functional Programming.

Essentially, the idea is the following: consider a function f: 'a * 'b -> 'c. This function takes a pair of arguments, the first of type 'a, and the second of type 'b, and gives back a result in 'c. There is only one way f can be applied: by passing the two arguments together. Given x:'a, and y:'b, we write f(x,y) for the application of f to the pair(x,y).

We could imagine now a variant of f that, instead of taking the arguments together, takes them "one at the time", and gives the same result as f when it is supplied with both arguments. This variant is called curried version of f. Let us denote it by fc. The type of this function is fc: 'a -> 'b -> 'c, and, by definition, we have that for every x:'a, and y:'b, f(x,y) = fc x y holds. The main difference between f and fc is that the latter can be applied also to the first argument only: The expression fc x (for x:'a) is perfectly legal and denotes a function of type 'b -> 'c (the function which, when provided with an input y:'b, will give as result f(x,y)).

In order to provide support for curried functions, a language needs to be Higher Order. The currying adds flexibility and expressivity to the language, and it is part of the general principle of abstraction. In a sense, currying is intrinsic to the philosophy and design of an higher-order language. Below we will see some examples of how this feature adds expressivity.

Let us see how the currying possibility can be used in ML.

### Defining curried functions

Let us consider a function with two arguments like the append of two lists. A possible definition is:
```   - fun append([],k) = k
| append(x::l,k) = x::append(l,k);
val append = fn : 'a list * 'a list -> 'a list
```
The curried version of append can be defined in the following way:
```   - fun append_c [] k = k
| append_c (x::l) k = x::(append_c l k);
val append_c = fn : 'a list -> 'a list -> 'a list
```
or, equivalently:
```   - fun append_c [] = (fn k => k)
| append_c (x::l) = fn k => x::(append_c l k);
val append_c = fn : 'a list -> 'a list -> 'a list
```
We can now write expressions like append_c [1], for instance in a declaration:
```   - val append_one = append_c [1];
val append_one = fn : int list -> int list
```
Note that the system does not evaluate the expression append_c [1], because it is a function. It only computes its type. The evaluation will be performed only when we provide also the second argument. For instance:
```   - append_one [5,6];
val it = [1,5,6] : int list
```

### Using currying for abstraction

We illustrate here how Higher Order and currying provide powerful and elegant mechanisms for abstraction.

Consider the functions sum_all : int list -> int and product_all : int list -> int (respectively sum and product of all the elements in a list of integers). They can be defined as follows:

```   - fun sum_all [] = 0
| sum_all (x::l) = x + sum_all l;
val sum_all = fn : int list -> int

- fun product_all [] = 1
| product_all (x::l) = x * product_all l;
val product_all = fn : int list -> int
```
Note that these two function work according to the same scheme: they scan the list (recursively) element by element, and perform a certain operation on every element (and on the result of the recursive call), and give a certain initial result when the list is empty.

This scheme is common to several other functions. We could then think of defining an abstract function (abstract wrt the operation and the initial element), which represent the general scheme. The particular functions (like sum_all and product_all can then be defined by providing the particular operation and initial value. This general function is commonly called reduce, and it is "more natural" to define it by using currying, as follows:

```   fun reduce f v [] = v
| reduce f v (x::l) = f(x, reduce f v l);
val reduce = fn : ('a * 'b -> 'b) -> 'b -> 'a list -> 'b
```
Here, f: 'a * 'b -> 'b represents the operation, and v:'b represents the initial value.

The definitions of sum_all and product_all can now be given as follows:

```   - val sum_all = reduce (op +) 0;
val sum_all = fn : int list -> int

-  val product_all = reduce (op * ) 1;
val product_all = fn : int list -> int
```
We need to use (op +) and (op * ) instead of + and * because the latter are infix, while in the definition of reduce the parameter f is prefix. The operator op changes a function from infix to prefix.

We can now apply these functions to lists of integers, as illustrated in the following examples:

```   - sum_all [];
val it = 0 : int
- sum_all [1,2,3,4];
val it = 10 : int

- product_all [];
val it = 1 : int
- product_all [1,2,3,4];
val it = 24 : int
```
Another example of function that we can define by using reduce is the function forall, which checks whether a certain property p: 'a -> bool holds for all elements of a list (of type 'a list). We can define it as follows:
```   fun forall p = let fun f(x,b) = p x andalso b
in reduce f true
end;
val forall = fn : ('a -> bool) -> 'a list -> bool
```
Examples of uses (note that (fn x => x>0) represents the property of being positive; (fn x => x mod 2 = 0) represents the property of being even).
```   - forall (fn x => x>0) [1,2,3];
val it = true : bool
- forall (fn x => x>0) [~1,2,3];
val it = false : bool

- forall (fn x => x mod 2 = 0) [2,0,4];
val it = true : bool
- forall (fn x => x mod 2 = 0) [2,1];
val it = false : bool
```
Other examples can be found in Assignment 8 (CSE 428, Spring 99). Note that in the assignment the type of reduce is restricted. The reason is due to a certain limitation of the type system of the present implementation of SML. We won't go into that because it's a bit complicated, and not so important.

The concept of currying extends naturally to arbitrary tuples of arguments.

# Type theory and programming languages

Types are very useful in programming languages. The advantages of using a typed language include:
1. (substantial) help in detecting errors
2. increasing program readability
3. increasing efficiency in implementation (because of better allocation of resources)

#### Some terminology

• Type system: the formal description (theory) of the laws which associate a type to every expression, in a given language.
• Typed language: a language which is provided with a type system. Examples of languages which have a type system: almost all modern high level languages, except Scheme (which is used mainly for didactical purposes) and (most of) Prolog.
• Type checker: implementation of the type system, i.e. component of the implementation of a language which checks the correct use of names and expressions, relatively to types.
• Type inference system: component wich not only checks, but is also able to infer the type of expressions and names, so that they do not need to be declared explicitly by the user. Examples of languages which have a type inference mechanism: ML, and most of the (typed) functional languages.

• Strongly typed: A language is strongly typed if, once the type checker has given its "ok", we can be sure that the program will never give an error due to types at run time. Examples: Pascal, ML.
• Weakly typed: The contrary of strongly typed. Some languages give up the strongly typed property (on certain data types) in favour of flexibility. For instance, Algol, C, C++ etc. do not check that indexes of arrays are used within their range.

• Static type checking: we say that a language is statically type-checked if the type checking done entirely at compile time. Examples: Pascal, ML.
• Dynamic type checking: the part of type checking done at run time. In general it is preferable to do the type checking at compile time, since it is more efficient. From the point of view of flexibility, however, we might want to allow that the type correctness of an expression depends on run-time properties. An example is the operation of casting in C++. Note that the price to be paid for this flexibility includes safety: we can never be sure that a program is type safe when correctness depends on run-time properties (it might run correctly for years and then, one day, give a type error).

• Polymorphic type system: A type system which allow types to depend on parameters. This feature is a powerful mechanism for abstraction. Note: by "polymorphism" here we mean "generic polymorphism", as distinct from "ad-hoc polymorphism". The latter concept merely means that an operation is overloaded, and has nothing to do with parametricity. Examples of languages with (generic) polymorphism: ML and most of the (typed) functional languages. C++ also allows to express some type parametricity (templates), but it is not well integrated in the type system. (The type checker of C++ does not check that templates are used consistently, they are expanded like macros at run time.) We will study the type system of ML, as the case study for a type system, because
1. it has solid mathematical foundations
2. it is well implemented
3. it is rich (higher-order, polymorphism)
By the way, there is a recent project which aims at enhancing Java with a polymorphic type system. They are taking ML as model (and not C++, because, as explained above, in C++ polymorphism is not done so well). This project is carried on in collaboration by a team at Sun Micro Sys. and a team at Bell Labs, and it's leaded by Philip Wadler. Currently, their main obstacle is how to make the new Java (called "Generic Java") compatible with the current version.

## The type system of ML

In order to focus on the main concepts regarding types, we will consider a small subset of ML and its type system. The expressions in this subset, which we will call Mini-ML, are described by the following grammar:
```    Exp ::= Ide                 (identifiers)
| Exp Exp             (functional application)
| fn Pattern => Exp   (functional abstraction)
| (Exp,Exp)           (pairing)
| Exp :: Exp          (cons on lists)
| hd Exp              (head of a list)
| tl Exp              (tail of a list)
| nil                 (empty list)

Pattern ::= Ide
| (Ide,Ide)
```
This is a very small subset of ML (both wrt the expressions and the patterns), and we may wish to extend it later, so to include other interesting data types and constants (like numbers). For the moment however we prefer focussing on just few constructs.

The types of this language constitute a language (type expressions) described by the following grammar:

```   Type ::= TVar             (type variables, i.e. parametres for types)
| Type * Type      (Cartesian product, the type of pairs)
| Type -> Type     (functional type, the type of functions)
| Type list        (the type of lists)
```
We will use the Greek letters alpha, beta, gamma,... to represent the type variables. They correspond to the dashed symbols 'a, 'b, 'c, ... used by the ML system.

Convention: * is left associative. -> is right associative. list has precedence wrt *, and * has precedence wrt ->.

Before studying the Type System formally, let us see some examples of type inferences that are done automatically by the type system of ML.

1. ```- fn f => fn x => fn y => f x y;
val it = fn : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c
```
2. ```- fn f => fn (x,y) => f(x,y);
val it = fn : ('a * 'b -> 'c) -> 'a * 'b -> 'c
```
3. ```- fn f => fn x => fn y => (f x,f y);
val it = fn : ('a -> 'b) -> 'a -> 'a -> 'b * 'b
```
4. ```- fn l => fn f => (f (hd l)) :: (tl l);
val it = fn : 'a list -> ('a -> 'a) -> 'a list
```
Let us see what is, intuitively, the "reasoning" done by the ML type system to derive the above types.

1. fn f => fn x => fn y => f x y is a function, so its type must be of the form
```   alpha -> beta -> gamma -> delta
```
where alpha is the type of f, beta is the type of x, gamma is the type of y, and delta is the type of the result.

Now, let us analyze how these types are related. In the resulting expression, f is applied to x and the result is applied to y (remember that f x y = (f x) y because application is left-associative). Hence alpha = beta -> phi where phi is the type of (f x). Since we then apply (f x) to y, and we have called delta the type of the result, we must have phi = gamma -> delta.

In conclusion the type is:

```   (beta -> gamma -> delta) -> beta -> gamma -> delta
```
(names are not important, only their relation is)

We need to put parentheses around the first beta -> gamma -> delta because if we don't do that then the type becomes

```   beta -> gamma -> delta -> beta -> gamma -> delta
```
which is interpreted as
```   beta -> (gamma -> (delta -> (beta -> (gamma -> delta))))
```
since -> is right-associative.

2. Convention: From now on I'll use the notation "z: t" to mean "z has type t".

fn f => fn (x,y) => f(x,y) is a function, where the second parameter is a pair, hence its type must be of the form

```   alpha -> (beta * gamma) -> delta
```
where f: alpha, x: beta, y: gamma, and (f(x,y)): delta

Since f is applied to (x,y) and the result is of type delta, then it must be

```   alpha = (beta * gamma) -> delta
```
hence the type is
```   ((beta * gamma) -> delta) -> (beta * gamma) -> delta
```
(the parentheses around (beta * gamma) are not necessary because * has priority wrt ->)

3. fn f => fn x => fn y => (f x,f y) is a function, hence its type must be of form
```   alpha -> beta -> gamma -> delta
```
where f: alpha, x: beta, y: gamma, and (f x, f y): delta

Now, since the result is a pair, we must have delta = phi * psi, where (f x): phi and (f y): psi. Since f is applied to x and to y, we must have alpha = beta -> phi, and also alpha = gamma -> psi. Hence we obtain beta = gamma, and phi = psi. Thus the type is (again, names are not important):

```  (beta -> phi) -> beta -> beta -> phi * phi
```

4. fn l => fn f => (f (hd l)) :: (tl l) is a function, hence its type must be of form
```   alpha -> beta -> gamma
```
where l: alpha, f: beta, and ((f (hd l)) :: (tl l)) : gamma.

Since the result is constructed with a cons operation, it must be a list. Hence we have gamma = delta list, where delta is the type of (f (hd l)). Furthermore, the rest of the list is given by (tl l), hence also l must have type delta list (l and (tl l) have the same type). Therefore we have alpha = delta list. Finally, observe that (hd l): delta and (f (hd l)): delta, hence we can deduce f: delta -> delta. In conclusion, the resulting type is:

```   delta list -> (delta -> delta) -> delta list
```