Relation entre la théorie des types russellienne et les systèmes de types

Je me suis récemment rendu compte qu'il existe une sorte de relation entre la théorie des types russellienne et les systèmes de types, comme par exemple dans Haskell. En fait, une partie de la notation des types dans Haskell semble avoir des précurseurs dans la théorie des types. Mais, à mon humble avis, la motivation de Russell en 1908 était d'éviter le paradoxe de Russell, et je ne sais pas comment cela est lié aux systèmes de types en informatique.

Le paradoxe de Russell sous une forme ou une autre devrait-il nous inquiéter, par exemple, si nous n'avions pas un bon système de caractères dans une langue donnée?

programming-languages type-theory

— Franc
source

Réponses:

La "théorie des types" au sens des langages de programmation et au sens de Russell est étroitement liée. En fait, le domaine moderne de la théorie des types dépendants vise à fournir des bases constructives aux mathématiques. Contrairement à la théorie des ensembles, la plupart des recherches en théorie des types reposent sur les calculs sont effectués dans des assistants de preuve comme Coq, NuPRL ou Agda. En tant que tels, les preuves effectuées dans ces systèmes sont non seulement "formalisables" mais en fait entièrement formelles et vérifiées par machine. En utilisant des tactiques et d'autres techniques d'automatisation des preuves, nous essayons de faire des preuves avec ces systèmes "de haut niveau" et ressemblent donc à des mathématiques informelles, mais parce que tout est vérifié, nous avons de bien meilleures garanties sur l'exactitude.

Voir ici

Les types dans les langages de programmation ordinaires ont tendance à être plus limités, mais la méta-théorie est la même.

Quelque chose de similaire au paradoxe de Russell est un problème majeur dans la théorie des types dépendants. En particulier, avoir

Type : Type

conduit généralement à la contradiction. Coq et travaux similaires en imbriquant des univers

Type_0 : Type_1

mais dans Coq par défaut, ces nombres sont implicites car ils n'ont généralement pas d'importance pour le programmeur.

Dans certains systèmes (Agda, Idris), la règle de type de type est activée via un indicateur de compilation. Cela rend les logiques incohérentes, mais rend souvent la programmation / vérification exploratoire plus facile.

Même dans les langues plus courantes, le paradoxe de Russell apparaît parfois. Par exemple, dans Haskell, un encodage du paradoxe de Russell combinant imprédicativité et cas de type ouvert est possible, permettant de construire des termes divergents sans récursivité même au niveau du type. Haskell est "incohérent" (lorsqu'il est interprété comme une logique de la manière habituelle) car il prend en charge à la fois la récursion de type et de valeur, sans parler des exceptions. Néanmoins, ce résultat est plutôt intéressant.

— Philip JF
source

Merci pour votre réponse détaillée - en ce qui concerne la preuve, il n'y a toujours pas d'outils en vue pour prouver l'exactitude des programmes dans les langages impératifs comme C ++ ou Java, non? Je serais ravi de mettre la main sur l'un d'entre eux ... Je réalise que c'est une tangente complète. Je connais Coq et Agda, mais ils ne semblaient pas être les bons outils pour prouver l'exactitude des programmes écrits en C ++ ou Java.

— Frank

il y a des outils. Quelques-uns pour C, beaucoup pour Java et des tonnes pour Ada. Voir par exemple: Why (Java, C, Ada), Krakatoa (Java) ou SPARK (sous-ensemble Ada avec un très bon outillage). Pour C ++ cependant, pas tellement. Vous pouvez également être intéressé par YNot (Coq DSL).

— Philip JF

Vous avez raison sur la motivation de Russell. Son paradoxe afflige toutes les théories des ensembles qui admettent des axiomes de compréhension sans restriction selon lesquels: toute fonction propositionnelle détermine un ensemble, à savoir celle de toutes les entités qui satisfont la fonction. Parmi les théories de ou basées sur des ensembles qui avaient ce défaut, il y avait la théorie naïve des ensembles de Cantor et le système de Frege de Grundgesetze (en particulier: axiome 5).

Étant donné que les types sont considérés comme des types particuliers d'ensembles, si l'on n'y prend pas garde, un paradoxe similaire peut se glisser dans un système de types. Cela étant dit, je ne connais aucun système de types ayant subi un tel sort. Je ne peux que rappeler les premières tentatives de Church pour formuler le calcul lambda dans les années 30, qui se sont révélées incohérentes (paradoxe de Kleene-Rosser), mais celle-ci n'était ni due aux types ni liée au paradoxe de Russell.

Mise à jour : Voir la réponse de Philip pour une réponse réelle à votre question.

— Hunan Rostomyan
source

Merci pour votre réponse. Il existe probablement des alternatives à types-a-la-Russell pour éviter le paradoxe de Russell. L'une de ces solutions alternatives aurait-elle quelque chose d'intéressant à apporter aux langages informatiques? Les types banals sont très utiles pour spécifier clairement les contrats entre les parties du code, et même avant cela, pour donner une sémantique aux programmes. Y aurait-il d'autres sémantiques qui pourraient être obtenues avec autre chose que des types? (Je n'ai aucune idée de ce que ce serait :-)

