août
2009
Un article de SpiceGuid
Eastwest est un langage jouet intégré avec un éditeur dirigé par la syntaxe.
Eastwest s’appuye sur OSET, le O’Caml Structure Editor Toolkit, un framework pour éditeurs structurés basé sur LablGtk2.
Eastwest est une démonstration étonnante de ce que non seulement Objective-Caml n’est pas réservé qu’à des programmes console mais qu’il peut même être en avance en matière d’interfaces interactives.
Démonstration
Comme le format texte n’est pas du tout adapté pour ce faire, la démonstration des capacités de Eastwest se fait principalement à l’aide de courtes vidéos.
L’outil lui même n’est disponible qu’en format source et suffisamment riche en dépendances pour décourager une compilation sur un système vierge. Malgré mon envie d’essayer le prototype (je tenterais bien un petit dérivateur formel et un interpréteur jouet pour le lambda-calcul paresseux) les vidéos restent la source la plus immédiate pour satisfaire ma curiosité.
Au visionnage on ne constate à première vue rien de bien révolutionnaire, c’est menu-déroulant sur menu-déroulant, avec un peu de clavier pour entrer les identificateurs à leur déclaration, tout-à-fait ce qu’on attend d’un éditeur dirigé par la syntaxe :
- il n’y a pas de syntaxe à apprendre, le menu contextuel affiche toutes les constructions valides en cours
- l’indentation et la mise en forme du code sont automatiques, le programmeur ne s’occupe que du contenu
Intérêt
Toutefois, à y regarder de plus près, on s’aperçoit que l’aspect innovant de Eastwest ne réside pas tant dans sa méthode de saisit du code que dans l’exploitation habile qui en est faite au bénéfice du typage en général et des types algébriques en particulier :
- la barre de menu de l’éditeur affiche le type de l’expression en cours d’édition
- le typage se fait du haut vers le bas (top-down), il faut typer les fonctions à la déclaration, ensuite l’édition de chaque expression est contrainte par le type du bloc qui lui est supérieur
- le menu d’édition est totalement contextuel, non seulement il n’affiche que les constructions syntaxiques valides mais en plus il n’affiche que les variables et les fonctions de type compatible avec celui du bloc supérieur, par conséquent il est impossible de construire une expression mal typée
- le langage offre une alternative intéressante à la surcharge (polysémie), il n’y a pas de surcharge cependant le module choisi n’est pas affiché et reste implicite
- l’entrée de la console interactive est sécurisée, l’utilisateur passe par le menu de l’éditeur structuré, il ne peut pas entrer une expression qui n’a pas la bonne syntaxe ou pas le bon type
- le langage supporte les GADT (Generalized Abstract Data Types)
La combinaison de ces deux dernières fonctionnalités est particulièrement puissante quand il s’agit de créer des DSL (Domain Specific Language) :
- grâce à l’édition structurée le programmeur n’a pas à faire d’analyse syntaxique, il n’y a pas d’analyseur syntaxique à écrire
- grâce aux GADT le programmeur n’a pas à faire de vérification de type, les expressions entrées dans la console sont forcément bien typées, pas besoin de vérification statique ou de tests dymaniques et pas besoin de générer des messages d’erreur explicatifs
Toutefois ce confort n’est pas forcément sans inconvénient.
Le premier c’est l’obligation de typer les fonctions et les variables déclarées à l’aide du let.
Le second, potentiellement plus grave, qui me vient à l’esprit c’est la fragilité du code. Que ce passe-t-il lors d’un refactoring ?
Par exemple si l’on change le type d’une fonction ou la déclaration d’un type. De la même manière qu’avec un éditeur texte cela invalide du code. Reste à savoir si le code (dé-)structuré est facile à (re-)structurer.
D’un autre côté on gagne du temps, par exemple le renommage est gratuit alors qu’il est coûteux avec un éditeur texte.
Conclusion
Indiscutablement, avec Eastwest, on a affaire à un prototype emblématique du language oriented programming.
Ce pseudo-paradigme, qui a toujours existé notamment dans la littérature consacrée à l’analyse récursive descendante, a pris une importance considérable depuis qu’il s’agit de vérifier statiquement la validité du contenu des pages web. Pour l’instant Eastwest ne permet pas l’édition/validation xml, mais on peut déjà imaginer l’intérêt d’un tel outil couplé aux GADT dans ce domaine. Dans tous les cas Eastwest est sans doute un formidable outil pédagogique et sans doute un excellent support pour l’apprentissage aisé de la programmation fonctionnelle (plus de messages d’erreur de type parfois difficiles à localiser pour le débutant).