Hay una publicación de blog en algún lugar con una implementación de nivel de tipo del cálculo del combinador SKI, que se conoce como Turing-complete.
Los sistemas de tipo Turing-complete tienen básicamente los mismos beneficios y desventajas que tienen los lenguajes completos de Turing: puede hacer cualquier cosa, pero puede probar muy poco. En particular, no puedes probar que eventualmente harás algo.
Un ejemplo de computación a nivel de tipo son los nuevos transformadores de recolección de preservación de tipo en Scala 2.8. En Scala 2.8, se garantiza que métodos como map, filter y demás devuelvan una colección del mismo tipo en el que fueron llamados. Por lo tanto, si filter a Set[Int], obtiene un Set[Int] y si map a List[String] obtiene un List[Whatever the return type of the anonymous function is].
Ahora, como puede ver, map puede transformar el tipo de elemento. Entonces, ¿qué ocurre si el nuevo tipo de elemento no se puede representar con el tipo de colección original? Ejemplo: un BitSet solo puede contener enteros de ancho fijo. Entonces, ¿qué sucede si tiene un BitSet[Short] y asigna cada número a su representación de cadena?
someBitSet map { _.toString() }
El resultado sería ser un BitSet[String], pero eso es imposible. Entonces, Scala elige el supertipo más derivado de BitSet, que puede contener un String, que en este caso es un Set[String].
Todo este cálculo está sucediendo durante el tiempo de compilación , o más precisamente durante el tiempo tipo comprobar, utilizando las funciones de nivel tipo. Por lo tanto, está garantizado estáticamente como seguro para el tipo, aunque los tipos se calculan realmente y, por lo tanto, no se conocen en el momento del diseño.
Preferiría tener un sistema de tipo no universal y un compilador rápido en su lugar. – ziggystar
@ziggystar lo que ganarías en velocidad de compilación que probablemente perderías en tiempo de desarrollo y depuración. – BAR