— Frank

Oui, beaucoup d'alternatives (NF de Quine, ZFC, etc.), mais je ne vois aucun lien direct entre la crise fondamentale et les langages de programmation. Si vous considérez la théorie des types de Martin Lof comme un langage de programmation, il pourrait y avoir un lien qui remonte à l'intuitionisme. En ce qui concerne la sémantique des langages de programmation, il existe certains langages de base comme PDL (Propositionitional Dynamic Logic) qui ont la sémantique de Kripke (ou mondes possibles). Mais les types me semblent si fondamentaux qu'ils pourraient bien être dans les coulisses :)

— Hunan Rostomyan

Mais les types sont un peu décevants: vous en voulez et vous en avez besoin, mais vous aimeriez ne pas avoir à les spécifier (d'où, à mon humble avis, pourquoi nous avons des systèmes d'inférence de type dans des langues comme Haskell ou Ocaml (j'adore ces langues)). À l'autre extrémité du spectre, Python est très intuitif et il est agréable (et efficace en termes de temps de codage) de ne pas trop se soucier des types dans ce langage. L'inférence de type est peut-être la meilleure des deux mondes - mais c'est l'ingénieur qui parle. Je rêvais juste que les mathématiques pourraient contribuer à un autre concept important (comme les types) en informatique :-)

— Frank

@Frank Chaque fois que j'utilise un langage sans type statique (principalement Ruby), je déteste l'expérience, car je déteste les erreurs d'exécution évitables. Donc, cela semble être une question de goût principalement. Je conviens qu'une inférence de type puissante peut vous donner le meilleur des deux mondes. C'est probablement pourquoi j'aime tant Scala.

— Raphael

Je ne suis pas convaincu que le fait de ne pas avoir de types "automatiquement" entraîne des erreurs d'exécution, comme vous semblez le laisser entendre :-) Je n'ai jamais eu de problème en Python.

— Frank

Puisque vous mentionnez Python, la question n'est pas purement théorique. J'essaie donc de donner une perspective plus large sur les types. Les types sont des choses différentes pour différentes personnes. J'ai collecté au moins 5 notions distinctes (mais liées) de types:

Les systèmes de types sont des systèmes logiques et des théories définies.
Un système de types associe un type à chaque valeur calculée. En examinant le flux de ces valeurs, un système de type tente de prouver ou de s'assurer qu'aucune erreur de type ne peut se produire.
Le type est une classification identifiant l'un des différents types de données, telles que les valeurs réelles, entières ou booléennes, qui détermine les valeurs possibles pour ce type; les opérations qui peuvent être effectuées sur des valeurs de ce type; la signification des données; et la façon dont les valeurs de ce type peuvent être stockées
Les types de données abstraits permettent l'abstraction des données dans des langages de haut niveau. Les ADT sont souvent implémentés sous forme de modules: l'interface du module déclare des procédures qui correspondent aux opérations ADT. Cette stratégie de masquage des informations permet de modifier l'implémentation du module sans perturber les programmes clients.
Les implémentations du langage de programmation utilisent des types de valeurs pour choisir le stockage dont les valeurs ont besoin et des algorithmes pour les opérations sur les valeurs.

Les citations proviennent de Wikipédia, mais je peux fournir de meilleures références en cas de besoin.

Les types-1 sont nés du travail de Russel, mais aujourd'hui ils ne sont pas simplement protégés des paradoxes: le langage typé de la théorie des types d'homotopie est une nouvelle façon d'encoder les mathématiques dans un langage formel et compréhensible par la machine, et une nouvelle façon pour les humains de comprendre les fondements des mathématiques. (L'ancienne méthode consiste à coder en utilisant une théorie des ensembles axiomatiques).

Les types 2 à 5 sont apparus dans la programmation à partir de plusieurs besoins différents: pour éviter les bogues, pour classer les concepteurs de logiciels de données et les programmeurs avec lesquels travailler, pour concevoir de grands systèmes et pour implémenter efficacement les langages de programmation respectivement.

Les systèmes de type en C / C ++, Ada, Java, Python ne sont pas nés du travail de Russel ou d'un désir d'éviter les bugs. Ils sont nés du besoin de décrire différents types de données (par exemple, "le nom de famille est une chaîne de caractères et non un nombre"), de modulariser la conception du logiciel et de choisir de manière optimale les représentations de bas niveau pour les données. Ces langues n'ont pas de types-1 ou types-2. Java garantit une sécurité relative contre les bogues non pas en prouvant l'exactitude du programme en utilisant le système de type, mais en concevant soigneusement le langage (pas d'arithmétique du pointeur) et le système d'exécution (machine virtuelle, vérification du bytecode). Le système de types en Java n'est ni un système logique ni une théorie des ensembles.

Cependant, le système de types dans le langage de programmation Agda est une variante moderne du système de types de Russel (basé sur des travaux ultérieurs ou sur Per Martin-Lof et d'autres mathématiciens). Le système de types dans Agda est conçu pour exprimer les propriétés mathématiques du programme et les preuves de ces propriétés, c'est un système logique et une théorie des ensembles.

Il n'y a pas de distinction noir-blanc ici: de nombreuses langues se situent entre les deux. Par exemple, le système de types du langage Haskell a ses racines dans le travail de Russel, peut être considéré comme un système d'Agda simplifié, mais d'un point de vue mathématique, il est incohérent (auto-contradictoire) s'il est considéré comme un système logique ou une théorie des ensembles.

Cependant, en tant que véhicule théorique pour protéger les programmes Haskell contre les bogues, cela fonctionne plutôt bien. Vous pouvez même utiliser des types pour encoder certaines propriétés et leurs preuves, mais toutes les propriétés ne peuvent pas être encodées, et le programmeur peut toujours violer les propriétés prouvées s'il utilise des hacks sales découragés.

Le système de type de Scala est encore plus éloigné du travail de Russel et du langage de preuve parfait d'Agda, mais a toujours des racines dans le travail de Russel.

Quant à prouver les propriétés des langages industriels dont les systèmes de types n'ont pas été conçus pour cela, il existe de nombreuses approches et systèmes.

Pour des approches intéressantes mais différentes, voir le projet de recherche Coq et Microsoft Boogie. Coq s'appuie sur la théorie des types pour générer des programmes impératifs à partir des programmes Coq. Boogie s'appuie sur l'annotation de programmes impératifs avec des propriétés et prouve ces propriétés avec le prouveur de théorème Z3 en utilisant une approche complètement différente de Coq.

— nponeccop
source