Warum liefert der Hindley-Milner-Algorithmus niemals einen Typ wie t1 -> t2?

Ich lese beim Schreiben einer Implementierung etwas über den Hindley-Milner-Typisierungsalgorithmus und sehe, dass Sie, solange jede Variable gebunden ist, immer entweder atomare Typen oder Typen erhalten, bei denen die Argumente den endgültigen Typ bestimmen, z. B. t1 -> t1oder (t1 -> t2) -> (t1 -> t2)wo t1und t2ist vom Typ Variablen.

Ich kann mir keine Möglichkeit vorstellen, wie Sie so etwas t1 -> t2oder einfach so bekommen t1, was meiner Meinung nach bedeuten würde, dass der Algorithmus kaputt ist, da es keine Möglichkeit geben würde, den tatsächlichen Typ des Ausdrucks zu bestimmen. Woher weißt du, dass du niemals einen Typ wie diesen "kaputten" bekommen wirst, solange jede Variable gebunden ist?

Ich weiß, dass der Algorithmus Typen mit Variablen liefert, aber diese werden immer aufgelöst, wenn Sie die Argumente an die Funktion übergeben, was bei einer Funktion mit Typ nicht der Fall wäre t1 -> t2. Aus diesem Grund möchte ich wissen, wie wir sicher wissen, dass der Algorithmus niemals solche Typen liefern wird.

(Es scheint, dass Sie diese "kaputten" Typen in ML bekommen können , aber ich frage nach Lambda-Kalkül.)

In der Lambda-Rechnung ohne Konstanten mit dem Hindley-Milner-Typensystem können Sie keine solchen Typen abrufen, bei denen das Ergebnis einer Funktion eine nicht aufgelöste Typvariable ist. Alle Typvariablen müssen irgendwo einen „Ursprung“ haben. Zum Beispiel gibt es keinen Term vom Typ , aber es gibt einen Term vom Typ ∀ α $\forall \alpha,\beta.\; \alpha\mathbin\rightarrow\beta$ (die Identitätsfunktion λ x . x ).$\forall \alpha.\; \alpha\mathbin\rightarrow\alpha$$\lambda x.x$

Intuitiv ein Term vom Typ $\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$

Es ist ein schwieriges und interessantes Problem, die Grenze zwischen Typsystemen, die eine starke Normalisierung gewährleisten, und Typsystemen zu finden, die dies nicht tun. Es ist ein wichtiges Problem, da es bestimmt, welche Logik korrekt ist, dh welche Programme Beweise für Theoreme enthalten. Sie können viel weiter gehen als System F, aber die Regeln werden komplexer. Beispielsweise normalisiert sich die dem Coq-Proof-Assistenten zugrunde liegende Berechnung induktiver Konstruktionen stark, kann jedoch gemeinsame induktive Datenstrukturen und Algorithmen darüber beschreiben und vieles mehr.

Sobald Sie zu echten Programmiersprachen gelangen, bricht die Korrespondenz zusammen. Reale Programmiersprachen verfügen über Funktionen wie allgemeine rekursive Funktionen (die möglicherweise nicht terminiert werden), Ausnahmen (ein Ausdruck, der immer eine Ausnahme auslöst, gibt niemals einen Wert zurück und kann daher in den meisten Typsystemen einen beliebigen Typ haben) und rekursive Typen (die eine Nichtterminierung zulassen) einschleichen) usw.