60 votes

Quelles sont les principales difficultés théoriques liées à l'ajout de modules de style ML à Haskell ?

Il est bien connu que les classes de types de style Haskell et les modules de style ML offrent des mécanismes différents pour la spécification de interfaces . Ils sont (peut-être) équivalents en termes de puissance, mais dans la pratique, chacun a ses propres avantages et inconvénients.

Étant donné que je suis un peu inclusionniste en ce qui concerne les caractéristiques de la langue, ma question est la suivante : Quelles sont les principales difficultés théoriques liées à l'ajout de modules de style ML à Haskell ? Je suis intéressé par des réponses du type suivant :

  • Quelles sont les caractéristiques des systèmes de types existants qui interagissent mal avec les modules de style ML ? (Un exemple de mauvaise interaction est GADT et les dépendances fonctionnelles, même si les fundeps sont techniquement équivalents aux types associés).

  • Quelles sont les choses auxquelles il faut renoncer du côté du compilateur pour pouvoir compiler des modules de style ML ?

  • Comment les modules de style ML interagissent-ils avec l'inférence de type ?

Lecture connexe :

34voto

Don Stewart Points 94361

L'endroit principal pour faire la comparaison est,

  • Modules ML et classes de type Haskell : Une comparaison constructive . Stefan Wehr et Manuel M.T. Chakravarty. Dans les actes du sixième symposium ASIAN sur les langages et systèmes de programmation - APLAS 2008, Springer-Verlag, LNCS, 2008.

  • Classes de type modulaire . Derek Dreyer, Robert Harper et Manuel M. T. Chakravarty. In Proceedings of The 34th Annual ACM SIGPLAN - SIGACT Symposium on Principles of Programming Languages, ACM Press, 2007.

  • Modules de première classe pour Haskell Mark Shields et Simon Peyton Jones. Soumis à la Ninth International Conference on Foundations of Object-Oriented Languages (FOOL 9), Portland, Oregon. 20 pages. Oct 2001.

En fait, je n'ai pas connaissance de problèmes théoriques - du moins, des propositions concrètes ont été faites (et mises en œuvre dans des prototypes) - l'article de Shields et PJ contient beaucoup de détails. Le fardeau de la mise en œuvre n'est cependant pas trivial.

11voto

augustss Points 15750

Je ne pense pas qu'il y ait de gros problèmes théoriques. Il faudrait prendre une décision sur les foncteurs applicatifs ou non. L'applicatif est probablement plus dans le style Haskell. Mais je pense que toute tentative d'ajouter des modules de style ML à Haskell sera grotesque en raison du chevauchement entre les modules et les classes ; il y aura deux façons de faire beaucoup de choses.

8voto

svenningsson Points 2648

Simon PJ a fait valoir que les modules de style ML ont un mauvais rapport puissance/coût, qu'ils sont difficiles à mettre en œuvre. Voir l'article de PJ diapositives de la conférence POPL 2003 (vers la fin). Il appelle également à une conception ayant un meilleur rapport puissance/coût, mais je n'ai pas connaissance d'une telle proposition.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X