(4) l'exemple avec la taille est possible dans tous les langage objet, surtout si il y a les template, ce que tu appelle les type paramétrés. C'est donc supporté par Lissac qui est objet à prototype. Ca se passe pas de la même façon mais la puissance de ce mécanisme dans Ocaml provient du mécanismes des types abstrait associé au mécanisme d'inférence.
L'inférence de type c'est une autre paire de manche. Écrire un moteur d'inférence est très complexe et pose des problèmes dans le cadre des langages objet, bien que cela soit dans une certaine mesure possible (cf implémentation objet de Ocaml). Initialement l'inférience est basé sur le typage automatique des lambda-calcul (fondement de la prog fonctionnelle), comme Lissac est objet et non pas fonctionnel il faut réétudier l'inférience dans ce cas.
(5) Le pattern matching est en fait une application des concepts de réécriture. Très souvent ajouté dans les langagues fonctionnels pour les enrichir. Le problème est qu'en objet on doit utiliser le polymorphisme pour éviter les switch entre les cas. Les branchement par cas sont à éviter en prog objet pour améliorer la capacitée du code à évoluer (pas besoin de modifier les switch suffit d'hériter une classe à la place). Il y a clairement un clash entre les deux paradigmes. Cela dit il y a peut être matière à creuser. Demande à ontologia il adore spéculer :))
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par Joris R (site web personnel, Mastodon) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
L'inférence de type c'est une autre paire de manche. Écrire un moteur d'inférence est très complexe et pose des problèmes dans le cadre des langages objet, bien que cela soit dans une certaine mesure possible (cf implémentation objet de Ocaml). Initialement l'inférience est basé sur le typage automatique des lambda-calcul (fondement de la prog fonctionnelle), comme Lissac est objet et non pas fonctionnel il faut réétudier l'inférience dans ce cas.
(5) Le pattern matching est en fait une application des concepts de réécriture. Très souvent ajouté dans les langagues fonctionnels pour les enrichir. Le problème est qu'en objet on doit utiliser le polymorphisme pour éviter les switch entre les cas. Les branchement par cas sont à éviter en prog objet pour améliorer la capacitée du code à évoluer (pas besoin de modifier les switch suffit d'hériter une classe à la place). Il y a clairement un clash entre les deux paradigmes. Cela dit il y a peut être matière à creuser. Demande à ontologia il adore spéculer :))