A veces un lenguaje de programación rompe las reglas de lo establecido.
Eso es lo que ocurre con Iris, un lenguaje funcional moderno que se anima a repensar algo que la mayoría de los lenguajes considera “resuelto”: la inferencia de tipos.
Mientras lenguajes como Haskell, Scala o TypeScript utilizan sistemas derivados de Hindley–Milner —que deducen tipos a partir de la forma y las restricciones estáticas del código— Iris propone algo distinto: una inferencia comportamental, donde los tipos no se deducen solo por lo que una expresión es, sino por lo que hace.
Para entender a Iris, conviene empezar por Haskell.
En Haskell, el compilador busca deducir el tipo más general posible de una expresión.
Por ejemplo:
f x = x + 1
El compilador infiere que f :: Num a => a -> a.
Eso significa: f toma algo de tipo a, siempre que a sea una instancia de Num, y devuelve otro a.
La inferencia en Haskell es declarativa: parte de un conjunto de reglas sobre cómo los tipos se combinan.
El compilador no intenta entender qué hace f, sino cómo encaja dentro del sistema de tipos predefinido.
Iris toma otro camino.
Cuando uno escribe algo como:
fn addOne(x) = x + 1
el compilador no busca una clase de tipo Num ni una restricción declarativa.
En cambio, observa el comportamiento del código:
- nota que x participa en una operación aritmética,
- deduce que x debe pertenecer a un tipo que sepa sumarse,
- y propaga esa característica como una capacidad requerida, no como una categoría rígida.
De esta forma, Iris no infiere tipos por forma, sino por rol.
El tipo de x no es una etiqueta estática, sino un conjunto de propiedades comportamentales deducidas del uso.
Este enfoque convierte a Iris en un lenguaje que parece dinámico, pero mantiene seguridad estática.
Por ejemplo, si una función usa un valor solo para imprimirlo, Iris no necesita saber que es un String; basta con que ese valor sepa representarse como texto.
Si más adelante ese mismo valor participa en una suma, el sistema de tipos lo amplía para incluir también la capacidad de actuar como número, sin perder la anterior.
Así, el tipo resultante se vuelve una composición de comportamientos inferidos.
En vez de limitar, los tipos se adaptan al uso que el programa les da.
En Haskell, el tipo Num a => a -> a expresa una restricción declarativa: a debe cumplir las leyes de Num.
En Iris, el tipo inferido sería más bien una descripción semántica: “esta función requiere algo que sepa sumarse.”
La diferencia puede parecer semántica, pero en realidad separa dos filosofías:
- Haskell razona sobre qué debe cumplirse para que el programa sea válido.
- Iris razona sobre qué comportamiento se manifiesta en el código.
Haskell clasifica; Iris describe.
El primero etiqueta los valores; el segundo observa lo que hacen.
La inferencia comportamental de Iris puede parecer un experimento académico, pero en realidad apunta a una tendencia profunda: sistemas de tipos que entienden la intención del código, no solo su estructura.
Durante décadas, el tipado estático fue visto como un conjunto de reglas sintácticas para detectar errores antes de ejecutar el programa.
Iris sugiere otra visión: los tipos como modelos del significado del programa.
En lugar de decir “esto es un número”, el compilador podría decir “esto se comporta como algo sumable, imprimible o clonable”.
Ese cambio abre un nuevo horizonte:
- una inferencia más rica, que se adapta al contexto,
- una frontera difusa entre lenguajes estáticos y dinámicos,
- y optimizaciones semánticas, donde el compilador comprende la intención del código.
En última instancia, Iris nos recuerda que los tipos no tienen por qué ser jaulas.
Pueden ser descripciones de comportamiento, espejos del flujo semántico del programa.
Y si el futuro del tipado estático pasa por hacer que las máquinas comprendan el significado del código, quizás Iris esté señalando, silenciosamente, hacia ese horizonte.
Dejo link: https://github.com/connorjacobsen/iris
