Introducción a la teoría de tipos de Martin-Löf

36

¿Cuál sería la mejor introducción a las ideas de Per Martin-Löfs sobre la teoría de tipos? He visto algunas conferencias de la escuela de verano de Oregon PL, pero todavía me sorprende la siguiente pregunta:

¿Qué es un tipo?

Sé lo que es un conjunto, ya que puedes definirlos mediante los axiomas ZF habituales y tienen un modelo concreto muy intuitivo; solo piensa en una canasta llena de cosas. Sin embargo, todavía no he visto una definición razonable de un tipo y me preguntaba si hay alguna fuente que destile esta idea para el ficticio.

logic type-theory

— dst
fuente

44

El libro de HoTT tiene una introducción que compara tipos y conjuntos, quizás eso ayude, vea la Sección 1.1 de homotopytypetheory.org/book . Pero lo que es más importante, desea que implantemos en su cabeza directamente la idea correcta de los tipos, mientras que para los conjuntos está contento de que los axiomas los describan, sin insistir en saber "qué son realmente". Bueno, los tipos se describen mediante las reglas de inferencia para los tipos. Y tienen un modelo concreto muy intuitivo, ya sabes, un baño lleno de bloques de Lego. Lo que puedas construir de ellos está en el tipo.

— Andrej Bauer

Creo que alejar mi cerebro de la teoría de conjuntos es el mayor problema. Sin embargo, no estoy seguro de cuán buena es la analogía de Lego. ¿Qué son los bloques? Si x: A e y: A normalmente no puedo construir nada de ellos a menos que A sea algún tipo de flecha recursiva. Por supuesto, a menudo puedo mezclar cosas de diferentes tipos para construir algo de un tercer tipo ...

— dst

44

Los bloques de Lego son los constructores tipo. Así, por ejemplo a partir de

y

se puede construir

y

, y

y

. También puede crear nuevos tipos, por ejemplo

y

x : A

$x : A$

y : A

$y : A$

(x, y)

$(x,y)$

(x, x)

$(x,x)$

i n l (x)

$\mathsf{inl}(x)$

{r e l f}_{x}

$\mathsf{relf}_x$

λ z : A . x

$\lambda z : A . x$

I d (x, y)

$\mathsf{Id}(x,y)$

, y así sucesivamente. Las personas tienen diferentes intuiciones sobre los tipos. Sets es uno de ellos, pero crudo. Los tipos también son como espacios topológicos. También son como datos estructurados en la programación. También son como

-groupoids. Esa es la belleza, la riqueza de posibilidades. Elige una posibilidad y corre con ella.

\sum_{z : A} I d (x, z)

$\sum_{z : A} \mathsf{Id}(x,z)$

ω

$\omega$

— Andrej Bauer

31

Un tipo es una propiedad de los cálculos. Es lo que escribes en el lado derecho de un colon.

Déjame elaborar sobre eso. Tenga en cuenta que la terminología no es completamente estándar: algunos artículos o libros pueden usar palabras diferentes para ciertos conceptos.

Un término es un elemento de una sintaxis abstracta que pretende representar el cálculo. Intuitivamente, es un árbol de análisis. Formalmente, es un árbol finito donde los nodos pertenecen a algún alfabeto. Un cálculo sin tipo define una sintaxis para los términos. Por ejemplo, el cálculo lambda (sin tipo) contiene términos (escritos , , etc.) creados a partir de tres tipos de nodos: $M$ $N$

variables, de aridad 0 (una colección numerable de las mismas), escritas , , etc .; $x$ $y$
aplicación de una variable, de aridad 1 (una colección numerable de la misma, con una biyección a variables), escrita , etc .; $\lambda x. M$
aplicación, de arity 2, escrita . $M \, N$

Un término es una construcción sintáctica. Una semántica relaciona los términos con los cálculos. Hay muchos tipos de semántica, la más común es operacional (que describe cómo los términos se pueden transformar en otros términos) o denotacional (que describe los términos mediante una transformación en otro espacio, generalmente construido a partir de la teoría de conjuntos).

Un tipo es una propiedad de los términos. Un sistema de tipos para un cálculo sin tipo describe qué términos tienen qué tipos. Matemáticamente, en el núcleo, un sistema de tipos es una relación entre términos y tipos. Más exactamente, un sistema de tipos es una familia de tales relaciones, indexadas por contextos ; típicamente, un contexto proporciona al menos tipos para variables (es decir, un contexto es una función parcial de variables a tipos), de modo que un término solo puede tener un tipo en contextos que proporcionan un tipo para todas sus variables libres. El tipo de objeto matemático de un tipo depende del sistema de tipos.

Algunos sistemas de tipos se describen con tipos como conjuntos, utilizando nociones de teoría de conjuntos como intersección, unión y comprensión. Esto tiene la ventaja de descansar sobre bases matemáticas familiares. Una limitación de este enfoque es que no permite razonar sobre tipos equivalentes.

