Por que o algoritmo Hindley-Milner nunca produz um tipo como t1 -> t2?

Estou lendo sobre o algoritmo de digitação Hindley-Milner ao escrever uma implementação e vejo que, desde que todas as variáveis ​​sejam vinculadas, você sempre terá tipos atômicos ou tipos em que os argumentos determinarão o tipo final, como t1 -> t1ou (t1 -> t2) -> (t1 -> t2)onde t1e t2são variáveis ​​de tipo.

Não consigo pensar em uma maneira de obter algo assim t1 -> t2ou simplesmente t1, o que entendo significaria que o algoritmo está quebrado, pois não haveria maneira de determinar o tipo real da expressão. Como você sabe que nunca obterá um tipo como esses "quebrados", desde que cada variável esteja vinculada?

Eu sei que o algoritmo gera tipos com variáveis, mas elas sempre são resolvidas quando você passa os argumentos para a função, o que não seria o caso de uma função com type t1 -> t2. É por isso que quero saber como sabemos com certeza que o algoritmo nunca produzirá esses tipos.

(Parece que você pode obter esses tipos "quebrados" no ML , mas estou perguntando sobre o cálculo lambda.)

No cálculo lambda sem constantes com o sistema do tipo Hindley-Milner, você não pode obter nenhum desses tipos em que o resultado de uma função é uma variável do tipo não resolvida. Todas as variáveis ​​de tipo precisam ter uma "origem" em algum lugar. Por exemplo, não existe um termo do tipo , mas existe um termo do tipo ∀ α $\forall \alpha,\beta.\; \alpha\mathbin\rightarrow\beta$ (a função de identidade λ x . x ).$\forall \alpha.\; \alpha\mathbin\rightarrow\alpha$$\lambda x.x$

Intuitivamente, um termo do 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$

Encontrar a linha tênue entre sistemas de tipos que garantem forte normalização e sistemas de tipos que não o fazem é um problema difícil e interessante. É um problema importante porque determina quais lógicas são válidas, ou seja, quais programas incorporam provas de teoremas. Você pode ir muito além do Sistema F, mas as regras se tornam mais complexas. Por exemplo, o cálculo de construções indutivas, que é a base do assistente de prova Coq , está fortemente normalizando, mas é capaz de descrever estruturas de dados indutivos e algoritmos comuns sobre elas, e muito mais.

Assim que você chega a linguagens de programação reais, a correspondência se decompõe. Linguagens de programação reais têm recursos como funções recursivas gerais (que podem não terminar), exceções (uma expressão que sempre gera uma exceção nunca retorna um valor e, portanto, pode ter qualquer tipo na maioria dos sistemas de tipos), tipos recursivos (que permitem a não terminação para esgueirar-se), etc.