Il est tout à fait possible d'ajouter des nombres pairs et des nombres impairs, en les considérant en tant que int. C'est juste qu'il y une annotation explicite de typage pour dire cela au type checker; mais la valeur deux de mon exemple précédent est bien à la fois de type Event.t et de type int.
C'est justement ça que je trouve dommage, devoir explicitement le dire, alors qu'il est possible de le déterminer implicitement.
Cela étant, je tiens à signaler que tout ceci est réalisé statiquement (le code non annoté refuserai de compiler), ce qui n'est pas le cas de LetLang d'après tes specs. La différence étant que les cast doivent être explicites en OCaml.
Yes, pour l'instant je fais au runtime, c'est plus simple. Mais à terme, j'imagine très bien de l'analyse statique de code avant la compilation pour appliquer ce type-check "implicite".
Après, il y a un point non abordé dans ta spec : quid des listes de even ? Sont-elles des listes de number ? Si c'est le cas, il te faudra aborder la notion de variance (invariance, covariance et contravariance) des types paramétriques.
Oui, et une LEP dédiée s'attaquera à ces notions.
Je ne suis pas sûr que tu te sois posé la question, car d'après ta spec sur les fonctions, on peut lire :
NB: The class func[arguments -> return] contains every function with the same signature.'
Pourtant les types des fonctions -> est contravariant sur son entrée (arguments) et covariant sur sa sortie (return). Ainsi la classe func[number -> number] devrait aussi contenir les fonctions avec cette signature funcnumber -> int.
Problème de formulation, j'aurais du dire "with a compatible signature" à la place. Mais je me suis bien posé la question.
tu t'inspires de l'approche de Russel et Whitehead dans leur principia mathematica.
Totalement, j'ai les 3 volumes à la maison. Et quelques autres ouvrages qui traitent de théorie des ensembles, des types et catégories.
Cela étant, il y a un point qui m'intrigue dans ta spec. Tu prétends avoir rejeté l'idée d'un classe object qui contiendrait toutes les valeurs du langage, parce que cela irait à l'encontre de la hiérarchie des set. Mais qu'en est-il de cette classe que je semble pouvoir définir ?
class object (v : !even | even)
De ce que je comprends, sa fonction de compréhension vaut true pour toutes valeurs du langage, et donc l'extension de cette classe contiendrait bien toutes les valeurs.
AAAAAAAAAAAAAAH.... merci. Il va falloir que j'ajoute à ma TODO d'interdire ce genre de définition (il me semble que des outils comme coq pourrait m'aider à implémenter cette fonctionnalité).
[^] # Re: théorie des ensembles pas naives
Posté par David Delassus (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2.
C'est justement ça que je trouve dommage, devoir explicitement le dire, alors qu'il est possible de le déterminer implicitement.
Yes, pour l'instant je fais au runtime, c'est plus simple. Mais à terme, j'imagine très bien de l'analyse statique de code avant la compilation pour appliquer ce type-check "implicite".
Oui, et une LEP dédiée s'attaquera à ces notions.
Problème de formulation, j'aurais du dire "with a compatible signature" à la place. Mais je me suis bien posé la question.
Totalement, j'ai les 3 volumes à la maison. Et quelques autres ouvrages qui traitent de théorie des ensembles, des types et catégories.
AAAAAAAAAAAAAAH.... merci. Il va falloir que j'ajoute à ma TODO d'interdire ce genre de définition (il me semble que des outils comme coq pourrait m'aider à implémenter cette fonctionnalité).
Au passage :
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg