Perché l'algoritmo Hindley-Milner non produrrà mai un tipo come t1 -> t2?

Sto leggendo l'algoritmo di tipizzazione Hindley-Milner mentre scrivo un'implementazione e vedo che, finché ogni variabile è vincolata, otterrai sempre tipi o tipi atomici in cui gli argomenti determineranno il tipo finale, come t1 -> t1o (t1 -> t2) -> (t1 -> t2)dove t1e t2sono variabili di tipo.

Non riesco a pensare a un modo in cui potresti ottenere qualcosa di simile t1 -> t2o semplice t1, che capisco significherebbe che l'algoritmo è rotto poiché non ci sarebbe modo di determinare il tipo effettivo dell'espressione. Come fai a sapere che non otterrai mai un tipo come questi "rotti" fino a quando ogni variabile è vincolata?

So che l'algoritmo produce tipi con variabili, ma questi vengono sempre risolti dopo aver passato gli argomenti alla funzione, il che non sarebbe il caso in una funzione con tipo t1 -> t2. Questo è il motivo per cui voglio sapere come sappiamo per certo che l'algoritmo non produrrà mai tali tipi.

(Sembra che tu possa ottenere questi tipi "rotti" in ML , ma sto chiedendo del calcolo lambda.)

Nel calcolo lambda senza costanti con il sistema di tipi Hindley-Milner, non è possibile ottenere tali tipi in cui il risultato di una funzione è una variabile di tipo non risolta. Tutte le variabili di tipo devono avere una "origine" da qualche parte. Ad esempio, non esiste un termine di tipo , ma esiste un termine di tipo ∀ α $\forall \alpha,\beta.\; \alpha\mathbin\rightarrow\beta$ (la funzione identità λ x . x ).$\forall \alpha.\; \alpha\mathbin\rightarrow\alpha$$\lambda x.x$

Intuitivamente, un termine di tipo $\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$

Trovare la linea sottile tra sistemi di tipi che garantiscono una forte normalizzazione e sistemi di tipi che non lo fanno è un problema difficile e interessante. È un problema importante perché determina quali logiche sono valide, in altre parole quali programmi rappresentano prove di teoremi. Puoi andare molto oltre il Sistema F, ma le regole diventano più complesse. Ad esempio, il calcolo delle costruzioni induttive che è la base dell'assistente di prova Coq , si sta fortemente normalizzando, ma è in grado di descrivere strutture di dati induttivi e algoritmi comuni su di esse, e altro ancora.

Non appena si arriva a linguaggi di programmazione reali, la corrispondenza si interrompe. I linguaggi di programmazione reali hanno caratteristiche come funzioni ricorsive generali (che potrebbero non terminare), eccezioni (un'espressione che genera sempre un'eccezione non restituisce mai un valore e quindi può avere qualsiasi tipo nella maggior parte dei sistemi di tipo), tipi ricorsivi (che consentono la non terminazione intrufolarsi), ecc.