Il existe un billet de blog quelque part avec une implémentation de niveau-type du calculateur SKI combinator, qui est connu pour être Turing-complet.
Les systèmes de type Turing-complet présentent essentiellement les mêmes avantages et inconvénients que les langages complets de Turing: vous pouvez tout faire, mais vous pouvez prouver très peu. En particulier, vous ne pouvez pas prouver que vous finirez par faire quelque chose. Un exemple de calcul au niveau du type est le nouveau transformateur de collection préservant le type dans Scala 2.8. Dans Scala 2.8, des méthodes comme map, filter et ainsi de suite sont garantis pour retourner une collection du même type à laquelle ils ont été appelés. Donc, si vous filter un Set[Int], vous obtenez un Set[Int] et si vous map un List[String] vous obtenez un List[Whatever the return type of the anonymous function is]. Maintenant, comme vous pouvez le voir, map peut réellement transformer le type d'élément. Alors, que se passe-t-il si le nouveau type d'élément ne peut pas être représenté avec le type de collection d'origine? Exemple: un BitSet ne peut contenir que des entiers à largeur fixe. Alors, que se passe-t-il si vous avez un BitSet[Short] et que vous mappez chaque nombre à sa représentation sous forme de chaîne?
someBitSet map { _.toString() }
Le résultat serait un BitSet[String], mais c'est impossible. Ainsi, Scala choisit le supertype le plus dérivé de BitSet, qui peut contenir un String, qui dans ce cas est un Set[String].
Tout ce calcul se passe pendant la compilation , ou plus précisément lors de la vérification de type temps, en utilisant des fonctions de niveau de type. Ainsi, il est statiquement garanti d'être de type sécurisé, même si les types sont réellement calculés et donc pas connus au moment du design.
Je préférerais avoir un système de type non universel et un compilateur rapide à la place. – ziggystar
@ziggystar ce que vous gagneriez en vitesse de compilation vous perdriez probablement en dev et en temps de débogage. – BAR