Que gagnons-nous à avoir des «types dépendants»?

Je pensais avoir bien compris la saisie dépendante (DT), mais la réponse à cette question: /cstheory/30651/why-was-there-a-need-for-martin-l%C3% B6f-to-create-intuitionistic-type-theory m'a fait penser le contraire.

Après avoir lu sur DT et essayé de comprendre ce qu'ils sont, j'essaie de me demander, que gagnons-nous à cette notion de DT? Ils semblent être plus flexibles et plus puissants que le calcul lambda simplement tapé (STLC), bien que je ne puisse pas comprendre exactement "comment / pourquoi".

Que pouvons-nous faire avec les DT qui ne peuvent pas être réalisés avec STLC? On dirait que l'ajout de DT rend la théorie plus compliquée, mais quel est l'avantage?

De la réponse à la question ci-dessus:

Les types dépendants ont été proposés par de Bruijn et Howard qui voulaient étendre la correspondance Curry-Howard de la logique propositionnelle au premier ordre.

Cela semble logique à un certain niveau, mais je ne parviens toujours pas à saisir la vue d'ensemble du «comment / pourquoi»? Peut-être qu'un exemple montre explicitement que cette extension de la correspondance CH à la logique FO pourrait aider à comprendre le problème avec les DT? Je ne suis pas sûr de comprendre cela aussi bien que je le devrais.

logic type-theory intuition Doctorat
la source

Les avez-vous recherchés sur Google? Avez-vous entendu parler de Coq, un prouveur de théorèmes basé sur des types dépendants? Saviez-vous que le théorème des 4 couleurs a fait ses preuves en utilisant Coq?

Dave Clarke

Je l'ai fait en fait. Ce qui est difficile pour Google, c'est quel est ce "pouvoir" supplémentaire (faute d'un meilleur mot) que les DT prêtent intuitivement à la théorie des types?

PhD

Pourquoi? Les types dépendants vous permettent de taper plus de programmes tout en étant sûrs pour le type. Comment? En paramétrant des types avec des programmes.

Martin Berger

@MartinBerger - Pouvez-vous s'il vous plaît développer "plus de programmes"? Que puis-je faire ou avoir besoin de plus, d'un point de vue théorique?

PhD

@DaveClarke That Coq, avec ses types fantaisies, a été utilisé pour faire des choses fantaisistes n'implique pas que ces choses fantaisistes nécessitent ces types fantaisistes. Par exemple, Twelf a eu des succès majeurs (comme une preuve d'exactitude de SML), et ce n'est que du second ordre, pas de l'ordre supérieur. J'ai vu des systèmes assez gros prouvés avec une logique de premier ordre uniquement.

Gilles 'SO- arrête d'être méchant'

Réponses:

Élargir mon commentaire: les types dépendants peuvent taper plus de programmes. "Plus" signifie simplement que l'ensemble des programmes typables avec des types dépendants est un surensemble approprié des programmes typables dans le -calculus simplement-typé (STLC). Un exemple serait , les listes de longueur , portant des éléments de type . L'expression est à la fois un programme et une partie d'un type. Vous ne pouvez pas le faire dans le STLC. $\lambda$ $List_{2*3+4}(\alpha)$ $10$ $\alpha$ $2*3+4$

La règle clé qui distingue les types dépendants des types non dépendants est l'application:

\frac{Γ ⊢ M : A \to B Γ ⊢ N : A}{Γ ⊢ M N : B} \frac{Γ ⊢ M : Π x^{A} . B Γ ⊢ N : A}{Γ ⊢ M N : B {N / x}}

