Quelle est la différence entre les preuves et les programmes (ou entre les propositions et les types)?

Étant donné que la correspondance Curry-Howard est si largement diffusée / étendue, y a-t-il une différence entre les preuves et les programmes (ou entre les propositions et les types)? Pouvons-nous vraiment les identifier?

Les langages de programmation que les gens utilisent au jour le jour ne correspondent pas si bien à la correspondance de Curry-Howard, car leurs systèmes de types sont trop faibles. Pour dire quelque chose d'intéressant en utilisant Curry-Howard pour les programmes impératifs, il faut avoir un système de type plus sophistiqué. Le livre Adapting Proofs-as-programmes pousse cet angle dans le but de synthétiser les programmes impératifs. Les types dépendants devenant de plus en plus populaires, certainement dans les langages fonctionnels de recherche ( Agda , Epigram ), la distinction devient plus floue. Bien sûr, vous pouvez faire la synthèse / extraction de programme dans le prouveur de théorème Coq (et probablement d'autres), qui est bien sûr basé sur Curry-Howard.

La correspondance Curry-Howard peut également être utilisée dans des situations où les preuves ne correspondent pas aussi clairement aux programmes (ou ce ne sont pas des programmes que quiconque exécutera jamais). Un exemple de ceci est dans l' autorisation de porter une preuve . Les propositions correspondent à des déclarations sur qui est autorisé à faire quoi. Les preuves fournissent les preuves requises qu'une proposition contient, donc une demande d'autorisation est autorisée. Afin d'encoder les preuves, des termes de preuve sont introduits (via Curry-Howard). Les conditions de preuve sont envoyées entre les parties comme représentations de preuves de la validité des demandes d'autorisation, mais elles ne sont pas considérées comme des programmes.

Dans Coq, il existe 2 types (Prop et Set), ils sont utilisés par le programmeur pour séparer les preuves qui ne produiront pas de code réel et la partie de la preuve qui sera utilisée pour extraire le code en cours d'exécution (votre programme).

C'est une bonne solution pour le problème que vous posez, comment identifier ce qui est censé générer le code machine (programme) et ce qui est présent pour compléter la preuve de la proposition (ou type).

AFAIK il n'y a pas de moyen automatique de distinguer les deux. Cela pourrait être quelque chose d'intéressant pour la recherche? Ou peut-être que quelqu'un est en mesure de souligner que c'est clairement impossible?

Avec les types dépendants, non seulement il n'y a pas de distinction claire entre les preuves et les programmes, mais il n'y a pas non plus de distinction entre les programmes et les types! La seule distinction sera l'endroit où le type (ou le programme) apparaîtra, en faisant partie du lieu "programme" ou du lieu "type" d'un terme donné.

Un exemple le rendra plus clair j'espère:

Lorsque vous utilisez la fonction d'identité avec des types dépendants, vous devez transmettre le type avec lequel vous allez utiliser la fonction! Le type est utilisé comme valeur dans votre "programme"!

Calcul lambda non typé:

id =$\lambda{x}.x$

Avec des types dépendants:

id: (A: Set) -> A -> A

id =$(\lambda{A}.(\lambda{x}.x))$

Si vous utilisez cette fonction, vous le feriez comme cet exemple:

id Naturals 1

Notez que le "type" (dans ce cas l'ensemble de produits naturels) transmis en tant que valeur est jeté de sorte qu'il ne sera jamais calculé, mais il se trouve toujours dans la partie "programme" du terme. C'est ce qui se passera également avec les pièces "preuves", elles doivent être là pour que le terme vérifie le type mais pendant le calcul, elles seront jetées.

Je vais sortir sur un membre ici et dire que, si vous êtes prêt à plisser les yeux un peu, les preuves et les programmes de terminaison peuvent être identifiés.

Tout programme de terminaison est une preuve que vous pouvez prendre son entrée et produire sa sortie. Il s'agit d'un type de preuve d'implication très basique.

Bien sûr, pour que cette implication porte des informations plus significatives que pour énoncer l'évidence, vous devez être en mesure de montrer que le programme fonctionne pour toutes les instances d'entrée dessinées dans une classe ayant une signification logique. (Et aussi pour la sortie.)

De l'autre côté, toute preuve avec des étapes d'inférence finies est un programme symbolique manipulant des objets dans un système logique. (Si nous ne nous soucions pas trop de ce que les symboles logiques et les règles signifient par calcul.)

Les types et les propositions peuvent fonctionner de manière similaire. N'importe quel type T peut être affecté à la proposition avec des conditions de vérité évidentes. Toute proposition peut être transformée en type de preuves.$\exists x : x \vdash T$

C'est assez simpliste, mais je pense que cela suggère la robustesse de l'idée. (Même si certaines personnes ne vont pas l'aimer. ;-))

Preuve de non pertinence?

Lorsque vous écrivez un certain programme, vous êtes intéressé à ses performances, la consommation de mémoire , etc.
Par exemple , il est préférable de sorte utiliser un algorithme de tri intelligent au lieu de bulle, même si leur mise en œuvre ont les mêmes types (même dans les paramètre de type dépendant).

Mais lorsque vous prouvez un théorème, ce n'est que l'existence d'une preuve qui vous intéresse.

Bien sûr, du point de vue esthétique, certaines épreuves sont plus simples / belles / inspirantes / etc. (par exemple les épreuves du Livre).

Si vous acceptez la correspondance Curry-Howard, la question est principalement philosophique. "Les preuves et les programmes sont-ils différents? Bien sûr. Comment? Eh bien, nous appelons les preuves les" preuves "et nous appelons les programmes les" programmes "."

Ou, pour le dire avec moins de désinvolture, s'il y a un isomorphisme entre les preuves et les programmes - ce qui semble clairement le cas - alors votre question est de savoir s'il existe un oracle capable de distinguer les deux. Les humains les classent comme étant différents (pour la plupart), il est donc certainement discutable qu'un tel oracle existe. La question importante est alors de savoir s'il existe une différence significative entre eux, ce qui est à débattre philosophiquement. Qu'est-ce qu'une "preuve"? Il n'y a pas de définition formelle de ce qui constitue une preuve; c'est un terme d'art, un peu comme la notion de «effectivement calculable» dans la thèse de Church-Turing. D'ailleurs, "programme" n'a pas non plus de définition formelle.

Ce sont des mots de langage naturel utilisés pour classer différents domaines de recherche mathématique. Ce que Curry et Howard ont observé, c'est que ces deux domaines différents étudiaient en fait la même chose. Il est important de remarquer cette connexion, car elle dit que ces différents chercheurs devraient se parler. Mais à un autre niveau, remarquer la connexion, c'est nier la différence entre eux. Lors de la résolution d'un problème, il est parfois plus avantageux de le considérer comme un problème de programmation, tandis que d'autres fois, il est plus avantageux de le considérer comme un problème logique. Cette différence de perspective est, je pense, la différence importante entre eux. Mais si une différence de perspective constitue une différence d'identité est une question philosophique profonde qui a été explorée au moins aussi loin que FregeUeber Sinn und Bedeutung .