Partial Evaluation for Program Comprehension

Partial evaluation for program comprehension Sandrine Blazy and Philippe Facon ACM Computing Surveys, Vol. 30, No. 3es, September 1998 Article 17 Permission to make digital/hard copy of part or all of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 1998 ACM 0360-0300/98/03es- . . . $5.00 Partial Evaluation for Program Comprehension Sandrine Blazy and Philippe Fa on  CEDRIC-IIE, 18 allee Jean Rostand, 91025 Evry Cedex, Fran e (blazyiie. nam.fr) 1. INTRODUCTION Program omprehension is the most tedious and time onsuming task of software maintenan e, an important phase of the software life y le [A.Frazer 1992℄. This is parti ularly true while maintaining s ienti appli ation programs that have been written in Fortran for de ades and that are still vital in various domains even though more modern languages are used to implement their user interfa es. Very often, programs have evolved as their appli ation domains in rease ontinually and have be ome very omplex due to extensive modi ations. This generality in programs is implemented by input variables whose value does not vary in the ontext of a given appli ation. Thus, it is very interesting for the maintainer to propagate su h information, that is to obtain a simpli ed program, whi h behaves like the initial one when used a ording to the restri tion. We have adapted partial evaluation for program omprehension. Our partial evaluator performs mainly two tasks: onstant propagation and statements simpli ation. It in ludes an interpro edural alias analysis. As our aim is program omprehension rather than optimization, there are two main di eren es with lassi al partial evaluation. Firstly, we do not hange the original stru ture of the ode. In parti ular, we do not unfold statements. In the same way, our partial evaluator generates neither new variables nor rename variables. The residual ode is easier to understand be ause many statements and variables have been removed and no additional statement or variable has been inserted. Se ondly, some identi ers are not repla ed by their orresponding values in the residual ode. The bene t of repla ing an identi er by its value depends on the meaning of the identi er for the user: thus, it depends on the kind of identi er, but also on the kind of user. For any user, identi ers like PI are likely to be kept in the ode, on the ontrary to intermediate variables used only to de ompose some Permission to make digital or hard opies of part or all of this work for personal or lassroom use is granted without fee provided that opies are not made or distributed for pro t or dire t ommer ial advantage and that opies show this noti e on the rst page or initial s reen of a display along with the full itation. Copyrights for omponents of this work owned by others than ACM must be honored. Abstra ting with redit is permitted. To opy otherwise, to republish, to post on servers, to redistribute to lists, or to use any omponent of this work in other works, requires prior spe i permission and/or a fee. Permissions may be requested from Publi ations Dept, ACM In ., 1515 Broadway, New York, NY 10036 USA, fax +1 (212) 869-0481, or permissionsa m.org. 2
Sandrine Blazy and Philippe Fa on omputations. A physi ist who is familiar with the equations implemented in the ode may prefer to keep variables that are meaningful for him; on the ontrary other users may prefer to see as few variables as possible. In fa t, our partial evaluator is very exible in that respe t. Of ourse, even when there is no repla ement, the known value of a variable is kept in the environment of our simpli ation task, as it an give opportunities to remove useless ode. 2. FORMAL DEVELOPMENT OF THE PARTIAL EVALUATOR Our partial evaluator - as software maintenan e tool - must introdu e absolutely no unforeseen hanges in programs. Therefore, we have used a formal development method. The partial evaluator's behavior is des ribed in natural semanti s [G.Kahn 1987℄ augmented with various set operators: the simpli ation is indu tively dened, by inferen e rules on the Fortran abstra t syntax. These formal on epts were very useful to larify on epts of Fortran (e.g. ommon blo ks in Fortran 77, pointers in Fortran 90) and to model omplex transformations. They also allowed us to prove the orre tness of the partial evaluation, with respe t to the dynami semanti s of Fortran 90, also given in natural semanti s [S.Blazy and P.Fa on 1995℄. Last, our spe i ation is abstra t enough to be easily adapted to any imperative language. 3. DESCRIPTION OF THE TOOL The partial evaluator has been implemented on top of a kernel that has been generated by the generi programming environment Centaur [INRIA 1994℄. When provided with the des ription of a parti ular programming language, in luding its syntax and semanti s, Centaur produ es a language spe i environment. We have merged two spe i environments into an environment for partial evaluation: a Fortran 90 environment, and an environment dedi ated to a language that we have de ned for expressing the s ope of general onstraints on variables. The formal spe i ations have been implemented in a language provided by Centaur, alled Typol, intended to be an implementation of natural semanti s. Thus, the Typol rules are lose to the formal spe i ation rules. Typol programs are ompiled into Prolog ode. Set operators have been written dire tly in Prolog. Although our partial evaluation propagates only equalities (and some spe i inequalities), our initial onstraints on input variables are written in a general language for expressing relations between variables and values, be ause our next work will be to progragate su h relations. As our partial evaluator is a program omprehension tool, we have implemented a sophisti ated graphi al interfa e to fa ilitate the exploration of Fortran appli ation programs. It has been written in Lisp, enhan ed with stru tures for programming ommuni ation between graphi al obje ts and pro esses. Di erent windows visualize with hyperlinks spe ialized versions of a pro edure, propagated data, initial and residual appli ation programs. Usually initial appli ation programs onsist of several Fortran les and ea h le is a Fortran pro edure with about 150 lines of statements. Furthermore several instan es of the tool an be triggered in parallel. The rst experiments with that tool at EDF (the Fren h ele tri ity provider) are very en ouraging [S.Blazy and P.Fa on 1997℄. Partial Evaluation for Program Comprehension
3 4. CONCLUSION Partial evaluation appears to be a promising te hnique not only for program optimization but also for program omprehension by allowing to fo us on a spe i ontext of the omputation. Our partial evaluator may be used in two ways: by visual display of the simpli ed program as part of the initial program (for do umentation or debugging), or by generating this simpli ed program as an independent (exe utable) program. We are urrently working on the propagation of more general onstraints than equalities. Furthermore, partial evaluation is omplementary to program sli ing [K.Gallagher and J.R.Lyle 1991℄, another te hnique for extra ting ode when debugging a program. Program sli ing aims at identifying the statements of a program whi h impa t dire tly or indire tly on some variables values. We believe that merging partial evaluation (a forward walk on the all graph) and program sli ing (a ba kward walk) would improve a lot the redu tion of programs. REFERENCES . 1995. Formal spe i ation and prototyping of a program spe ializer. , Volume 915 of LNCS (May 1995), pp. 666{680. S.Blazy and P.Fa on. 1997. Appli ation of formal methods to the development of a software maintenan e tool. In Automated Software Engineering Conferen e Pro eedings (November 1997), pp. 162{171. IEEE. A.Frazer. 1992. Reverse engineering- hype, hope or here? In Software Reuse and Reverse Engineering in Pra ti e , pp. 209{243. P.A.V. Hall (ed.). K.Gallagher and J.R.Lyle. 1991. Using program sli ing in software mainetnan e. ACM Trans. Soft. Eng. 17, 8, 751{761. INRIA. 1994. Centaur 1.2 Do umentation. INRIA. G.Kahn. 1987. Natural semanti s. In STACS Pro eedings , Volume 247 of LNCS (1987). S.Blazy and P.Fa on In TAPSOFT Conferen e Pro eedings