¿Por qué el algoritmo Hindley-Milner nunca arrojará un tipo como t1 -> t2?

Estoy leyendo sobre el algoritmo de mecanografía Hindley-Milner mientras escribo una implementación, y veo que, siempre que todas las variables estén vinculadas, siempre obtendrás tipos atómicos o tipos donde los argumentos determinarán el tipo final, como t1 -> t1o (t1 -> t2) -> (t1 -> t2)donde t1y t2son variables de tipo.

No puedo pensar en una forma en que obtendrías algo así t1 -> t2o simplemente t1, lo que entiendo significaría que el algoritmo está roto ya que no habría forma de determinar el tipo real de la expresión. ¿Cómo sabes que nunca obtendrás un tipo como estos "rotos" siempre y cuando cada variable esté vinculada?

Sé que el algoritmo produce tipos con variables, pero estos siempre se resuelven una vez que pasa los argumentos a la función, lo que no sería el caso en una función con tipo t1 -> t2. Es por eso que quiero saber cómo sabemos con certeza que el algoritmo nunca producirá tales tipos.

(Parece que puede obtener estos tipos "rotos" en ML , pero le pregunto sobre el cálculo lambda).

En el cálculo lambda sin constantes con el sistema de tipos Hindley-Milner, no puede obtener ninguno de esos tipos donde el resultado de una función es una variable de tipo no resuelta. Todas las variables de tipo tienen que tener un "origen" en alguna parte. Por ejemplo, no existe un término de tipo , pero hay un término de tipo ∀ α $\forall \alpha,\beta.\; \alpha\mathbin\rightarrow\beta$ (la función de identidad λ x . x ).$\forall \alpha.\; \alpha\mathbin\rightarrow\alpha$$\lambda x.x$

Intuitivamente, un término de tipo requiere poder construir una expresión de tipo β desde el aire. Es fácil ver que no hay ningúnvalorque tenga ese tipo. Más precisamente, si la variable de tipo β no aparece en el tipo de cualquier variable de término en el entorno, entonces no existe un término de tipo β que esté en forma normal de la cabeza. Puede probar esto por inducción estructural en el término: o la variable en la cabeza tendría que tener el tipo β , o uno de los argumentos tendría que tener un tipo principal que involucre β , es decir, habría un término adecuado más pequeño.$\forall \alpha,\beta.\; \alpha\mathbin\rightarrow\beta$$\beta$$\beta$$\beta$$\beta$$\beta$

El hecho de que no haya un valor de cierto tipo no significa que no haya un término de ese tipo: podría haber un término sin valor, es decir, un término sin terminación (precisamente, un término sin forma normal). La razón por la cual no existe un término lambda con tales tipos es que todos los términos HM bien tipados se están normalizando fuertemente. Esta es una generalización del resultado que establece que el cálculo lambda simplemente tipado se está normalizando fuertemente. Es una consecuencia del hecho de que el Sistema F se está normalizando fuertemente: el Sistema F es como HM, pero permite cuantificadores de tipo en todas partes en tipos, no solo en el nivel superior. Por ejemplo, en el Sistema F, tiene el tipo ( ∀ α . α ) → ( ∀ α . α ) - pero$\Delta = \lambda x. x \, x$$(\forall \alpha. \alpha) \rightarrow (\forall \alpha. \alpha)$ no está bien escrito.$\Delta\,\Delta$

HM y System F son ejemplos de sistemas de tipos que tienen una correspondencia de Curry-Howard : los términos bien tipados corresponden a pruebas en una lógica determinada, y los tipos corresponden a fórmulas. Si un sistema de tipos corresponde a una teoría consistente, entonces esa teoría no permite probar teoremas como ; por lo tanto, no hay término del tipo correspondiente ∀ α , β $\forall A, \forall B, A \Rightarrow B$ . El sistema de tipos permite deducir "teoremas gratis" sobre funciones sobre estructuras de datos.$\forall \alpha,\beta.\; \alpha\mathbin\rightarrow\beta$

Este resultado se descompone tan pronto como agrega ciertas constantes al cálculo. Por ejemplo, si permite un combinador de punto fijo general como , es posible construir términos de tipo arbitrario: Y ( λ x . X ) tiene el tipo ∀ α . α . El equivalente de un combinador de punto de fijación general en la correspondencia de Curry-Howard es un axioma que establece ∀ A , ∀ B , A ⇒ B , lo que hace que la lógica sea obviamente poco sólida.$Y$$Y (\lambda x.x)$$\forall \alpha. \alpha$$\forall A, \forall B, A \Rightarrow B$

Encontrar la línea fina entre los sistemas de tipos que aseguran una fuerte normalización y los sistemas de tipos que no lo son es un problema difícil e interesante. Es un problema importante porque determina qué lógicas son sólidas, en otras palabras, qué programas incorporan pruebas de teoremas. Puede ir mucho más allá del Sistema F, pero las reglas se vuelven más complejas. Por ejemplo, el cálculo de las construcciones inductivas, que es la base del asistente de prueba Coq , se está normalizando fuertemente pero es capaz de describir estructuras de datos inductivos y algoritmos comunes sobre ellos, y más.

Tan pronto como llegue a los lenguajes de programación reales, la correspondencia se rompe. Los lenguajes de programación reales tienen características como funciones recursivas generales (que pueden no terminar), excepciones (una expresión que siempre genera una excepción nunca devuelve un valor y, por lo tanto, puede tener cualquier tipo en la mayoría de los sistemas de tipos), tipos recursivos (que permiten la no terminación para colarse), etc.