Concernant les littéraux, je ne comprends pas pourquoi il sont considéré différemment du type.
En gros si tu as
i : int
i + 1
i + 1 est ok, uniquement car on détermine que 1 est d'un type entier.
Or a part dans fonctionnalité de généricité, le type n'est jamais une variable. C'est chiant dans ingénierie des modèles, tu ne peux pas prévoir un modèle de plus haut niveau, qui sera utilisé pour en faire un de plus petit niveau en définissant le type de certain donné par exemple. Ce genre de problème se contourne en réinventant une sorte de typage depuis le modèle de haut niveau, mais c'est moche et lourd. De plus, la vérification des types doit être réécrites.
Cela se retrouve dans tout ce qui ressemble à des déclarations des schémas (xml ou autre) : il est compliqué d'avoir un schéma dans le même "monde" (au sens d'une library ou d'une autre donné) qu'une instance d'un objet. c'est ainsi que l'on se retrouve avec des "metamodèles" (en UML) qui devienne super chiant quand il s'agit de rapprocher des modèles utilisant des metamodèles différents, ce qui ne poserait aucun problème si on utilisait une library à la place.
[^] # Re: Reason
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OCaml 4.04 et 4.05. Évalué à 3.
Réponse bien complète :)
Concernant les littéraux, je ne comprends pas pourquoi il sont considéré différemment du type.
En gros si tu as
i : int
i + 1
i + 1 est ok, uniquement car on détermine que 1 est d'un type entier.
Or a part dans fonctionnalité de généricité, le type n'est jamais une variable. C'est chiant dans ingénierie des modèles, tu ne peux pas prévoir un modèle de plus haut niveau, qui sera utilisé pour en faire un de plus petit niveau en définissant le type de certain donné par exemple. Ce genre de problème se contourne en réinventant une sorte de typage depuis le modèle de haut niveau, mais c'est moche et lourd. De plus, la vérification des types doit être réécrites.
Cela se retrouve dans tout ce qui ressemble à des déclarations des schémas (xml ou autre) : il est compliqué d'avoir un schéma dans le même "monde" (au sens d'une library ou d'une autre donné) qu'une instance d'un objet. c'est ainsi que l'on se retrouve avec des "metamodèles" (en UML) qui devienne super chiant quand il s'agit de rapprocher des modèles utilisant des metamodèles différents, ce qui ne poserait aucun problème si on utilisait une library à la place.
"La première sécurité est la liberté"