Pourquoi l'algorithme Hindley-Milner ne donnera-t-il jamais un type comme t1 -> t2?

Je lis à propos de l'algorithme de typage Hindley-Milner lors de l'écriture d'une implémentation, et je vois que, tant que chaque variable est liée, vous obtiendrez toujours des types atomiques ou des types où les arguments détermineront le type final, comme t1 -> t1ou (t1 -> t2) -> (t1 -> t2)où t1et t2sont des variables de type.

Je ne peux pas penser à un moyen d'obtenir quelque chose comme t1 -> t2ou simplement t1, ce qui, je crois, signifierait que l'algorithme est cassé car il n'y aurait aucun moyen de déterminer le type réel de l'expression. Comment savez-vous que vous n'obtiendrez jamais un type tel que ceux "cassés" tant que chaque variable est liée?

Je sais que l'algorithme donne des types avec des variables, mais ceux-ci sont toujours résolus une fois que vous passez les arguments à la fonction, ce qui ne serait pas le cas dans une fonction avec type t1 -> t2. C'est pourquoi je veux savoir comment nous savons avec certitude que l'algorithme ne donnera jamais de tels types.

(Il semble que vous pouvez obtenir ces types "cassés" en ML , mais je pose des questions sur le calcul lambda.)

$\forall \alpha,\beta.\; \alpha\mathbin\rightarrow\beta$$\forall \alpha.\; \alpha\mathbin\rightarrow\alpha$$\lambda x.x$

$\forall \alpha,\beta.\; \alpha\mathbin\rightarrow\beta$$\beta$$\beta$$\beta$$\beta$$\beta$

$\Delta = \lambda x. x \, x$$(\forall \alpha. \alpha) \rightarrow (\forall \alpha. \alpha)$$\Delta\,\Delta$

$\forall A, \forall B, A \Rightarrow B$$\forall \alpha,\beta.\; \alpha\mathbin\rightarrow\beta$

$Y$$Y (\lambda x.x)$$\forall \alpha. \alpha$$\forall A, \forall B, A \Rightarrow B$

Trouver la fine ligne entre les systèmes de types qui assurent une forte normalisation et les systèmes de types qui ne le sont pas est un problème difficile et intéressant. C'est un problème important car il détermine quelles logiques sont saines, c'est-à-dire quels programmes incarnent des preuves de théorèmes. Vous pouvez aller beaucoup plus loin que le système F, mais les règles deviennent plus complexes. Par exemple, le calcul des constructions inductives qui est la base de l' assistant de preuve Coq , est fortement normalisant mais est capable de décrire des structures de données inductives communes et des algorithmes sur eux, et plus encore.

Dès que vous arrivez à de vrais langages de programmation, la correspondance tombe en panne. Les vrais langages de programmation ont des fonctionnalités telles que les fonctions récursives générales (qui ne peuvent pas se terminer), les exceptions (une expression qui déclenche toujours une exception ne renvoie jamais de valeur et peut donc avoir n'importe quel type dans la plupart des systèmes de types), les types récursifs (qui permettent la non-terminaison se faufiler), etc.