# Consistency of the Lambda Calculus

We will show that the Lambda Calculus is consistent, in the sense that not all terms are equivalent (lambda-convertible). In particular, different Church's numerals are not lambda-convertible. Note that if the Church's numerals were identified by lambda-conversion, then the result of lambda-definability (Lecture 2) would not be of any interest.

In order to prove this result, it is convenient to introduce the notion of beta-reduction.

### Beta reduction

The notion of conversion is symmetric, but from a computational point of view the beta rule has a direction. This directionality is captured in the concept of beta-reduction.

From now on, we will reason modulo alpha-renaming, i.e. we will identify terms which are alpha-convertible.

• -> is the least relation s.t
• (\x. M) N -> M[N/x],
• M -> M' => M N -> M'N,
• N -> N' => M N -> M N',
• M -> M' => \x. M -> \x. M'
• ->> is the reflexive and transitive closure of ->
Note: the lambda-conversion is the reflexive, symmetric, and transitive closure of -> (or equivalently, of ->>)

Theorem (Church-Rosser) ->> is confluent (enjoyes the diamond property). Namely, if M ->> N and M ->> P, then there exists Q such that N ->> Q and P ->> Q.

Corollary If N = P then there exists Q such that N ->> Q and P ->> Q.

As a consequence we have:

Theorem The Lambda Calculus is consistent. In particular, different Church's numerals are not lambda-convertible.

In fact, if [m] = [n], then from previous corollary there must exist P such that [m] ->> P and [n] ->> P. However, Church's numerals are in normal form, i.e. they cannot be reduced. Hence we mush have that [m] and P and [n] are identical (modulo alpha-renaming). But, by definition of Church's numerals, [m] and [n] are identical only if m and n are the same number.

# Programming Languages based on the Lambda Calculus

The Lambda Calculus is the basis of the functional languages. These usually have a "core" corresponding to the Lambda Calculus, plus:
• Some data structures and primitives: for convenience of programming.
• Declarations: for convenience of programming.
• A fixed evaluation strategy: for efficiency. In Lambda Calculus every reducible subterm can be selected for reduction. In real languages, the choice of the subterm is fixed. The main strategies are relative to the function call and are:
• Call-by-value, or eager strategy, which always evaluates the argument first, and
• Call-by-name, or lazy strategy, which evaluates first the body of the funcion, and evaluates the arguments only if necessary.
It can be shown that the lazy strategy is complete, i.e. it covers all the possible reductions of the Lambda Calculus, while the eager strategy is not complete.
• Types (not always).
Several languages have been proposed. For instance:
• Lisp (1958, Mc Carty). Untyped. Eager. Dynamic Scope (This was actually unintended, and it is considered a mistake, in fact the Lambda-Calculus has lexical scope. Dynamic scope corresponds to "capturing" free (i.e. global) variables when performing beta reduction.)
• Scheme (1975). Untyped. Eager.
• ML (Milner, 1974). Typed. Eager. A more efficient version (Standard ML), using garbage collection, was implemented in 1985.
• CLOS (1988). Eager. Integrates the Functional and the Object-Oriented paradigms.
• HHaskell (1990). (Named after Curry!) Typed. Lazy.

# Typed Lambda Calculus

There are two main type systems for the symple typed Lambda Calculus: The system of Curry (1934) and the system of Church (1940).

## The Type System of Curry

Hystorical note: Haskell Curry lived in State College and worked at the Mathematical Department of Penn State! See the dedication to him at the entrance of the Math building.

In this system, the syntax of Lambda terms is the same as in the untyped version.

The types are defined by the following grammar:

Type ::= TVar           (type variable)
| Type -> Type   (function)

The system allows to derive statements of the following form:

G |- M : A
meaning: under the assumptions G (asociations between lambda variables and types), the lambda term M has type A.

The rules for the Type System are the following:

(var)  ---------------   if x : A is in G
G |- x : A

G |- M : A -> B    G |- N : A
(app)  ----------------------------------
G |- M N : B

G , x : A |- M : B
(abs)  ------------------------
G |- \x. M : A -> B