$\newcommand{\TYPES}[3]{#1 \vdash #2 : #3} \newcommand{\SUBST}[2]{\{#1/#2\}} \frac{ \TYPES{\Gamma}{\color{red}{M}}{A \rightarrow B} \qquad \TYPES{\Gamma}{\color{red}{N}}{A} }{ \TYPES{\Gamma}{\color{red}{MN}}{B} } \qquad \frac{ \TYPES{\Gamma}{{\color{red}M}}{\Pi x^A. B} \qquad \TYPES{\Gamma}{\color{red}{N}}{A} }{ \TYPES{\Gamma}{{\color{red}{MN}}}{B\SUBST{{\color{red}N}}{x}} }$

Sur la gauche, vous avez le STLC, où les programmes dans les locaux ne «coulent» que dans le programme de la conclusion. En revanche, dans la règle d'application dépendante à droite, le programme de la prémisse de droite «coule» dans le type dans la conclusion . $N$ $^1$

Afin de pouvoir paramétrer les types par des programmes, la syntaxe des types dépendants doit être plus riche, et pour s'assurer que les types sont bien formés, nous utilisons un deuxième «système de typage» appelé types qui contraint les types. Ce système de tri est essentiellement le STLC, mais "un niveau supérieur".

Il existe de nombreuses explications sur les types dépendants. Quelques exemples.

Types dépendants au travail , par Bove et Dybjer.
Types dépendants, par Aspinall et Hofmann.
Programmation typée de façon dépendante dans Agda , par Norell et Chapman.
Lambda Calculi avec types , par Barendregt.

$^1$ ^{En termes de couleurs: avec les types non dépendants, les expressions noires dans la conclusion sont construites à partir d'expressions noires dans les locaux tandis que les expressions rouges dans la conclusion sont construites à partir d'expressions rouges dans les locaux. Avec les types dépendants, les couleurs peuvent être mélangées en ayant des parties noires de la conclusion construites à partir des parties rouges et noires du local.}

Martin Berger
la source

Maintenant, cela a beaucoup de sens. C'était peut-être évident, mais pour une raison quelconque, je ne pouvais pas mettre le doigt dessus. Appréciez le passage du commentaire à la réponse. Malheureusement, la question a été votée pour la fermeture, mais je suis heureux de la réponse :)

PhD

Je ne suis pas fou de votre exemple, car la longueur de la liste est juste quelque chose que vous pouvez effacer en types et faire parler les programmes des listes ordinaires (non indexées). Il pourrait être utile de noter qu'il existe des types qui ne restent pas bien typés après ce type d'effacement, par exemple un programme de type , où et .

A r r n

$\mathrm{Arr}\ n$

A r r 0 = n a t

$\mathrm{Arr}\ 0 = \mathrm{nat}$

A r r (n + 1) = n a t \to A r r n

$\mathrm{Arr}\ (n+1) = \mathrm{nat}\rightarrow\mathrm{Arr}\ n$

cody

@cody, je ne sais pas ce que tu veux dire. Les types dépendants ont (ou peuvent être configurés pour avoir) l'effacement de type dans le sens suivant: pour tous les types P: iff , où est la relation de réduction à l' exécution . (Il s'agit d'une description simplifiée où la fonction d'effacement mappe les programmes avec annotation de type sur les "mêmes" programmes sans annotation.)

P ⇓ V

$P\Downarrow V$

e r a s e (P) ⇓ e r a s e (V)

$erase(P)\Downarrow erase(V)$

⇓

$\Downarrow$

Martin Berger

@MartinBerger: oui dans ce cas je parle d'effacer les dépendances dans les types dépendants pour obtenir des types simples. Le seul exemple que je peux citer en ce moment est la preuve que normalise iff normalise (par exemple dans le livre de Barendregt ).

F_{ω}

$F_\omega$

C o C

$\mathrm{CoC}$

cody

@cody Je pense qu'il est inhabituel d'appeler ce type d'effacement. Quel est un meilleur nom? Peut-être une simplification de type?

Martin Berger

Considérez les déclarations de type comme rien de plus que des assertions. Actuellement, tout ce que vous pouvez dire est des choses comme isInt32 (), isCharPtr (), etc. Ces différentes assertions sont choisies pour être vérifiables au moment de la compilation. Mais ce concept peut être étendu à des choses comme: isCharPtr () && isNotNull (). Les pointeurs nulles sont un énorme problème. Les pointeurs ne doivent pas être annulables comme position par défaut, les pointeurs annulables étant un type qui n'est pas déréférençable sans savoir s'il est nul ou non. Des problèmes similaires sont des choses comme: isPositiveInteger (), ou isEvenNaturalNumber ().

Rob
la source