Dependent type

Type systems
Type safety Inferred vs. Manifest Dynamic vs. Static Strong vs. Weak Nominal vs. Structural Dependent typing Duck typing Latent typing Linear typing Uniqueness typing

In computer science and logic, a dependent type is a type that depends on a value. Dependent types play a central role in intuitionistic type theory and in the design of functional programming languages like ATS, Agda and Epigram.

An example is the type of n-tuples of real numbers. This is a dependent type because the type depends on the value n.

Deciding equality of dependent types in a program may require computations. If arbitrary values are allowed in dependent types, then deciding type equality may involve deciding whether two arbitrary programs produce the same result; hence type checking becomes undecidable.

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.

Contents 1 Systems of the lambda cube 1.1 First order dependent type theory 1.2 Second order dependent type theory 1.3 Higher order dependently typed polymorphic lambda calculus 1.4 Object-oriented programming 2 Comparison 3 Footnotes 4 See also 5 Further reading 6 References

Systems of the lambda cube

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

The system 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.

Writing for -tuples of real numbers, as above, stands for the type of functions which given a natural number n returns 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. is the type of functions from natural numbers to the real numbers, written as in the simply typed lambda calculus.

Second order dependent type theory

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

Higher order dependently typed polymorphic lambda calculus

The higher order system extends 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.

Object-oriented programming

Some recent research^[1] has been directed at combining dependent type theory with object-oriented programming.

Comparison

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[2]	Purely functional	Few/limited[fn 3]	Yes	Yes (optional)	Any term	Yes (optional)[fn 4]	Proof-irrelevant arguments (experimental)[4]	Haskell	Yes[4]
ATS	Yes[5]	Functional / imperative	No[6]	Yes	Yes	?	?	?	Yes	?
Cayenne	No	Purely functional	No	Yes	No	Any term	No	No	?	?
Coq	Yes[7]	Purely functional	Yes	Yes	Yes	Any term	Yes[fn 5]	Yes	Haskell, Scheme and ML	Yes
Dependent ML	No[fn 6]	?	?	Yes	?	Natural numbers	?	?	?	?
Epigram 2	Yes[8]	Purely functional	No	Coming soon	By construction	Any term	Coming soon	Coming soon	Coming soon	Coming soon
Guru [1]	Yes[9]	Purely functional[10]	hypjoin[11]	Yes[10]	Yes	Any term	No	Yes	Carraway	Yes
Idris [2]	Yes[12]	Purely functional[13]	Yes[14]	Yes	Coming soon	Any term	No	No	Yes	Yes, aggressively[14]
Matita [3]	Yes[15]	Purely functional	Yes	Yes	Yes	Any term	Yes	?	O'Caml	?
NuPRL	No	?	?	?	?	?	?	?	Yes	?
PVS	?	?	Yes	?	?	?	?	?	?	?
Sage [4]	?	Hybrid typechecking	?	?	?	?	?	?	?	?
Twelf	Yes	Logic programming	?	Yes	Yes (optional)	Any (LF) term	No	No	?	?
Xanadu [5]	No[16]	Imperative	?	?	?	?	?	?	?	?

Footnotes

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^[3]
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

See also

• Typed lambda calculus

Further reading

• H. Barendregt (1992). "Lambda calculi with types". In S. Abramsky, D. Gabbay and T. Maibaum. Handbook of Logic in Computer Science. Oxford Science Publications. ftp://ftp.cs.ru.nl/pub/CompMath.Found/HBK.ps. 
• Why Dependent Types Matter T. Altenkirch, C. McBride, J. McKinna

References