Quelles sont les forces et les faiblesses de l'assistant de preuve Isabelle par rapport à Coq?
Est-ce que Isabelle/HOL proof assistant a des faiblesses et des forces par rapport à Coq?
Je connais surtout Coq et je n'ai pas beaucoup d'expérience avec Isabelle/HOL, mais je pourrais peut-être aider un peu. Peut-être que d'autres ayant plus d'expérience sur Isabelle/HOL peuvent aider à améliorer cela.
Il existe deux grands points de divergence entre les deux systèmes: les théories sous-jacentes et le style d'interaction . Je vais essayer de donner un bref aperçu des principales différences dans chaque cas.
Théories
Coq et Isabelle/HOL sont tous deux basés sur des logiques d'ordre supérieur puissantes et très expressives. Ces logiques, cependant, diffèrent sur quelques caractéristiques:
Types dépendants
La logique de Coq est une théorie de type dépendante, connue sous le nom de calcul des constructions inductives ( [~ # ~] cic [~ # ~] pour faire court). "Type dépendant" signifie ici que les types dans Coq peuvent faire référence à des valeurs ordinaires. Par exemple, on peut écrire une fonction de multiplication matricielle mult de type
mult : forall (n m p : nat), matrix n m -> matrix m p -> matrix n p
Le type de cette fonction indique qu'elle prend deux matrices en entrée, l'une de dimension n x m et un autre de dimension m x p, et renvoie une matrice de dimension n x p. La théorie d'Isabelle/HOL, en revanche, ne possède pas de types dépendants; par conséquent, on ne peut pas écrire une fonction mult avec le même type que celle ci-dessus. Au lieu de cela, il faudrait écrire une fonction qui fonctionne pour n'importe quel type de matrice, et prouver a posteriori certaines propriétés de cette fonction lorsqu'elle reçoit des arguments de la bons types. En d'autres termes, certaines propriétés qui se manifestent dans les types Coq doivent être affirmées comme des théorèmes distincts lors du travail sur Isabelle/HOL.
Bien que les types dépendants soient intéressants pour certaines choses, leur utilité en général n'est pas claire. Mon impression est que certains estiment qu'ils sont très compliqués à utiliser et que l'avantage d'avoir certaines propriétés exprimées au niveau du type par rapport à les avoir comme théorèmes séparés ne vaut pas cette complexité supplémentaire. Personnellement, j'aime utiliser des types dépendants dans quelques cas, quand il y a une raison claire de le faire.
Principes de raisonnement de base
Par défaut, la théorie de Coq manque de nombreux principes de raisonnement qui sont courants dans la pratique mathématique, tels que la loi du milieu excl (c'est-à-dire la capacité de raisonner de manière non constructive), l'extensionnalité (par exemple, être capable de disent que les fonctions qui produisent des résultats égaux sont elles-mêmes égales), et l'axiome de choix. Dans Isabelle/HOL, en revanche, ces principes sont intégrés.
En théorie, ce n'est pas un gros problème, car la logique de Coq a été conçue pour permettre aux gens d'ajouter en toute sécurité ces principes de raisonnement en tant qu'axiomes supplémentaires. Néanmoins, j'ai l'impression qu'il est plus facile de faire ce genre de raisonnement sur Isabelle/HOL, puisque la logique a été construite de fond en comble pour les soutenir.
(Vous pouvez vous demander quelle est la raison pour laquelle ces principes de base sont exclus de la logique de Coq. La motivation est philosophique: dans la logique de base de Coq, les preuves peuvent être considérées comme des programmes exécutables, ce qui donne à la logique une saveur constructive. La raison du rejet des exclus au milieu, par exemple, est que la preuve d'une disjonction A \/ B correspond à un programme qui renvoie un bit indiquant lequel de A ou B est vrai; ainsi, le milieu exclu correspondrait à un programme qui déciderait de chaque question mathématique, qui ne peut exister. Cette question discute le problème un peu plus loin.)
Style d'interaction
Coq et Isabelle/HOL sont tous les deux prouveurs de théorèmes interactifs. Ce sont des langages pour écrire des définitions et des preuves à leur sujet; ces preuves sont vérifiées par un ordinateur pour s'assurer qu'elles ne contiennent pas d'erreurs. Dans les deux systèmes, on écrit une preuve en donnant des commandes qui expliquent comment prouver quelque chose. Cependant, la façon dont cela se produit sur chaque système varie.
Isabelle/HOL a généralement une prise en charge plus mature de l'automatisation de la preuve "bouton-poussoir". Par exemple, il est livré avec la célèbre tactique sledgehammer, qui invoque plusieurs prouveurs et solveurs de théorèmes automatiques externes pour essayer de prouver un théorème. Coq est également livré avec de nombreuses procédures d'automatisation de preuve puissantes, telles que omega ou congruence, mais elles ne sont pas aussi généralement applicables, et de nombreux théorèmes qui peuvent être résolus avec une seule commande dans Isabelle/HOL nécessitent des preuves plus explicites dans Coq.
Bien sûr, cette commodité a un prix. On m'a dit qu'il est plus difficile de contrôler sa preuve dans Isabelle/HOL car le système essaie de faire beaucoup par lui-même. Ce n'est pas un problème lors de la démonstration de théorèmes simples, mais cela devient un problème lorsque l'automatisation de la preuve n'est pas suffisamment puissante et que vous devez indiquer au prouveur de théorèmes comment procéder plus en détail.
La situation est un peu différente lors de la prise en charge de procédures d'automatisation de la preuve définies par l'utilisateur. Coq est livré avec un langage tactique pour écrire des preuves, connu sous le nom de Ltac, qui est un langage de programmation à part entière. Même si Ltac a quelques problèmes de conception, il permet aux utilisateurs de coder des procédures d'automatisation de preuve assez compliquées de manière légère. Pour les tâches plus lourdes, Coq permet également aux utilisateurs d'écrire des plugins dans le langage d'implémentation de Coq, OCaml. Dans Isabelle/HOL, en revanche, il n'y a pas de langage d'automatisation de niveau supérieur comme Ltac, et la seule façon dont l'utilisateur peut programmer des procédures d'automatisation d'épreuves personnalisées est avec des plugins.
Un aspect, que je vais illustrer, de l'efficacité "bouton-poussoir" d'Isabelle/HOL est son automatisation de l'argument classique de "diagonalisation" de Cantor (rappelons que cela indique qu'il n'y a pas de les naturels à son alimentation, ou plus généralement tout à son alimentation).
theorem Cantor: "∄f :: 'a ⇒ 'a set. ∀A. ∃x. A = f x"
proof
assume "∃f :: 'a ⇒ 'a set. ∀A. ∃x. A = f x"
then obtain f :: "'a ⇒ 'a set" where *: "∀A. ∃x. A = f x" ..
let ?D = "{x. x ∉ f x}"
from * obtain a where "?D = f a" by blast
moreover have "a ∈ ?D ⟷ a ∉ f a" by blast
ultimately show False by blast
qed
Ce que je viens de vous présenter serait la traduction de l'argument classique de Cantor en Isabelle/HOL. Sans doute, ingénieux! Isabelle/HOL peut automatiser la compréhension de même cette preuve, cependant:
theorem "∄f :: 'a ⇒ 'a set. ∀A. ∃x. f x = A"
by best
theorem "∄f :: 'a ⇒ 'a set. ∀A. ∃x. f x = A"
by force
Le système de preuve est capable de prouver automatiquement la déclaration de Cantor. Pour un chercheur, d'une part, cela est utile, mais il y a un sens dans lequel il s'agit d'une épée à double tranchant. Je peux trouver utile que des déclarations vraies aussi complexes qu'un argument de diagonalisation puissent être fiables pour être prouvées en interne à Isabelle/HOL, car mes théorèmes sont ainsi plus sophistiqués. D'un autre côté, au fur et à mesure que j'avance dans mes recherches en m'inspirant des progrès automatisables de l'ordinateur, je peux de moins en moins expliquer pourquoi ou pour quel principe le théorème est vrai. Seul l'ordinateur sait pourquoi, si seulement nous pouvons le lui demander!
Comme "Isabelle/HOL" est précisé dans la question, je vais parler de la logique HOL utilisée dans Isabelle qui je pense est la meilleure à utiliser pour une comparaison avec Coq. Je ne suis pas un expert en systèmes de types et en logique, mais je pense que ce que je dis ici est correct, au moins approximativement. C'est aussi certainement une question de goût ;-) et ma réponse peut être subjective.
Les différences les plus profondes résident dans les systèmes de types et les logiques.
Je dirais que la force est d'être plus naturelle pour quelqu'un qui connaît un langage fonctionnel de la famille ML (et encore plus pour quelqu'un qui connaît SML) et qu'elle utilise une approche pragmatique pour résoudre des problèmes comme par exemple l'utilisation d'une logique classique comme une base. Son système de type est proche de celui de Hindley Milner et se termine par défaut (s'il n'est pas modifié par l'utilisateur).
En revanche, Coq est plus strict et utilise une logique intuitionniste. Il a un système de type spécialisé avec plusieurs commandes et permet des dépendances de type qui peuvent être plus difficiles à gérer et peuvent ne pas se terminer dans certaines circonstances. Il permet également d'extraire des programmes de preuves (qui peuvent être relativement inefficaces) ce qui n'est pas directement possible dans Isabelle.