Prototypes

Dans le document Composition non modulaire modulaire (Page 94-97)

conserv´ees est vaste. Cette taxonomie a ´et´e propos´ee `a la fois dans un contexte d´eterministe et non d´eterministe (programmes concurrents) [17]. Par la suite afin de rendre peu coˆuteux le test d’appartenance d’un aspect `a une cat´egorie, nous avons propos´e des langages d’aspects restreints qui garantissent l’appartenance `a une cat´egorie par construction [18]. La synth`ese de ces travaux a finalement ´et´e produite [3].

9.1.5 Vieux amours

Ma th`ese de doctorat porte sur la mod´elisation formelle des techniques de mise en œuvre de langages fonctionnels par transformation de programme. Quelques ann´ees apr`es ma th`ese j’ai eu l’occasion de me replonger dans cet univers et de proposer avec Pascal Fradet une mod´elisation de la machine de Krivine et de ses variantes [5].

9.2 Prototypes

Je ne suis pas un programmeur ´em´erite mais j’aime confronter occasionnellement mes id´ees de recherche `a la r´ealit´e de la programmation. Ainsi `a plusieurs reprises j’ai particip´e `a la conception et au d´eveloppement de petits prototypes de recherche. Ces d´eveloppements dans un contexte id´ealis´e m’ont permis de me concentrer sur l’essence des probl`emes tout en v´erifiant (parfois avec mauvaise surprise) la coh´erence de d´efinitions qui ont pu par la suite ˆetre corrig´ees ou simplement am´elior´ees. Je passe ici bri`evement en revus de tels prototypes :

• MetaJ : est un interpr´eteur r´eflexif pour un sous ensemble de Java. Cet interpr´eteur est en fait une collection d’interpr´eteurs dans la mesure o`u en suivant les travaux pionniers sur les reflexions dans le langage Lisp n’importe quelle classe de notre m´eta interpr´eteur Java peut ˆetre rendue r´eifiable. Nous avons ainsi pu montrer que l’essentiel des API de r´eflexion repose sur un folklore qui fait des hypoth`eses implicites quant `a la mise en œuvre des m´ecanismes du langage (par exemple le protocole lookup-apply). En changeant la d´efinition d’un interpr´eteur on change l’API de sa version r´eflexive. Et en choisissant les classes `a r´eifier on contrˆole le degr´e de r´eflexivit´e du langage.

• EAOP : est une biblioth`eque Java utilisant des threads pour d´efinir des coroutines et un arbre pour composer des aspects. En utilisant un outil de transformation de programme nous avons facilement pu instrumenter le programme de base (et possibles les actions des aspects) pour tisser des aspects `a la fa¸con d’un moniteur d’ex´ecution.

• Cacao : est un solveur de contraintes discr`etes id´ealis´e. Nous avons con¸cu ce programme avec un minimum de concepts (c.a.d. sans `a priori), puis a posteriori nous l’avons ´etendu avec AspectJ pour y ajouter une analyse dynamique connue sous le nom d’explication. Ce travail nous a confront´e `a certaines limites d’AspectJ et nous a permis d’identifier des pistes de recherche que nous explorons encore `a ce jour.

• AXL : est une biblioth`eque Java offrant un interpr`eteur pour un langage de coupe g´en´eralis´e sensible aux flots de donn´ees. Il utilise AspectJ pour instrumenter le programme de base et appeler l’interpr`eteur.

• CEAOP : est une biblioth`eque Java mettant en œuvre notre mod`ele de programmation par aspect dans un cadre concurrent et notamment des op´erateurs de composition d’aspects.

Ces prototypes n’ont pas franchi le stade du jouet d’´etude mais ils ont r´eellement nourri nos r´eflexions et permis de raffiner nos propositions.

82 9. Autres travaux

9.3 Conclusion

La recherche n’est pas un chemin en ligne droite. Le mien a peut ˆetre pris plus de tours et d´etours que d’autres, mais cette richesse a permis aussi d’alimenter mes reflexions. On peut tout de mˆeme noter qu’`a une ´epoque o`u Haskell connaˆıt un regain d’int´erˆet je peux travailler de nouveau dans ce cadre (comme notamment mes derniers travaux avec Nicolas Tabareau sur l’´evaluation imp´erative paresseuse pr´ec´edemment ´evoqu´es).

Chapitre 10

Conclusion

Sommaire 10.1 Bilan . . . . 83 10.2 Revisiter le pass´e . . . . 84 10.2.1 Le futur . . . . 86 10.3 Un programme de recherche . . . . 87 10.3.1 Objectif(s) . . . . 87

10.3.2 Dans un cadre dynamique . . . . 87

10.3.3 Dans un cadre statique . . . . 88 10.4 Conclusion . . . . 91

10.1 Bilan

Qu’avons nous fait ? Comment l’avons nous fait ? Que reste-t-il `a faire ? Cette section fait un bilan des travaux pr´esent´es dans ce document et esquisse un programme de recherche pour l’avenir.

L’objectif `a ne pas perdre de vue est toujours le mˆeme : donner au programmeur des supports (langages) afin de l’aider `a d´evelopper des applications complexes. Une application peut ˆetre complexe pour diff´erentes raisons. L’une d’entre elles est je pense que les limites de la modularit´e vont amener le programmeur `a prendre en compte diff´erentes fonctionnalit´es en mˆeme temps avec pour r´esultat d’obtenir un code entrelac´e ayant perdu toute structuration propre `a chaque fonctionnalit´e. Une autre raison compl´ementaire est que le programmeur entrela¸cant son code `a la main va souvent devoir sursp´ecifier son code (par exemple en choisissant un ordonnancement pr´ecis de deux instructions pourtant commutatives) et ˆetre tent´e d’appliquer des optimisations qui ne sont pas forc´ement indispensables. Un code dupliqu´e va alors pouvoir ´evoluer de diff´erentes fa¸cons suivant son contexte d’entrelacement et cr´eer des opportunit´es de bogues (par l’oubli de la correction d’un bogue dans les deux branches `a la fois ou par l’impossibilit´e de corriger le bogue de la mˆeme fa¸con dans les deux branches).

Nous voulons inciter le programmeur `a ne pas se censurer. En effet, un programmeur peut ˆ

etre amen´e `a renoncer `a programmer certaines fonctionnalit´es `a cause de leur complexit´e. Par exemple une des motivations des travaux d´ecrits `a la section 8.1 ´etait que les propri´et´es sont parfois tellement complexes `a maintenir lorsque le graphe ´evolue qu’un sch´ema de programmation qui recalcule ces propri´et´es peut lui ˆetre pr´ef´er´e. Dans ce cas l’´evaluation paresseuse et des optimisations dynamiques permettent de rendre ce sch´ema raisonnablement efficace. A l’inverse,

84 10. Conclusion

nous voulons inciter le programmeur `a se censurer sur certaines optimisations non indispensables. Dans un premier temps, il doit se limiter `a d´efinir un code le plus g´en´eral et le plus composable possible.

Tous les travaux pr´esent´es dans ce document (depuis la prise en compte du flot dynamique de contrˆole, jusqu’au tissage statique de code en passant par la prise en compte des flots dynamique de donn´ees) vont dans ce sens. Avant de pr´esenter un programme de recherche, je souhaite revenir sur une d´efinition des aspects que j’avais propos´e et la revisiter `a l’aune des ann´ees ´ecoul´ees.

Dans le document Composition non modulaire modulaire (Page 94-97)