Ours & Hippy — le blog [extensibilité]

Mince. Je viens de lire les articles, et après le premier j’me suis dit : « ok c’est une introduction, dans le prochain il va parler des variants polymorphes », et finalement j’arrive et je vois de l’OO donc j’me dis : « bon tant pis, ça sera dans le 3e ». Et là j’regarde les commentaires et j’vois qu’en fait y’aura fort probablement pas de 3e article, du coup j’suis pas mal déçu. Parce que j’ai découvert les variants polymorphes y’a pas très longtemps et j’aurais bien aimé voir un exemple d’utilisation.

Bref, tout ça pour dire que je trouve le sujet des articles intéressant et que j’aimerais vraiment que tu fasses une suite !

J’ai un peu honte de l’avouer, mais la partie 3 n’est pas encore prête, et je ne suis pas sûre de la publier prochainement : ça demande du travail, je n’ai pas énormément de temps, et je suis plus motivé pour écrire d’autres choses ces temps ci (surtout au vu de l’indifférence tangible¹ qu’on rencontré les deux premières parties, sur un sujet que je trouve pourtant intéressant).

¹ : à l’exception des commentaires pertinent de toi et SpiceGuid; au passage (pour SpiceGuid), j’ai un peu farfouillé du côté du Pattern Calculus mentionné par SpiceGuid (indépendamment, mais je pense que nos sources se recoupent) et c’est effectivement intéressant, même si je me demande s’il ne promet pas un peu trop par rapport à ce qu’il apporte ; je ne suis pas encore assez loin pour m’en assurer.

Je compte évidemment parler des polymorphic variants. D’ailleurs, ces trois billets sont en fait nés d’une réaction au sujet du papier Code Reuse Through Polymorphic Variants de Jacques Garrigue.

J’ai jeté un coup d’oeil à ton lien d’Edward Kwett, mais ça m’a l’air un peu jeune : impossible de trouver quoi que ce soit sur la toile à ce sujet (à part le travail de l’auteur sur le monoidal parsing qui est certainement intéressant, j’avais lu des choses à ce sujet sur Planet Haskell), et ça sent un peu le projet ambitieux qui n’a pas encore porté ses fruits. Ce que je vois dans ce code c’est que les fonctionnalités qu’il met en avant, ensure et unifies, demanderaient un travail de preuve de programmes pour être correctement formalisées au niveau du langage, et que ce serait donc forcément un langage relativement "lourd", ou alors très restrictif.

Si tu t’intéresses à la formulation "informatique" de concepts mathématiques, je te conseille aussi de jeter un oeil aux travaux du projet Focal; il est maintenant plus orienté vers la sécurité, mais ils ont étudié la question de la présentation des arborescences d’objets mathématiques, avec en particulier le très intéressant article Les objets des mathématiques.

Par ailleurs, ceci pourrait t'intéresser (ainsi que tes lecteurs) :
http://comonad.com/Category.ks-old
Un langage sur lequel bosse Edward Kmett. Ce fichier montre comment modéliser les catégories & compagnie dans son langage, il mélange pas mal polymorphisme nominal et structurel c'est plutôt impressionnant.

J'espère que la partie 3 mentionnera les polymorphic variants... C'est l'un des trucs que je trouve splendide en OCaml.

Je pense que le motif de conception POO dont tu parles est connu sous le nom de Interpréteur. Le motif Composite n'a aucun intérêt pour un programmeur Caml, c'est juste un type union mal typé (on peut manipuler les enfants d'une feuille).

Le problème de l'expression vient de ce que le découpage par les fonctions (programmation fonctionnelle) ou par les données (POO) s'excluent l'un et l'autre et qu'on a pas d'abstraction unifiée pour les deux. Ce problème est élégamment résolu par le pattern calculus, où on a droit à des variables libres dans les motifs qui deviennent des citoyens de première classe qui subsument à la fois les données et les fonctions. Un point remarquable c'est que le pattern calculus reste typable statiquement, pour une implantation en OCaml voir le langage Bondi de Barry Jay. En plus de résoudre l'expression problem le pattern calculus offre une approche rigoureuse pour repenser certains autres motifs de conception à la frontière de plusieurs paradigmes (par exemple iterators en POO vs. zippers en fonctionnel).

Je ne connais pas d’exemple concret utilisant explicitement l’extensibilité dans les deux directions à grande échelle, mais je ne me suis pas non plus beaucoup intéressé au code des gros projets logiciels existant dans les langages qui proposent ce genre d’outils. Je connais par contre des cas où cette extensibilité pourrait être profitable pour améliorer le design d’une application déjà existante.

Un exemple générique est le cas où tu veux étendre ton couple (données, opérations) de deux manières différentes, indépendamment. Si tu n’as pas de solution sans modification du code, tu es obligé soit de faire cohabiter les deux extensions au même endroit (en rajoutant de vieux hack du genre "si le booléen machin faut false, on vérifie au runtime l’absence des données de ce genre là"), soit de dupliquer ton couple initial pour le modifier séparément. Les deux solutions donnent lieu à des problèmes de maintenance non négligeables, et la première détruit en plus la sûreté langage de ton application.

Un cas particulier de ce cas général est assez courant, c’est celui où tu veux étendre ton couple (données, opérations), mais en conservant à côté la version initiale, parce que les deux sont pertinents dans ton application. Typiquement, imagine l’auteur d’un compilateur ou interpréteur Lisp, qui a commencé par coder son langage sans supporter les macros. Il a envie de rajouter les macros, qu’il définit comme un "sucre syntaxique" par dessus le langage de base : il y a un langage étendu (langage de base + macros) et une passe de désucrification qui applique toutes les macros et te renvoie le programme entièrement dans le langage de base. Pour faire ça on a besoin d’une représentation, simultanément, du langage de base et du langage étendu. Dans ce cas, tu te retrouves souvent à avoir besoin d’extensibilité dans les deux directions.
Ce qui est fait en pratique, dans les outils que je connais, c’est soit d’abandonner des garanties de typage (en oubliant le langage de base, mais en garantissant que les données que tu fournis aux passes ultérieures, bien que typées "langage avec macro", n’utilisent aucune des constructions macro-esques; inutile de préciser que ça fait des trucs un peu moches), soit de dupliquer les structures de données, ce qui donne lieu à la production d’une certaine quantité de code boilerplate (par exemple tu codes une fonction "map" sur ton langage de base puis ton langage étendu, sans pouvoir réutiliser la première pour coder la deuxième car les types sont disjoints).
Les alternatives plus extensibles (ici on pense très fort aux polymorphic variants de OCaml que je compte mentionner dans un futur billet) permettraient de résoudre le problème, mais viennent aussi avec leurs inconvénients (des messages d’erreurs de typage un peu plus lourds, mais surtout c’est plus sophistiqué donc il faut l’apprendre et ça fait peur) qui font que les programmeurs préfèrent souvent encore the good old way.

C'est intéressant, surtout via les parallèles avec Macaque, où on se rend compte que certes le typage fort fait du bien, mais faut savoir comment ça marche derrière pour pas se faire avoir.

Les exemples sont un peu tordus par contre. Le compilateur lent n'est pas crédible (surtout vu l'effort demandé par la suite), le programme propriétaire passons, reste la compatibilité de la bibliothèque. Tu connais un cas concret où il y a eu ce besoin ?

Je compte sortir un vrai commentaire quand j'aurai vraiment lu l'article (il me manque un certain nombre de subtilités qui sont apparement tout le but ici).