Muchos sistemas de tipos describen los tipos mismos como términos en un cálculo de tipos. Dependiendo del tipo de sistema, estos pueden ser los mismos términos o términos diferentes. Usaré el término base de la frase para referirme a un término del cálculo que describe el cálculo. Por ejemplo, el cálculo lambda de tipo simple usa el siguiente cálculo de tipos (escrito , etc.): $\tau$

tipos base, de aridad 0 (una colección finita o numerable de los mismos), escritos , , etc .; $A$ $B$
función, de aridad 2, escrita . $\tau_0 \rightarrow \tau_1$

La relación entre términos y tipos que define el cálculo lambda simplemente tipado generalmente se define mediante reglas de tipeo . Las reglas de escritura no son la única forma de definir un sistema de tipos, pero son comunes. Funcionan bien para sistemas de tipo composicional, es decir, sistemas de tipo donde el tipo (s) de un término se construye a partir de los tipos de subterms. Las reglas de escritura definen inductivamente un sistema de escritura: cada regla de escritura es un axioma que establece que para cualquier instanciación de las fórmulas por encima de la regla horizontal, la fórmula debajo de la regla también es verdadera. Consulte ¿Cómo leer las reglas de escritura? para más detalles. ¿Existe un cálculo lambda tipificado completo de Turing? También puede ser de interés.

Para el cálculo lambda simplemente tipado, el juicio de tipeo significa que tiene el tipo en el contexto . He omitido la definición formal de contextos. $\Gamma \vdash M : \tau$ $M$ $\tau$ $\Gamma$

\frac{x : τ \in Γ}{Γ ⊢ x : τ} (Γ) \frac{Γ, x : τ_{0} ⊢ M : τ_{1}}{Γ ⊢ λ x . M : τ_{0} \to τ_{1}} (\to I) \frac{Γ ⊢ M : τ_{0} \to τ_{1} Γ ⊢ N : τ_{0}}{Γ ⊢ M N : τ_{1}} (\to E)

$\dfrac{x:\tau \in \Gamma}{\Gamma \vdash x : \tau}(\Gamma) \qquad \dfrac{\Gamma, x:\tau_0 \vdash M : \tau_1}{\Gamma \vdash \lambda x.M : \tau_0 \rightarrow \tau_1}(\mathord{\rightarrow}I) \qquad \dfrac{\Gamma \vdash M : \tau_0 \rightarrow \tau_1 \quad \Gamma \vdash N : \tau_0}{\Gamma \vdash M\,N : \tau_1}(\mathord{\rightarrow}E)$

For example, if $A$ and $B$ are based types, then $\lambda x. \lambda y. x\,y$ has the type $(A \rightarrow B) \rightarrow A \rightarrow B$ in any context (from bottom to top, apply $(\mathord{\rightarrow}I)$ twice, then $(\mathord{\rightarrow}E)$ , and finally $(\Gamma)$ on each branch).

It is possible to interpret the types of the simply typed lambda calculus as sets. This amounts to giving a denotational semantics for the types. A good denotational semantics for the base terms would assign to each base term a member of the denotation of all of its types.

Intuitionistic type theory (also known as Martin-Löf type theory) is more complex that simply typed lambda calculus, as it has many more elements in the calculus of types (and also adds a few constants to the base terms). But the core principles are the same. An important feature of Martin-Löf type theory is that types can contain base terms (they are dependent types): the universe of base terms and the universe of types are the same, though they can be distinguished by simple syntactic rules (usually known as sorting, i.e. assigning sorts to terms, in rewriting theory).

There are type systems that go further and completely mix types and base terms, so that there is no distinction between the two. Such type systems are said to be higher-order. In such calculi, types have types — a type can appear on the left-hand side of the $:$ . The calculus of construction is the paradigm of higher-order dependent types. The lambda cube (also known as Barendregt cube) classifies type systems in terms of whether they allow terms to depend on types (polymorphism — some base terms contain types as subterms), types to depend on terms (dependent types), or types to depend on types (type operators — the calculus of types has a notion of computation).

Most type systems have been given set-theoretical semantics, to tie them with the usual foundations of mathematics. How are programming languages and foundations of mathematics related? and What is the difference between the semantic and syntactic views of function types? may be of interest here. There has also been work on using type theory as a foundation of mathematics — set theory is the historic foundation, but it is not the only possible choice. Homotopy type theory is an important milestone in this direction: it describes the semantics of intentional intuitionistic type theory in terms of homotopy theory and constructs set theory in this framework.

I recommend Benjamin Pierce's books Types and Programming Languages and Advances Topics in Types and Programming Languages. They are accessible to any undergraduate with no prerequisite other than basic familiarity with formal mathematical reasoning. TAPL describes many type systems; dependent types are the subject of chapter 2 of ATTAPL.

— Gilles 'SO- stop being evil'
fuente

+1 for TAPL. I was able to teach myself quite a bit about types from reading that book.

— Guy Coder

I'm not sure ATTAPL is a good starting point to learn about dependent types.

— Martin Berger

