Le compilateur pour le type dépendant est-il beaucoup plus difficile qu'un interprète?


11

J'ai appris quelque chose sur l'implémentation de types dépendants, comme ce tutoriel , mais la plupart d'entre eux implémentent des interprètes. Ma question est, il semble que l'implémentation d'un compilateur pour le type dépendant soit beaucoup plus difficile qu'un compilateur, car vous pouvez vraiment évaluer les arguments de type dépendant pour la vérification de type.

Donc

  • Mon impression naïve est-elle juste?
  • Si c'est le cas, des exemples / ressources sur l'implémentation d'un langage à vérification statique prenant en charge le type dépendant

Non, car vous pouvez réduire le problème de compilation des types dépendants à un problème connu: (1) vérifier le programme à l'aide d'un interpréteur; (2) extraire le programme vers OCaml / Haskell / autre; (3) compiler en utilisant ocamloptou GHC :-) (Ceci est d'ailleurs l'approche Coq et Agda.)
xrq

Réponses:


12

C'est une question intéressante! Comme le suggère la réponse d'Anthony, on peut utiliser les approches habituelles pour compiler un langage fonctionnel non dépendant, à condition d'avoir déjà un interprète pour évaluer les termes pour la vérification de type .

C'est l'approche adoptée par Edwin Brady. Maintenant, c'est conceptuellement plus simple, mais cela perd les avantages de vitesse de la compilation lors de la vérification de type. Ce problème a été résolu de plusieurs manières.

Tout d'abord, on peut implémenter une machine virtuelle qui compile les termes en octet-code à la volée pour effectuer le contrôle de conversion. C'est l'idée derrière vm_computemise en œuvre dans Coq par Benjamin Gregoire . Apparemment, il y a aussi cette thèse de Dirk Kleeblatt sur ce sujet précis, mais en bas du code machine réel plutôt que d'une machine virtuelle.

Deuxièmement, on peut générer du code dans un langage plus conventionnel qui, lors de l'exécution, vérifie toutes les conversions nécessaires pour vérifier par type un programme typé de manière dépendante. Cela signifie que nous pouvons utiliser Haskell, par exemple, pour effectuer une vérification de type d'un module Agda. Le code peut être compilé et exécuté, et s'il accepte, alors le code dans le langage de type dépendant peut être supposé être bien typé (à l'exception des erreurs d'implémentation et de compilation). J'ai d'abord entendu cette approche suggérée par Mathieu Boesflug .


1
Un peu ironique: pourquoi prendriez-vous la peine d'écrire un compilateur si vous avez un interprète qui fait la vérification de type? Après tout, la plupart (tous?) Des utilisateurs sérieux de langages de programmation typés de manière dépendante ne se soucient que du vérificateur de type, utilisant le langage comme assistant de vérification. Je n'ai certainement jamais exécuté aucun de mes programmes Agda ou Coq. Donc, si vous vous souciez de la vitesse, ne voudriez-vous pas compiler les conversions de types?
Martin Berger

2
Les solutions 2 et 3 résolvent ce problème: vous compilez du code qui vérifie le bon typage (et en particulier effectue les conversions de type). Ma deuxième remarque est que vous voulez réellement exécuter du code typé de manière dépendante dans certaines situations (voir Idris, Ur / Web).
cody

1
Aussi: dans une certaine mesure, la solution 1 y répond aussi, en brouillant les lignes entre interprète et compilateur.
cody

1
Je me demande si la technique des projections futurama pourrait être utilisée pour accélérer l'interpréteur, aboutissant effectivement à un compilateur?
Steven Shaw

1
La seule chose que j'ai vue est Unison unisonweb.org/2017-10-13/scala-world.html
Steven Shaw

10

La thèse de doctorat d' Edwin Brady explique comment construire un compilateur pour un langage de programmation typé de manière dépendante. Je ne suis pas un expert, mais je dirais que ce n'est pas extrêmement difficile que d'implémenter un compilateur de type System F. Beaucoup de principes sont assez similaires et certains sont les mêmes (par exemple, compilation de supercombinateurs.) La thèse couvre de nombreuses autres préoccupations.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.