Dependent type

From Wikipedia, the free encyclopedia
Jump to: navigation, search

In computer science and logic, a dependent type is a type that depends on a value. It is an overlapping feature of math-encoding type theory and bug-stopping type systems. In intuitionistic type theory, dependent types are used to encode logic's quantifiers like "for all" and "there exists". In functional programming languages like ATS, Agda, Idris and Epigram, dependent types prevent bugs by allowing very expressive types.




Dependent types were created to deepen the connection between programming and logic.

In 1934, Haskell Curry noticed that the types used in mathematic programming languages followed the same pattern as axioms in propositional logic. Going further, for every proof in the logic, there was a matching function (term) in the programming language. One of Curry's examples was the correspondence between simply typed lambda calculus and intuitionistic logic.[1]

Predicate logic is an extension of propositional logic, adding quantifiers. Howard and de Bruijn extended lambda calculus to match this more powerful logic by creating types for dependent functions, which correspond to "for all", and dependent pairs, which correspond to "there exists".[2]

(Because of this and other work by Howard, propositions-as-types is known as the Curry-Howard correspondence.)

Formal definition[edit]

Dependent types can be, very loosely speaking, imagined to be similar to the type of an indexed family of sets. More formally, given a type A:\mathcal{U} in a universe of types \mathcal{U}, one may have a family of types B:A\to\mathcal{U} which assigns to each term a:A a type B(a):\mathcal{U}. A function whose codomain varies depending on its argument is a dependent function, and the type of this function is called a dependent type, dependent product type or pi-type. For this example, the dependent type would be written as


or as

\Pi (x:A),B(x)

If B is a constant, the dependent type becomes an ordinary function A\to B. That is, \Pi_{(x:A)}B is judgementally equal to the function type A\to B.

The name 'pi-type' comes from the idea that these may be viewed as a Cartesian product of types. Pi-types can also be understood as models of universal quantifiers.

For example, writing \mbox{Vec}({\mathbb R},n) for n-tuples of real numbers, then \Pi_{(n:{\mathbb N})} \mbox{Vec}({\mathbb R},n) would be the type of functions which, given a natural number n, return a tuple of real numbers of size n. The usual function space arises as a special case when the range type does not actually depend on the input, e.g. \Pi_{(n:{\mathbb N})}\; {\mathbb R} is the type of functions from natural numbers to the real numbers, which is written as {\mathbb N}\to{\mathbb R} in the simply typed lambda calculus.

Polymorphic functions are an important example of dependent functions, that is, functions having dependent type. Given a type, these functions act on elements of that type (or on elements of a type constructed (derived, inherited) from that type). A polymorphic function returning elements of type C would have a polymorphic type written as

\Pi_{(A:\mathcal{U})} A\to C

Dependent pair type[edit]

The opposite of the dependent type is the dependent pair type, dependent sum type or sigma-type. It is analogous to the coproduct or disjoint union. Sigma-types can also be understood as models of existential quantifiers. Notationally, it is written as

\Sigma_{(x:A)} B(x)

The dependent pair type captures the idea of a pair, where the type of the second term is dependent on the first. Thus, if

(a,b):\Sigma_{(x:A)} B(x)

then a:A and b:B(a). If B is a constant, then the dependent pair type becomes (is judgementally equal to) the product type, that is, an ordinary Cartesian product A\times B.

Systems of the lambda cube[edit]

Henk Barendregt developed the lambda cube as a means of classifying type systems along three axes. The eight corners of the resulting cube-shaped diagram each correspond to a type system, with simply typed lambda calculus in the least expressive corner, and calculus of constructions in the most expressive. The three axes of the cube correspond to three different augmentations of the simply typed lambda calculus: the addition of dependent types, the addition of polymorphism, and the addition of higher kinded type constructors (functions from types to types, for example). The lambda cube is generalized further by pure type systems.

First order dependent type theory[edit]

The system \lambda \Pi of pure first order dependent types, corresponding to the logical framework LF, is obtained by generalising the function space type of the simply typed lambda calculus to the dependent product type.

Second order dependent type theory[edit]

The system \lambda \Pi 2 of second order dependent types is obtained from \lambda \Pi by allowing quantification over type constructors. In this theory the dependent product operator subsumes both the \to operator of simply typed lambda calculus and the \forall binder of System F.

Higher order dependently typed polymorphic lambda calculus[edit]

The higher order system \lambda \Pi \omega extends \lambda \Pi 2 to all four forms of abstraction from the lambda cube: functions from terms to terms, types to types, terms to types and types to terms. The system corresponds to the Calculus of constructions whose derivative, the calculus of inductive constructions is the underlying system of the Coq proof assistant.

Simultaneous Programming language and Logic[edit]

The Curry–Howard correspondence implies that types can be constructed that express arbitrarily complex mathematical properties. If the user can supply a constructive proof that a type is inhabited (i.e., that a value of that type exists) then a compiler can check the proof and convert it into executable computer code that computes the value by carrying out the construction. The proof checking feature makes dependently typed languages closely related to proof assistants. The code-generation aspect provides a powerful approach to formal program verification and proof-carrying code, since the code is derived directly from a mechanically verified mathematical proof.

Comparison of languages with dependent types[edit]

Language Actively developed Paradigm[fn 1] Tactics Proof terms Termination checking Types can depend on[fn 2] Universes Proof irrelevance Program extraction Extraction erases irrelevant terms
Agda Yes[3] Purely functional Few/limited[fn 3] Yes Yes (optional) Any term Yes (optional)[fn 4] Proof-irrelevant arguments (experimental)[5] Haskell, Javascript Yes[5]
ATS Yes[6] Functional / imperative No[7] Yes Yes ? ? ? Yes ?
Cayenne No Purely functional No Yes No Any term No No ? ?
Coq Yes[8] Purely functional Yes Yes Yes Any term Yes[fn 5] No Haskell, Scheme and OCaml Yes
Dependent ML No[fn 6] ? ? Yes ? Natural numbers ? ? ? ?
Guru No[9] Purely functional[10] hypjoin[11] Yes[10] Yes Any term No Yes Carraway Yes
Idris Yes[12] Purely functional[13] Yes[14] Yes Yes (optional) Any term Yes No Yes Yes, aggressively[14]
Matita Yes[15] Purely functional Yes Yes Yes Any term Yes Yes OCaml Yes
NuPRL Yes Purely functional Yes Yes Yes Any term Yes ? Yes ?
F* Yes Functional /imperative ? ? ? ? ? ? ? ?
PVS Yes ? Yes ? ? ? ? ? ? ?
Sage ? Hybrid typechecking ? ? ? ? ? ? ? ?
Twelf Yes Logic programming ? Yes Yes (optional) Any (LF) term No No ? ?
Xanadu No[16] Imperative ? ? ? ? ? ? ? ?

See also[edit]


  1. ^ This refers to the core language, not to any tactic or code generation sublanguage.
  2. ^ Subject to semantic constraints, such as universe constraints
  3. ^ Ring solver[4]
  4. ^ Optional universes, optional universe polymorphism, and optional explicitly specified universes
  5. ^ Universes, automatically inferred universe constraints (not the same as Agda's universe polymorphism) and optional explicit printing of universe constraints
  6. ^ Has been superseded by ATS


Further reading[edit]