Quels sont les problèmes pratiques liés aux types d'intersection et d'union?

Je conçois un langage de programmation fonctionnel simple typé statiquement comme une expérience d'apprentissage.

Il semble que le système de types que j'ai mis en place jusqu'à présent puisse (avec un peu de travail supplémentaire) incorporer des types d'intersection et d'union, par exemple vous pourriez avoir:

• <Union String Integer>
• <Union Integer Foo>
• L'intersection des deux types ci-dessus serait une plaine Integer
• L'union des deux types serait <Union String Integer Foo>

Le fait que cela soit possible, bien sûr, ne signifie pas nécessairement que c'est une bonne idée de conception. En particulier, je suis quelque peu préoccupé par les difficultés de mise en œuvre de garder les types disjoints et / ou de gérer les chevauchements.

Quels sont les avantages / inconvénients de l'intégration de telles fonctionnalités dans le système de saisie?

Voici quelques éléments à garder à l'esprit:

• Bien que nous pensons généralement que nous savons ce que nous entendons par intersection ensembliste et de l' union, il y a eu plusieurs différentes sur ce qu'est exactement l' intersection et les types syndicaux sont . Donc, cela vaut la peine de le préciser avant de vous lancer dans une implémentation.
• $S \sqsubset A$"as" affine ") alors que les règles de formation pour les produits et sommes ordinaires sont $S$$A$ $$\frac{S\sqsubset A \quad T \sqsubset A}{S\cap T\sqsubset A}\qquad \frac{S\sqsubset A \quad T \sqsubset A}{S\cup T\sqsubset A}$$ $$\frac{S\sqsubset A \quad T \sqsubset B}{S* T\sqsubset A*B}\qquad \frac{S\sqsubset A \quad T \sqsubset B}{S+T\sqsubset A+B}$$
• Comme les intersections et les unions peuvent être utilisées pour faire des assertions plus précises sur le comportement à l'exécution d'un programme, il est naturel que le typage devienne sensible à l'ordre d'évaluation. Par exemple, les articles (2) et (4) ci-dessous expliquent pourquoi les règles de typage et de sous-typage "évidentes" (et assez standard) pour les intersections et les unions sont en fait peu valables pour les langages de type ML (en raison de la présence d'effets secondaires et Résiliation). Tu étais prévenu!
• Pour des raisons similaires, l'inférence de type globale devient généralement impraticable ou indécidable. En effet, tout le concept de "type principal" est sans doute un redingue, car une fonction peut satisfaire de nombreuses propriétés différentes qui ne sont pas pertinentes pour son utilisation prévue (par exemple, " foo prend des nombres premiers à des nombres supérieurs à 7"). Au lieu de cela, les approches pratiques des intersections et des unions (voir (3) , (4) ) sont généralement basées sur une combinaison d'inférence et de vérification.

Je suppose que certains des points ci-dessus peuvent sembler négatifs, bien que je ne les qualifierais pas de "contre" mais simplement de "réalités" des types d'intersection et d'union. D'un autre côté, du point de vue de la conception du langage, l'une des raisons pour lesquelles nous nous efforçons de soutenir les intersections et les unions (et de les obtenir correctement!) Est qu'elles permettent d'exprimer les propriétés plus précises des programmes de manière assez incrémentielle, nécessitant une transformation beaucoup moins drastique que, disons, la théorie des types dépendants.

Une brève liste de lecture:

1. Conception du langage de programmation Forsythe par John C. Reynolds
2. Types d'intersections et effets computationnels par Rowan Davies et Frank Pfenning
3. Vérification pratique de type raffinement par Rowan Davies (dissertation)
4. Vérification typographique tridirectionnelle par Joshua Dunfield et Frank Pfenning