nn constate immédiatement que les changements eǣectués par l’instrumentation touchent de nombreuses parties du code de l’in- terpréteur, sans être restreints à une ou deux régions particulières. kes changements sont éparpillés dans le code. ce plus, des chan- gements de catégories diǣérentes sont entremêlés : certaines fonc- tions sont aǣectées par les changementsev6lu6teE6chetProgr6m Counter. qésultat, il devient diǦcile de comprendre les eǣets de l’instrumentation en lisant le code à l’œil nu, ou de s’assurer de sa justesse par rapport à une spéciǤcation. hl devient diǦcile éga- lement, sans connaissances avancées de marcissus et de l’évalua- tion multi-facettes, de savoir si une ligne de code de l’interpréteur instrumenté concerne l’interprétation décrite par le standard db- lArcript, ou si elle concerne l’évaluation multi-facettes. ke code de l’interpréteur instrumenté ne comporte aucune information qui permet de les distinguer.
Autre point important : l’instrumentation duplique tout le code de l’interpréteur. b’est une solution simple pour créer un interpré- teur qui supporte l’évaluation multi-facettes. dn revanche, la dupli- cation de code a un impact important sur la maintenance à long terme : plus du double du code doit être maintenu. kes change- ments requis dans le code source pour corriger un bug dans mar- cissus, ou pour ajouter une fonctionnalité, doivent désormais être répétés dans l’instrumentation. ke coût de maintenance devient prohibitif lorsque plusieurs instrumentations sont envisagées.
hl est évident que les auteurs avaient pour but de démontrer la viabilité de l’évaluation multi-facettes sur un langage réaliste, en l’occurrence iavarcript. hls ne cherchaient probablement pas à ré- soudre les problèmes d’éparpillement et d’entremêlement de code. b’est pourquoi modiǤer directement marcissus était une solution adéquate pour atteindre leur but.
méanmoins, ces problèmes sont légitimes, et pas seulement dans le simple contexte d’un interpréteur et d’une analyse de ǥot dyna- mique. ka duplication de code apparaît bien souvent dans d’autres programmes. dt il est rare qu’ajouter ou modiǤer une fonctionna- lité à un programme n’impacte qu’une partie bien déǤnie du code source ; éparpillements et entremêlements ne sont pas des pro- blèmes spéciǤques à l’instrumentation d’un interpréteur. nn peut alors se demander si ces problèmes sont évitables, et s’ils le sont, comment les éviter ? k’instrumentation de marcissus constitue un bon scénario pour tenter de répondre à ces questions.
.
Le but : factoriser les changements
c’un point de vue abstrait, on peut voir l’interpréteur comme une fonction mathématique qui associe un code source à un pro- cessus :
baladin Le problème : instrumenter et étendre des interpréteurs
spec_ : source -interpréteur-> processus
ka déǤnition exacte de cette fonction correspond à une spéciǤ- cation de l’interpréteur (voir §1.1).
k’instrumentation de la section précédente correspond à une modiǤcation de cette spéciǤcation. dt à cette nouvelle spéciǤcation correspond à une nouvelle fonction :
spec_ : source -interpréteur modifié-> processus
cans la spéciǤcation 1, un programme iavarcript est évalué en suivant les règles du standard dblArcript. dn suivant la spéciǤca- tion 2, un programme iavarcript est évalué en suivant les règles de l’évaluation multi-facettes.
À ces spéciǤcations correspondent un programme. cans la sec- tion précédente, on a bien deux programmes : marcissus corres- pond à la spéciǤcation 1, et marcissus instrumenté par Austin et elanagan correspond à la spéciǤcation 2. k’interpréteur modiǤé est vu comme un nouvel interpréteur, sans aucune relation avec le premier. dn suivant ce point de vue, il est naturel d’implémen- ter l’interpréteur modiǤé comme un nouveau programme.
oourtant, le nouveau programme est en grande partie basé sur le premier. k’instrumentation pour l’évaluation multi-facettes change moins de 10% du code source de marcissus. nn pourrait alors adop- ter un point de vue complémentaire, et s’intéresser à la modi ca- tion en elle-même :
interpréteur -modific6tion-> interpréteur modifié
(0,0)
(0,1)
(2,1)
(2,0)
(0,0)
(2,1)
ka modiǤcation décrit uniquement les changements, le delta,entre les deux interpréteurs. k’interpréteur modiǤé est alors dérivé de l’interpréteur d’origine. b’est un peu la même distinction que l’on peut faire entre représenter un rectangle par quatre sommets, ou bien par une origine et un vecteur. ka seconde représentation est plus compacte que la première, sans perte d’information.
korsque la modiǤcation est relativement mineure par rapport à la taille de l’interpréteur, la représentation du couple origine + delta sera plus compacte. nn qualiǤera une telle représentation de di érentielle.
lais quel est l’intérêt de cette représentation diǣérentielle ? qappelons nous que le processus de développement est le sui- vant :
. . Le but : factoriser les changements barbute spécification code source programme processus implémentation compilation exécution observation résultats rectification conception abandon
aien que le véritable objet du program- meur est de faire concorder le processus avec les résultats attendus, le program- meur ne manipule pas directement le processus, mais seulement le code qui le décrit. ka boucle observation/rectiǤca- tion permet de rectiǤer les imprécisions causées par cette indirection.
ke programmeur élabore le code source en fonction de la spé- ciǤcation. À partir du code source, le compilateur produit un pro- gramme exécutable, et le programmeur observe les résultats de son exécution sur la machine. ke but du programmeur est de conce- voir un programme qui aura les résultats attendus par la spéciǤca- tion. ri les résultats sont en accord avec la spéciǤcation, le pro- gramme est Ǥni. ke plus souvent, il faut corriger le code source pour corriger le processus engendré, jusqu’à ce que les résultats concordent, ou que le programme ne présente plus d’intérêt, ce qui oǣre une porte de sortie à ce cycle.
ke changement décrit dans la section précédente correspond à une modiǤcation de la spéciǤcation. cans le premier point de vue, cela entraîne deux codes sources, pour deux programmes, pour deux processus, bien distincts :
spécification code source programme processus résultats modification spécification code source programme processus résultats
Interpréteur d'origine Interpréteur modifié
ka spéciǤcation est modiǤée : il y a des parties nouvelles ( ), qui correspondent aux ajouts de l’évaluation multi-facettes, qui
baroque Le problème : instrumenter et étendre des interpréteurs
viennent se greǣer sur la spéciǤcation de l’interprétation d’origine. ouisque les spéciǤcations sont proches, on peut réutiliser le code source de l’interpréteur d’origine, et y apporter des modiǤcations. Au Ǥnal, on a un interpréteur qui se comporte diǣéremment, mais dont la fonctionnalité principale reste inchangée : il interprète tou- jours du code iavarcript. lais même si cette similarité entre les deux interpréteurs existe bien, elle n’est pas exploitée : on a deux spéciǤcations, deux codes sources, deux programmes.
cans une représentation diǣérentielle, le but est de factoriser cette similarité. olutôt que d’avoir deux programmes, on a un pro- gramme et sa modiǤcation :