In this article, the symbols and are used to range over types. Informally, the function type refers to the type of functions that, given an input of type , produce an output of type .
By convention, associates to the right: is read as .
To define the types, a set of base types, , must first be defined. These are sometimes called atomic types or type constants. With this fixed, the syntax of types is:
For example, , generates an infinite set of types starting with
A set of term constants is also fixed for the base types. For example, it might assumed that a base type nat, and the term constants could be the natural numbers. In the original presentation, Church used only two base types: for "the type of propositions" and for "the type of individuals". The type has no term constants, whereas has one term constant. Frequently the calculus with only one base type, usually , is considered.
The syntax of the simply typed lambda calculus is essentially that of the lambda calculus itself. The term denotes that the variable is of type . The term syntax, in BNF, is then:
where is a term constant.
That is, variable reference, abstractions, application, and constant. A variable reference is bound if it is inside of an abstraction binding . A term is closed if there are no unbound variables.
In comparison, the syntax of untyped lambda calculus has no such typing or term constants:
Whereas in typed lambda calculus every abstraction (i.e. function) must specify the type of its argument.
To define the set of well-typed lambda terms of a given type, one defines a typing relation between terms and types. First, one introduces typing contexts or typing environments, which are sets of typing assumptions. A typing assumption has the form , meaning has type .
The typing relation indicates that is a term of type in context . In this case is said to be well-typed (having type ). Instances of the typing relation are called typing judgements. The validity of a typing judgement is shown by providing a typing derivation, constructed using typing rules (wherein the premises above the line allow us to derive the conclusion below the line). Simply-typed lambda calculus uses these rules:
If has type in the context, then has type .
Term constants have the appropriate base types.
If, in a certain context with having type , has type , then, in the same context without , has type .
If, in a certain context, has type , and has type , then has type .
Examples of closed terms, i.e. terms typable in the empty context, are:
For every type , a term (identity function/I-combinator),
For types , a term (the K-combinator), and
For types , a term (the S-combinator).
These are the typed lambda calculus representations of the basic combinators of combinatory logic.
Each type is assigned an order, a number . For base types, ; for function types, . That is, the order of a type measures the depth of the most left-nested arrow. Hence:
Intrinsic vs. extrinsic interpretations
Broadly speaking, there are two different ways of assigning meaning to the simply typed lambda calculus, as to typed languages more generally, variously called intrinsic vs. extrinsic, ontological vs. semantical, or Church-style vs. Curry-style.
An intrinsic semantics only assigns meaning to well-typed terms, or more precisely, assigns meaning directly to typing derivations. This has the effect that terms differing only by type annotations can nonetheless be assigned different meanings. For example, the identity term on integers and the identity term on booleans may mean different things. (The classic intended interpretations
are the identity function on integers and the identity function on boolean values.)
In contrast, an extrinsic semantics assigns meaning to terms regardless of typing, as they would be interpreted in an untyped language. In this view, and mean the same thing (i.e., the same thing as ).
The distinction between intrinsic and extrinsic semantics is sometimes associated with the presence or absence of annotations on lambda abstractions, but strictly speaking this usage is imprecise. It is possible to define an extrinsic semantics on annotated terms simply by ignoring the types (i.e., through type erasure), as it is possible to give an intrinsic semantics on unannotated terms when the types can be deduced from context (i.e., through type inference). The essential difference between intrinsic and extrinsic approaches is just whether the typing rules are viewed as defining the language, or as a formalism for verifying properties of a more primitive underlying language. Most of the different semantic interpretations discussed below can be seen through either an intrinsic or extrinsic perspective.
The simply typed lambda calculus (with -equivalence) is the internal language of Cartesian closed categories (CCCs), as was first observed by Joachim Lambek. Given any specific CCC, the basic types of the corresponding lambda calculus are just the objects, and the terms are the morphisms. Conversely, every simply typed lambda calculus gives a CCC whose objects are the types, and morphisms are equivalence classes of terms.
To make the correspondence clear, a type constructor for the Cartesian product is typically added to the above. To preserve the categoricity of the Cartesian product, one adds typing rules for pairing, projection, and a unit term. Given two terms and , the term has type . Likewise, if one has a term , then there are terms and where the correspond to the projections of the Cartesian product. The unit term, of type 1, is written as and vocalized as 'nil', is the final object. The equational theory is extended likewise, so that one has
This last is read as "if t has type 1, then it reduces to nil".
The above can then be turned into a category by taking the types as the objects. The morphisms are equivalence classes of pairs where x is a variable (of type ) and t is a term (of type ), having no free variables in it, except for (optionally) x. Closure is obtained from currying and application, as usual.
More precisely, there exist functors between the category of Cartesian closed categories, and the category of simply-typed lambda theories.
The presentation given above is not the only way of defining the syntax of the simply typed lambda calculus. One alternative is to remove type annotations entirely (so that the syntax is identical to the untyped lambda calculus), while ensuring that terms are well-typed via Hindley–Milner type inference. The inference algorithm is terminating, sound, and complete: whenever a term is typable, the algorithm computes its type. More precisely, it computes the term's principal type, since often an unannotated term (such as ) may have more than one type (, , etc., which are all instances of the principal type ).
Another alternative presentation of simply typed lambda calculus is based on bidirectional type checking, which requires more type annotations than Hindley–Milner inference but is easier to describe. The type system is divided into two judgments, representing both checking and synthesis, written and respectively. Operationally, the three components , , and are all inputs to the checking judgment , whereas the synthesis judgment only takes and as inputs, producing the type as output. These judgments are derived via the following rules:
Observe that rules – are nearly identical to rules (1)–(4) above, except for the careful choice of checking or synthesis judgments. These choices can be explained like so:
If is in the context, we can synthesize type for .
The types of term constants are fixed and can be synthesized.
To check that has type in some context, we extend the context with and check that has type .
If synthesizes type (in some context), and checks against type (in the same context), then synthesizes type .
Observe that the rules for synthesis are read top-to-bottom, whereas the rules for checking are read bottom-to-top. Note in particular that we do not need any annotation on the lambda abstraction in rule , because the type of the bound variable can be deduced from the type at which we check the function. Finally, we explain rules  and  as follows:
To check that has type , it suffices to synthesize type .
If checks against type , then the explicitly annotated term synthesizes .
Because of these last two rules coercing between synthesis and checking, it is easy to see that any well-typed but unannotated term can be checked in the bidirectional system, so long as we insert "enough" type annotations. And in fact, annotations are needed only at β-redexes.
Given the standard semantics, the simply typed lambda calculus is strongly normalizing: that is, well-typed terms always reduce to a value, i.e., a abstraction. This is because recursion is not allowed by the typing rules: it is impossible to find types for fixed-point combinators and the looping term . Recursion can be added to the language by either having a special operator of type or adding general recursive types, though both eliminate strong normalization.
Since it is strongly normalising, it is decidable whether or not a simply typed lambda calculus program halts: in fact, it always halts. We can therefore conclude that the language is notTuring complete.
The unification problem for -equivalence is undecidable. Huet showed in 1973 that 3rd order unification is undecidable and this was improved upon by Baxter in 1978 then by Goldfarb in 1981 by showing that 2nd order unification is already undecidable. A proof that higher order matching (unification where only one term contains existential variables) is decidable was announced by Colin Stirling in 2006, and a full proof was published in 2009.
We can encode natural numbers by terms of the type (Church numerals). Schwichtenberg showed in 1975 that in exactly the extended polynomials are representable as functions over Church numerals; these are roughly the polynomials closed up under a conditional operator.
A full model of is given by interpreting base types as sets and function types by the set-theoretic function space. Friedman showed in 1975 that this interpretation is complete for -equivalence, if the base types are interpreted by infinite sets. Statman showed in 1983 that -equivalence is the maximal equivalence which is typically ambiguous, i.e. closed under type substitutions (Statman's Typical Ambiguity Theorem). A corollary of this is that the finite model property holds, i.e. finite sets are sufficient to distinguish terms which are not identified by -equivalence.
Plotkin introduced logical relations in 1973 to characterize the elements of a model which are definable by lambda terms. In 1993 Jung and Tiuryn showed that a general form of logical relation (Kripke logical relations with varying arity) exactly characterizes lambda definability. Plotkin and Statman conjectured that it is decidable whether a given element of a model generated from finite sets is definable by a lambda term (Plotkin–Statman conjecture). The conjecture was shown to be false by Loader in 2001.