15

Maybe a better question for somebody coming from set theory and grappling with how set theory and Martin-Löf type theory differ, is to reflect on what sets are. Your intuitions about set theory and the foundations of mathematics will be infected with unquestioned set-theoretic assumptions that you take for granted. Alas Martin-Löf type theory does not share these assumptions.

Contrary to conventional understanding, set theory is a theory of two relations: equality and set membership, not just set membership. And these two relations are built in substantially distinct phases.

We build up first-order logic as a theory of equality of arbitrary things (not just sets). First-order logic uses an informal notion of proof. The concept proof is not itself expressible formally in first-order logic alone.
Then we build up set-theory on top of first-order logic as a theory of sets and set membership.
Set membership and equality are then related by the axiom of extensionality which says that two sets are equal exactly when they have the same members.
Finally, the informal concept of proof from (1) gets an ex-post rationalisation as certain sets (proof trees).

It is important thing to realise is that the notion of proof is thus a second-class citizen in set theory.

This set-up works fine for conventional small/medium sized mathematics, but as we are now tackling large-scale proofs, such as the classification of all finite simple groups, or the verification of non-trivial computer programs, it falls apart, because it does not lead itself to easy mechanisation.

Martin-Löf type theory is different: it builds up the notion of proof and that of type (which, roughly, is to Martin-Löf type theory what sets are to set theory) in one-fell swoop. This means proofs are first-class citizens of the theory. While a set is given by it's members, set theory omits to specify formally what counts as a proof that something is a set member. In contrast a type is given by its proofs of inhabitation. So you understand a type $T$ exactly when you understand what counts as a proof of $T$ .

What are these proofs that inhabit types? Simplifying a bit (and omitting identity types), they are functional programs, more precisely terms in the $\lambda$ -calculus that are typable. This is known as the Curry-Howard correspondence. It gives a beautiful new and less ad-hoc foundation of constructive mathematics. It doesn't work quite so well for classical mathematics tough.

— Martin Berger
fuente

This was extremely useful. I think one major issue of anyone coming into constructive mathematics is to unlearn a lot of things.

— dst

I agree. It takes a while to unlearn one's unacknowledged set-theoretic assumptions. Doing a lot of Agda programming helped me, and might work for you too if you come from a computer science background.

— Martin Berger

10

I'm not aware of easy pathways into Martin-Löf type theory. I guess the following could serve as introductions.

B. Nordström, K. Petersson, J. M. Smith, Martin-Löf's Type Theory.
B. Nordström, K. Petersson, J. M. Smith, Programming in Martin-Löf's Type Theory.

However, if you are puzzled by the question "what is a type", I suggest to get into much simpler type-theories first. Any typed programming language will do, but e.g. Ocaml, F# and Haskell would be especially useful. Simplifying a bit, one could say that Martin-Löf type theory extends the types behind the aforementioned languages in two ways:

With dependent types. You find them in tamer form in various programming languages.
With identity types. This is the main innovation of Martin-Löf's over previous dependent type theories.

The key idea behind dependent types is simple: types can be parameterised by programs. This is not possible (simplifying a bit) in more conventional typing systems such as those mentioned above. While simple, the consequences are profound: dependent types lift the Curry-Howard correspondence to first-order constructive logic. Identity types are a bit unusual. If/when you are comfortable with a language like Haskell, you could learn Agda, which is basically Haskell with Martin-Löf type theory. I feel that Agda is much easier to learn for a programmer than reading the books mentioned above.

— Martin Berger
fuente

I actually know Haskell. My problem is that any tutorial will just tell you how to define types, but never what they actually are. It just seems to be some magic tag attached to all your data, so that the type checker can pick the right version of a polymorphic function and check that things are not mixed in ways that don't make sense. They still leave the question open of what a type is. I'm especially puzzled by this, since Voevodsky & co is trying to base all of math on this, yet, I've never seen a precise definition.

— dst

2

In Haskell you have typing judgements

Γ ⊢ M : α

$\Gamma \vdash M : \alpha$ where

M

$M$ is a program,

α

$\alpha$ is the type of

M

$M$ , assuming that

M

$M$ 's free variables are typed as assumed in the typing environment

Γ

$\Gamma$ . In first approximation, Haskell types themselves are 'blobs', syntactic markers. That's exactly the same in Martin-Löf type theory. It just happens to be the case that the types, the 'blobs', the syntactic markers of Martin-Löf type theory are more complicated than those of Haskell.

— Martin Berger

Types are very precisely defined in Haskell, in Martin-Löf type theory and in Voevodsky's homotopy type theory. There is no ambiguity whatsoever. For example Appendix A.2 gives a proof-system for all terms and types of homotopy type theory. If you want even more rigour, you can look at the Coq or Agda formalisations.

— Martin Berger

2

Maybe you need to swallow that types have no essence other than how they are defined. This is not different with e.g. Sets, they are given by the axioms of set theory. (This is not quite true, but it is nevertheless important to understand.)

— Martin Berger