347
I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES Almagro, 23 y 24 de Noviembre de 2001 Editores: Fernando Orejas Fernando Cuartero Diego Cazorla

I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

  • Upload
    others

  • View
    3

  • Download
    0

Embed Size (px)

Citation preview

Page 1: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

I JORNADAS SOBRE PROGRAMACIÓN Y

LENGUAJES

Alm

agro

, 23

y 2

4 de

Nov

iem

bre

de 2

001

Editores: Fernando Orejas Fernando Cuartero Diego Cazorla

Page 2: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

PRIMERAS JORNADAS SOBREPROGRAMACION Y LENGUAJES(PROLE 2001)Almagro, 23 y 24 de Noviembre de 2001CoordinadorDr. D. Fernando OrejasOrganizaGrupo Alar osUniversidad de Castilla - La Man ha

Page 3: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 4: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

INDICEA Demand Driven Strategy for Lazy Narrowing with Multisets . . . . 1M. Abengozar, P. Arenas, A. GilComputational properties of term rewriting with strategy annotations 17S. Lu asA Proof of Corre tness for the STG Ma hine . . . . . . . . . . . . . . 33A. de la En ina, R. Pe~naImproving the EÆ ien y of Non-Deterministi s Computations . . . . . 49S. Antoy, P. Julian, B. MasseyDynami Programming of Partial Parses . . . . . . . . . . . . . . . . . 63D. Cabrero, J. Vilares, M. VilaresApplying Frameworks and Obje t-Oriented Te hniques for developingLanguage Pro essors Tools . . . . . . . . . . . . . . . . . . . . . . 77M. C. Luengo, D. Basanta, J. E. Labra, N. Gar a, J. M. CuevaLanguage Prototyping in the Maude Metalanguage . . . . . . . . . . . 93M. Clavel, F. Duran, S. Eker, P. Lin oln, N. Mart-Oliet, J. MeseguerPanta Rei (Everything Flows): A Cal ulus of Channels . . . . . . . . . 111F. ArbabINDALOG: A De larative Dedu tive Database Language . . . . . . . 113J. M. Almendros, A. Be erraA de larative debugger of wrong answers for lazy fun tional logi pro-grams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129R. Caballero, M. Rodrguez ArtalejoTransforming Layered Spe i ations into Operational Spe i ations . 145F. J. Galan, J. M. Ca~neteAbstra t Satisability of Linear Temporal Logi . . . . . . . . . . . . . 163M. del Mar Gallardo, P. Merino, E. PimentelDe larative Re e tion and its Appli ation as a Pattern Language . . . 179J. J. Moreno-Navarro, A. Herranz-NievaUn lenguaje modelo para la deni ion y analisis de refa toriza iones . 199Y. Crespo, V. Carde~noso, J. M. Marques

Page 5: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

El Visitante Generi o Extensible . . . . . . . . . . . . . . . . . . . . . 217F. Moya, J. C. LopezGeneri Des ription, Behavior and Animation of Visual Modeling Lan-guages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227H. Ehrig, , R. Bardohl, C. ErmelModelling implementations as institution morphisms . . . . . . . . . . 229C. Domnguez, L. Lamban, V. Pas ual, J.RubioTight and loose semanti s for transformation systems . . . . . . . . . 241F. Orejas, H. Ehrig, E. PinoA Comparison between three Non-determinism Analyses in a Parallel-Fun tional Language . . . . . . . . . . . . . . . . . . . . . . . . . 263R. Pe~na, C. SeguraSin roniza ion Multipro eso en Programas Con urrentes: Sele ionCompletamente k-Justa de Intera iones . . . . . . . . . . . . . . 279D. Ruiz, R. Cor huelo, J. A. Perez, M. ToroCompatibility of Linda Interfa es . . . . . . . . . . . . . . . . . . . . 295A. Brogi, E. Pimentel, A. M. RoldanA Pattern-based Language to Coordinate HPF Tasks . . . . . . . . . . 309M. Daz, B. Rubio, E. Soler y J. M. TroyaReasoning about Probabilisti and Nondeterministi Pro esses . . . . 325D. Cazorla, F. Cuartero, V. Valero, F.L. Pelayo

Page 6: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

INTRODUCCIONEste volumen re oge los trabajos a eptados para su presenta ion en las Pri-meras Jornadas sobre Programa ion y Lenguajes (PROLE 2001) elebradas enAlmagro los das 23 y 24 de Noviembre de 2001, bajo la organiza ion del gru-po Alar os de la Universidad de Castilla - La Man ha. Tambien re oge losresumenes de las dos onferen ias invitadas impartidas por los profesores Far-had Arbab (Amsterdam) y Hartmut Ehrig (Berln).La idea de la organiza ion de estas Jornadas partio de Juanjo Moreno que me onven io para que las pusiera en mar ha. El objetivo era rear un espa io dereunion de los grupos espa~noles que trabajan en temas ligados a la programa iony a los lenguajes de programa ion. Con la organiza ion de este evento, se hapretendido que los, ada vez mas numerosos, grupos que trabajan en Espa~na eneste ambito puedan ono erse mejor, inter ambiar experien ias y resultados deinvestiga ion y, posiblemente, ini iar lneas de oopera ion.El ambito estable ido para PROLE omprende trabajo tanto teori o omopra ti o alrededor de la espe i a ion, dise~no, implementa ion, analisis y veri- a ion de programas y lenguajes de programa ion. Mas on retamente, unalista no exhaustiva de los temas de PROLE in luira: Paradigmas de programa ion (fun ional, logi o, on urrente, orientado aobjetos, visual .) y su integra ion. Espe i a ion y lenguajes de espe i a ion Semanti a y su apli a ion aldise~no, analisis y veri a ion, transforma ion o aprendizaje de programas. Te ni as de analisis de programas Compila ion y herramientas de imple-menta ion de lenguajes de programa ion Te ni as de veri a ion Sistemas de tiposEn un tiempo relativamente es aso se organizo un Comite de Programa for-mado por Jesus Almendros (Universidad de Almera), Mara Alpuente Universi-dad Polite ni a de Valen ia), Javier Esparza (Universidad de Edimburgo) RafaelCor huelo (Universidad de Sevilla), Fernando Cuartero (Universidad de Castilla-La Man ha), Juan Manuel Cueva (Universidad de Oviedo), David de Frutos(Universidad Complutense), Manuel Hermenegildo (Universidad Polite ni a de

Page 7: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Madrid), Juan Hernandez (Universidad de Extremadura), Pas ual Julian Iranzo(Universidad de Castilla-La Man ha), Jordi Levy IIIA-CSIC), Jim Lipton (Wes-leyan University), Juanjo Moreno (Universidad Polite ni a de Madrid), MarisaNavarro (Universidad del Pas Vas o), Robert Nieuwenhuis (Universidad Po-lite ni a de Catalu~na), Fernando Orejas (Universidad Polite ni a de Catalu~na),Ri ardo Pe~na (Universidad Complutense), Ernesto Pimentel (Universidad deMalaga), Isidro Ramos (Universidad Polite ni a de Valen ia), Mario RodrguezArtalejo (Universidad Complutense), Ambrosio Toval (Universidad de Mur ia) yManuel Vilares (Universidad de Coru~na). A ontinua ion se difundio una llama-da para el envo de trabajos, que tuvo onsiderable exito, dado el po o tiempodisponible, y se sele ionaron los trabajos que in luye este volumen.Estas jornadas se realizan onjuntamente on varios eventos, entre los que tie-ne espe ial relevan ia las, ya onsolidadas, VI Jornadas de Ingeniera del Softwarey Bases de Datos (JISBD'2001). Consideramos que la onsiderable interse ion omun, en temas y personas, de ambas Jornadas apoyaba su realiza ion onjun-ta. Esperamos que PROLE pueda tener ontinuidad en el futuro, manteniendosu organiza ion onjunta on las JISBD.Deseo agrade er, espe ialmente, al Grupo Alar os haber a eptado in luira PROLE en el paquete de eventos que organizan, a Fernando Cuartero su olabora ion en la edi ion e impresion de estas a tas.Fernando OrejasPresidente del Comite de Programa de PROLE 2001

Page 8: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Demand Driven Strategy for Lazy Narrowingwith Multisets?M. Abengozar-Carneros, P. Arenas-San hez, A. Gil-LuezasDept. Sistemas Informati os y Programa ion (U. Complutense de Madrid)Fa ultad de CC. Matemati as, Av. Complutense s/n, 28040 Madrid, Spainemail:fmer edes,puri,anagilgsip.u m.esAbstra t. In re ent works, a lazy fun tional logi language with mul-tisets and onstraints, named SETA, was des ribed, in luding a Prolog-based implementation and a well-dened de larative and operational se-manti s. In the present paper, we have hanged the urrent naive lazynarrowing strategy implemented for SETA, in orporating a new demanddriven strategy whi h avoids, in some ases, unne essary omputations,improving the behaviour of the strategy. Furthermore, we have developeda omplete Prolog-based implementation of the language and we have in- orporated it into the lazy fun tional logi system T OY , omparing theold SETA implementation with the new one. Experimental results haveshown good performan e.Keywords: Fun tional logi programming, lazy narrowing, multisets,implementation.1 Introdu tionThe integration of Fun tional and Logi Programming (FLP in short) aims to ombine into a single paradigm the ni est properties of both fun tional and Logi Programming (see [13 for a survey). In many approa hes to FLP programs areseen as onstru tor-based onditional rewrite systems. This is the ase of theCRWL-framework presented in [11, where lassi al equational logi is repla edby a suitable onstru tor-based rewriting logi whi h expresses properly thesemanti s of redu tion for lazy, partial and possibly non-deterministi fun tions.Most approa hes to FLP, in luding CRWL, are based on free onstru tors.However, in some ases the use of non-free onstru tors (in parti ular multi-sets) is very suitable to des ribe some kind of problems, su h as a tion and hange problems [12, [20 or the General Abstra t Model for Multiset Manipula-tion (GAMMA) [8. In [7, authors extend the CRWL-framework in orporatingalgebrai polymorphi datatypes. The new resulting framework, named ACRWL,allows to deal with any kind of non-free onstru tors (in luding multisets). How-ever, like CRWL, ACRWL only supports stri t equalities as possible onstraints.The language SETA, rstly proposed in [5, is an attempt to integrate lazy fun -tional logi programming with multisets, as well as various symboli onstraintsover datatypes (equality, disequality, membership and non-membership). More on retely, the work [5 des ribes an exe utable Prolog spe i ation of the op-erational semanti s of SETA, whi h an be exe uted in any Prolog system withthe ability to solve simple arithmeti onstraints (needed to solve ardinality onstraints). The operational and de larative semanti s of SETA, extended witharithmeti onstraints, was presented in [6, where authors shown that SETAis in fa t an extended instan e of ACRWL. It is an instan e in the sense that? This resear h has been partially supported by the the Spanish CICYT (proje tCICYT-TIC98-0445-C03-02/97 "TREND").

Page 9: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

2 M. Abengozar, P. Arenas, A. Gilthe multiset onstru tor is the unique non-free onstru tor onsidered, but itis an extension sin e it in orporates primitive built-in data (the real numbers)and onstraints in luding equality, disequality, membership and non-membership(CRWL and ACRWL only support stri t equality). Some other interesting ex-tensions of logi programming with (multi) sets are [20, [10, [15, [16, whi h useset uni ation as a parti ular instan e of uni ation modulo equations [14; butno on ern on programming with lazy fun tions is found in these proposals. Withrespe t to fun tional logi programming, we an nd the higher-order languageEs her [17, where sets and multisets an be represented as fun tions rather thanusing data onstru tors (as in SETA). The advantages of ea h representation areproblem dependent (e.g. see [17).The aim of the present paper is to des ribe a new lazy narrowing strategyfor the language SETA, more lazy and eÆ ient than the presented in [5. In [5authors use a naive lazy narrowing strategy, similar to that presented in [18,but hanging the uni ation in order to take into a ount the ommutativityaxiom for multisets. As ommented in [18, [5, the naive strategy performs a lotof redundant work, even more in presen e of multisets, where the existen e of aunique most general unier is lost. What we have done in the present paper is torepla e the naive strategy by a demand driven strategy whi h improves substan-tially the behaviour of the language. The lazy narrowing strategy that we presentuses ideas in the spirit of needed narrowing [18, [2,[3 but with important mod-i ations. In fa t, the demand driven strategy in [18, modifying ex lusively theuni ation to take into a ount multisets, is as bad as the naive. We have alsoextended the syntax of SETA in luding ardinality onstraints, whi h are reallyneeded in order to dete t failures and su esses as soon as possible, withoutevaluating any expression. Although, due to the la k of spa e, in this paper wefo us on the des ription of a demand driven strategy for lazy narrowing withmultisets, we have also developed a omplete Prolog-based implementation ofthe language, in orporating it into the lazy fun tional logi system T OY [19. Infa t, we have three dierent implementations, one supporting the naive strategydes ribed in [5, other with the demand driven strategy of [18, [2, [3 modify-ing the on ept of uni ation, and the last with the demand driven strategy formultisets presented here. Experimental results have shown good performan e ofthe last one.The rest of the paper is organized as follows: Se t. 2 des ribes the languageSETA as presented in [5, in luding a simple but illustrative example. Se t. 3presents the demand driven strategy for lazy narrowing with multisets. Se t. 4 omments very brie y on the Prolog-based implementation for SETA and showsseveral experimental results. Some on lusions are pointed in Se t. 5.2 The language SETAOur presentation of SETA follows exa tly the lines of [5. In the urrent imple-mentation, ardinality onstraints have been in orporated to lose SETA's syntaxto omputed answers (see next se tion).We assume a ountable set TV of type variables A;B; : : : ; et . and a ount-able ranked alphabet TC = Sn0 TC n of type onstru tors, in luding the multi-set type onstru tor mset 2 TC 1. Polymorphi types ; 0 2 TTC (TV ) are builtfrom TV and TC . In the following tvar() stands for the set of type variables o - urring in . We dene a polymorphi signature over TC as hTC ;DC ;FS ;PS i,where:

Page 10: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Demand Driven Strategy for Lazy Narrowing with Multisets 3. DC is a set of type de larations for data onstru tors, of the form : (1; : : : ;n) ! 0, with Sni=1 tvar(i) tvar(0). We assume that DC ontainsthe type de larations f[ g :! mset(A) (representing the empty multiset)and f[ j g : (A;mset(A)) ! mset(A) (representing the multiset on-stru tor1). The multiset onstru tor is governed by the equation (mset):f[X;Y jXs g f[Y;X jXs g. Here, we have used f[X;Y jXs g as an abbrevia-tion for f[X jf[Y jXs g g. In the sequel we will ontinue using su h notation.. FS is a set of type de larations for fun tion symbols, of the form f : (1; : : : ;n)! .. PS = f==; ==: (A;A);2; 62: (A;mset(A))g is a set of type de larations forpredi ate symbols. == and == stand for stri t equality and disequality respe -tively, whereas 2, 62 represent membership and non-membership respe tively.We will write h 2 DC n [ FSn to indi ate the arity of a symbol a ordingto its type de laration. Assuming another ountable set DV of data variablesX;Y; et ., expressions e; r; l : : : 2 E(DV ) are built from DV , DC and FS .Terms TDC (DV ) E(DV ) are built by using only DV and DC . A onstraint' 2 R(DV ) is dened as ' ::= e1e2, where e1; e2 2 E(DV ) and 2 f==,==, 2, =2g.A program rule for f 2 FSn has the form: f(t1; : : : ; tn) = r ( '1; : : : ; 'm,where the left-hand side is linear (i.e., without multiple o urren es of variables),ti 2 TDC (DV ), 1 i n, r 2 E(DV ), all variables o urring in r o ur alsoin the left-hand side and 'j 2 R(DV ), 1 j m. Program rules must be well-typed in the usual way; see e.g. [5. We dene programs as pairs P = h;Ri,where is a polymorphi signature and R is a nite set of program rules fordened fun tion symbols in FS . Programs must be well-typed, i.e., all programrules must be well-typed.Goals G have the form: '1; : : : ; 'm, where 'j 2 R(DV ), 1 j m, andmust be well-typed in the usual way; see e.g. [5.A solution for a goal is a pair hSS ; i, where SS = fX1 = t1; : : : ; Xn = tngis a system of equations in solved form, i.e., ea h variable Xi o urs only on ein SS, ti 2 TDC (DV ), 1 i n, and is a set of onstraints in solved form.There are two kinds of onstraints in solved form: X== t (with t dierent fromX) and t 62 Xs. SETA's implementation is designed in su h a way that SS is omputed by Prolog's uni ation, whereas is omputed by using a onstraintstore (whi h is updated by the proper implementation).Example 1. As an example, onsiderTC = fa tion0 ; bool0g,DC = fsleep; study ;work ; doShopping :! a tion ; true; false :! boolg and the fun tion symbolsFS = fasBusy : (mset(a tion); mset(a tion)) ! boolg. A multiset of a tionsrepresents the daily tasks of a person. The fun tion asBusy(M ;N ) below he ksif M has to do at least the same tasks as N . Of ourse, the a tion of sleeping isnot onsidered. The ode for fun tion asBusy is the following:(R1 ) asBusy(Xs; f[ g) = true(R2 ) asBusy(Xs; f[ sleepjYs g) = asBusy(Xs;Ys)(R3 ) asBusy(f[X jXs g; f[Y jYs g) = asBusy(Xs;Ys) ( X == Y ;X == sleepA possible goal for this program would be:Y =2 f[X jYs g; asBusy(f[X jYs g; f[ sleep;work ; doShopping g) == true ;1 The intended meaning of f[XjXs g is to add a new opy of the element X to themultiset Xs.

Page 11: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

4 M. Abengozar, P. Arenas, A. Gilfor whi h we expe t, among others, the solutions:hfX = work ;Ys = f[ doShopping jZs gg; fY == work ;Y == doShopping ;Y =2 ZsgihfX = doShopping ;Ys = f[work jZs gg; fY == work ;Y == doShopping ;Y =2 ZsgihfYs = f[work ; doShopping jZs gg; fY == work ;Y == doShopping ;Y == X ;Y =2 ZsgiNote that, be ause of the axiom (mset), we get dierent solutions by bindingX and Ys onveniently. Note also that there are more solutions oming from onsidering sleep as a possible element of Ys . In fa t, there are innite solutions.3 A Demand Driven Strategy for SETAThis se tion des ribes a Demand Driven Strategy (ddsm, for short) to deal withmultiset uni ation, omparing this strategy with other existing ones. First ofall, note that as in AC1-uni ation (see [14), the uni ation between two termsinvolving multisets may have several in omparable uniers, even for very simpleuni ation problems, as e.g. f[X;Y g = f[ a; b g (whereX ,Y are dierent variablesand a,b dierent onstant symbols), whi h has two dierent uniersX = a; Y = bandX = b; Y = a. Another diÆ ulty is related to pattern mat hing. For instan e,mat hing a given expression e with a multiset pattern su h as f[ ajXs g annotbe solved simply by redu ing e to head normal form (i.e., variable or outermost onstru tor). Imagine that e happens to redu e to the expression f[ b; ajYs g! Thisshows that lazy evaluation is mu h harder to implement in presen e of multisets.Nevertheless, laziness must be preserved as mu h as possible.In [5 the authors present a Prolog-based implementation for SETA, based onthe idea of translating multisets into Prolog terms whi h keep information abouttheir ardinalities. Su h a representation turns out very useful when solvingequality or disequality onstraints sin e allows to dete t failures and su esseswithout evaluating. As an example, a disequality of the form f[ f; f g== f[ f g,where f is a fun tion symbol dened by the rule f = f (diverges) su eeds be- ause of dis repan y of ardinalities (f is not evaluated!). However, the proposalof [5 has two important drawba ks. Firstly, there is a disagreement betweenSETA's syntax and omputed answers. The reason is that multiset representa-tion in Prolog, although ingenious, for es to use onstraints about ardinalitieswhi h are solved by a onstraint solver (more on retely, by the solver for real onstraints of Si stus Prolog [21). Hen e, omputed answers ontain ardinality onstraints, not allowed in SETA's syntax. As an example, a goal of the formf[X jXs g== f[ a; b g would ompute the solution hfXs = Ys : Lg; fL== 1gi, ex-pressing that both multisets have dierent ardinality. As shown by the example,the answer ontains multiset variables (Ys : L) and real onstraints (L== 1) notallowed in SETA's syntax. Se ondly, the lazy narrowing strategy they use (i.e., theway of translating program rules to Prolog) is very ineÆ ient, even without usingmultisets. More on retely, in [5 authors implement the naive lazy narrowingstrategy presented rstly in [18, but hanging the pro ess of uni ation to on-sider multisets. As a result, any program rule of the form f(t1; : : : ; tn) = r ( 'is translated2 into the prolog lause:f (X1 ; : : : ;Xn ;H ) : unify(X1 ; t1 ); : : : ; unify(Xn ; tn); solve('); hnf (r ;H ).2 Of ourse, all expressions o urring at the program rule at hand must be translatedinto their orresponding Prolog terms. We are not onsidering su h a translationbe ause it is irrelevant for the understanding of the problem.

Page 12: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Demand Driven Strategy for Lazy Narrowing with Multisets 5The argument H of f returns the head normal form of the evaluation of therule, the predi ate solve solves the onstraint ', hnf omputes the head normalform of its rst argument, returning the result in the se ond one, and nally,predi ate unify unies an expression with a term, possibly involving multisets.As an example onsider the fun tion p whi h returns true if a multiset ontainseither the onstant symbol a or both onstant symbols a and b.p(f[ ajXs g) = true g1 = b h = f[ g1 ; g2 gp(f[ a; bjXs g) = true g2 = aA goal of the form p(h) == L returns the solution L = true twi e, sin e bothrules of p an be applied. Imagine the translation of p into Prolog by followingthe naive strategy. In order to ompute both answers, we would need to all,rstly to unify(h; f[ ajXs g) and se ondly to unify(h; f[ a; bjXs g). The rst all tounify omputes the head normal form of h (whi h is f[ g1 ; g2 g), and afterwards,tries to unify su h a head normal form with f[ ajXs g by evaluating g1 (whi his b) to head normal form. Sin e b and a are not synta ti ally uniable, theuni ation pro ess (embedded in predi ate unify) mutates the multiset f[ g1 ; g2 greturning f[ g2 ; g1 g. Then omputes the head normal form of g2 (whi h is a)and again, he ks the synta ti uni ation, that in this ase su eeds gettingthe rst solution. If we would want to ompute the se ond solution, solving the all unify(h; f[ a; bjXs g), then we would need to revaluate h, g1 and g2 to headnormal form. All head normal forms omputed to al ulate the rst solution arelost!As an improvement over the naive strategy without multisets, in [18 authorsspe ify a so alled demand driven strategy, using denitional trees [1 to guideuni ation with the left-hand sides of rewrite rules. The idea is roughly as follows:given a set of rules S for a fun tion symbol f 2 FSn , we partitionate S a ordingto demanded positions. Ea h resulting subset Si will have demanded the positioni , i.e., in su h a position all rules in Si will have a term with a onstru tor at head.As a onsequen e, in order to narrow an expression of the form f (e1 ; : : : ; en ),the head normal form hi of ei will be omputed only on e, and after this, wewill apply the asso iated rule depending on the form of hi . Note that the naivestrategy would revaluate ei to head normal form as many times as rules in Sibefore the rst one yielding su ess. As an example, fun tion p above would betranslated, following the demand driven strategy in [18 (modifying onvenientlythe uni ation pro ess, as in the naive strategy), as follows:p0 (A;H ) :- hnf (A;HA); p1 (HA;H ):p1 (A;H ) :- unify(A; f[Y jYs g); hnf (Y ;HY ); p2 (f[HY jYs g;H ):p2 (f[Y jYs g;H ) :- unify(Y ; a); hnf (true;H ):p2 (f[Y jYs g;H ) :- unify(Y ; a); hnf (Ys;HYs); p3 (f[ ajHYs g;H ):p3 (f[ ajYs g;H ) :- unify(Ys; f[Z jZs g); hnf (Z ;HZ ); p4 (f[ a;HZ jZs g;H ):p4 (f[ a;Y jYs g;H ) :- unify(Y ; b); hnf (true;H ):Note that the rst argument of both rules for p is demanded sin e it has themultiset onstru tor at head. For su h a reason, the lause p0 omputes the headnormal form of the rst argument (the evaluation always is required). Similarly,the position o upied by the onstant a in rules for p is also demanded. Hen e,the lause p1 omputes the head normal form for su h position. The se ond lause for p2 orresponds to the se ond rule of p, that demands the evaluationof the rest of the multiset. After this, su h a rule demands also the evaluationof the head of the tail of the multiset, what is re e ted by lause p3 . If we

Page 13: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

6 M. Abengozar, P. Arenas, A. Gil onsider again the goal p(h) == L, we an observe that the head normal formof h is omputed only on e in order to apture both solutions. In general, thisimproves the behaviour of the naive strategy. However, in presen e of multisets,this ode may revaluate head normal forms in the same way that the naivestrategy does. The problem relies on the need of mutating. Let us follow theexe ution of the goal from the all p1 (f[ g1 ; g2 g;H ). The head normal form ofg1 (whi h is b) is omputed. Sin e b and a are not uniable, then the uni ationpro ess mutates the multiset returning the f[ g2 ; g1 g (as in the naive strategy).Then omputes the head normal form of g2 (whi h is a) and again, he ks thesynta ti uni ation, that in this ase su eeds, getting the rst solution byapplying the rst lause of p2 . To ompute the se ond solution, by the se ond lause of p2 , we need to evaluate g1 (previously omputed!) to head normalform. Basi ally the problem now is that the evaluation to head normal form ofthe elements of a multiset is not kept!What we have done in the present paper is to modify the above demanddriven strategy in two senses: First, we have separated the uni ation pro essfrom the mutation pro ess, and se ond, we have mixed the head normal formpro ess with the mutation pro ess. As an introdu tory example of the new re-sulting strategy ddsm, we anti ipate the new ode for fun tion p:p0 (A;H ) :- hnf (A;HA); p1 (HA;H ):p1 (A;H ) :- mutateHnf (A;HA); unifyHnf (HA; f[Y jYs g); p2 (f[Y jYs g;H ):p2 (f[Y jYs g;H ) :- unifyHnf (Y ; a); hnf (true;H ):p2 (f[Y jYs g;H ) :- unifyHnf (Y ; a); hnf (Ys;HYs); p3 (f[ ajHYs g;H ):p3 (f[ ajYs g;H ) :- mutateHnf (Ys;HYs); unifyHnf (HYs; f[Z jZs g); p4 (f[ a;Z jZs g;H ):p4 (f[ a;Y jYs g;H ) :- unifyHnf (Y ; b); hnf (true;H ):where unifyHnf does the synta ti uni ation between its two arguments, notmutating. The need of this predi ate is due to the onstraints supported by SETA.We will omment on this later. For the moment we an think only on synta ti uni ation. Predi ate mutateHnf reorganizes the representation of a multiset indierent ways, trying to bring all the elements at the head position, omputingtheir head normal forms. Now, the omputation of the goal p(h) == L does notrevaluate anything. By p0 , the head normal form of h is omputed. After this,predi ate mutateHnf returns f[ b; g2 g. Sin e the uni ation between a and bfails, there is a ba ktra king pro ess over predi ate mutateHnf , whi h returnsas new solution f[ a; b g (does not destroy the previously omputed head normalform). Finally, both lauses for p2 ompute the solutions.3.1 Denitional TreesIn order to des ribe the ddsm strategy, we rely on the idea of using denitionaltrees [1,[18 as a tool to generate the Prolog ode asso iated to ddsm. However,as we will see later, our denitional trees are not identi al to the presented onesin the previous works, sin e the presen e of multisets requires new kinds of nodesin order to onsider the axiom (mset). Before presenting formally the algorithmto generate denitional trees, we need some auxiliary on epts similar to thatdened in [18.Preliminary notions Let f 2 FSn be a dened fun tion symbol in a programP = h;Ri:. Rf stands for the set of all rules for f in P .

Page 14: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Demand Driven Strategy for Lazy Narrowing with Multisets 7. A all pattern for f is any linear expression of the form f(t1; : : : ; tn), whereti 2 TDC (DV ), 1 i n.. A generi all pattern for f is any all pattern for f of the form f(X1; : : : ; Xn),where Xi, 1 i n, are pairwise distin t variables.Let pat1 and pat2 be two all patterns. We say that pat1 mat hes pat2 ipat1 is an instan e of pat2 via some term substitution (a mapping from DV toTDC (DV )). Moreover, pat2 is a variant of pat1 i this term substitution is avariable renaming.Given a all pattern pat , P(pat) denotes the set of all positions in pat , andit is dened re ursively as follows:. P(t) = f"g if t 2 DV [ DC 0 , where " stands for the empty position.. P(f(t1; : : : ; tn)) = f1; : : : ; ng [Sni=1fi uju 2 P(ti)g, if f 2 FSn.For instan e, if pat = f( (X;Y ); d(Z; d); s(W )), then P (pat) = f1; 1 1; 1 2; 2; 2 1; 2 2; 3; 3 1g. u 2 P (pat) identies the subterm t of pat o urring atposition u. If t has a onstru tor symbol at head, then u also identies .For the example at hand, position 1 refers to (X;Y ) and also to . Similarly,position 2 1 identies variable Z. VP(pat) P(pat) denotes the set of variablepositions in pat . Following with our example, VP(pat) = f1 1; 1 2; 2 1; 3 1g.Let pat be a all pattern for a fun tion symbol f , whi h mat hes the left-handside of at least one dening rule Rul l = r ( ' in Rf . Let u be a position inVP(pat). We say that:. u is a demanded position by Rul i l has a onstru tor at position u.. u is a uniformly demanded position by a set of rules S Rf i u is ademanded position by every rule in S.As an example, onsider the fun tion asBusy dened in Example 1 togetherwith the generi all pattern pat = asBusy(X ;Y ). Position 2 2 VP(pat) is uni-formly demanded by RasBusy , sin e the se ond argument of all rules in RasBusyhas a (multiset) onstru tor at head. Position 1 2 VP(pat) is demanded only byrule (R3 ) (and also uniformly demanded by the set f(R3 )g), whi h has, in itsrst argument, the multiset onstru tor at head.Generation of denitional trees Let f be a dened fun tion symbol. Thedenitional tree of f is built a ording to the re ursive algorithm dt below. Ageneri all to dt has the form dt(pat ; oldpat ;S ), where pat is a all pattern,oldpat is (intuitively) the last modied pat 's an estor in the tree, and S Rf .An initial all to dt is as follows: dt(pat ; pat ;Rf ), where pat is a generi allpattern (note that in this ase oldpat = pat). The algorithm termination anbe proved by onsidering that any all dt(pat ; oldpat ;S ) veries the followinginvariant properties:. S Rf .. pat = oldpat or pat = oldpat [Y=d(Z1; : : : ; Zn), where Y is a variable o - urring at a uniformly demanded (by S) position in oldpat . The notationpat [Y=t stands for the result of repla ing in pat the variable Y by the termt. In the sequel, we will ontinue using su h notation. Similarly, we will useZn to denote Z1; : : : ; Zn.. If VP(pat) has no uniformly demanded positions by S , then left-hand side ofrules in S are variants of pat .

Page 15: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

8 M. Abengozar, P. Arenas, A. Gildt-AlgorithmBe ause of item (a.1) below, for the des ription of the algorithm we willassume that all multisets o urring at left-hand sides of program rules have beenreorganized in order to put at the beginning all elements with a onstru tor athead. For instan e, the multiset f[X; a; Y; bjZs g, where a; b are onstant symbolsand X;Y; Zs are variables would be reorganized as f[ a; b;X; Y jZs g3.1. dt(pat ; oldpat ;S ) = ; if S = ;.2. Otherwise, ompute VP(pat) and distinguish the following ases:(a) Some position in VP(pat) is uniformly demanded by S. Let u be the leftmostone (this hoi e is arbitrary) and let X be the variable at position u in pat .Let 1; : : : ; k be all dierent onstru tors o urring at position u in the left-hand sides of rules in S (we assume that these i are taken in textual order).Let Siu be the subset of S omposed of those rules ontaining i at positionu (1 i k). For ea h i, 1 i k, build the new all pattern:pati = pat[X= i(X1; : : : ; Xmi)where mi is the arity of i and Xj , 1 j mi, are new variables.(a.1) If u p1 ::: pm1 1 (m > 1) and the symbol at position p1 ::: pm1in pat is the multiset onstru tor4, then:dt(pat ; oldpat ; S) = pat mutate hnf 1 : dt(pat1 ; pat ; S 1u ) 2 : dt(pat2 ; pat ; S 2u ): : : k : dt(patk ; pat ; S ku )(a.2) Otherwise:(a.2.1) If pat = oldpat[Y=f[ZjZs g then the denitional tree has thefollowing form:dt(pat ; oldpat ; S) = pat mutate ase X of 1 : dt(pat1 ; pat ; S 1u ) 2 : dt(pat2 ; pat ; S 2u ): : : k : dt(patk ; pat ; S ku )(a.2.2) Otherwise, the denitional tree has the form:dt(pat ; oldpat ; S) = pat ase X of 1 : dt(pat1 ; pat ; S 1u ) 2 : dt(pat2 ; pat ; S 2u ): : : k : dt(patk ; pat ; S ku )(b) Some position in VP(pat) is demanded, but none of them is uniformly de-manded. Let u1; : : : ; uk be those positions in VP(pat) whi h are demanded,taken in the same order as they o ur as demanded positions in the rules.For ea h 1 i k, we dene re ursively the sets of rules Q0 = S, Qi =Qi1Sui , Sui = fRul j Rul 2 Qi1 demanding the position uig. Let S0 be3 Of ourse, there exists more possible representations. But we need only to ensurethat a,b are at the beginning. It does not matter the order between them.4 As ommented at the beginning of this se tion, all demanded elements in a multisetare at the beginning.

Page 16: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Demand Driven Strategy for Lazy Narrowing with Multisets 9the set of rules of S whi h does not demand any position (S0 = Qk). Thenthe denitional tree has the following form:dt(pat ; oldpat ; S) = pat ordt(pat ; oldpat ; S0 )dt(pat ; oldpat ; Su1 ): : :dt(pat ; oldpat ; Suk )( ) No position in VP(pat) is demanded. All the left-hand sides of rules in S arevariants5 of pat . Let pat = ri ( 'i, 1 i m, be renamings of rules in Swith the left-hand side equal to pat, taken in textual order.( .1) If pat = oldpat [X =f[Z jZs g, then the denitional tree has the followingform:dt(pat ; oldpat ; S) = pat mutate tryhr1 ( '1jr2 ( '2j : : :jrm ( 'mi( .2) Otherwise, the denitional tree has the following form:dt(pat ; oldpat ; S) = pat tryhr1 ( '1jr2 ( '2: : :jrm ( 'miBefore explaining brie y the dt-algorithm, we are going to present an exam-ple showing the stru ture of the denitional tree asso iated to the generi allpattern asBusy(A;B) from Example 1.asBusy(A;B)(((((((((asBusy(A;f[ g)B=f[ g ase?truetry

hhhhhhhhhasBusy(A;f[ Y jYs g)B=f[Y jYs g(((((((asBusy(A;f[ Y jYs g)fR2g orhhhhhhhasBusy(A;f[ Y jYs g)fR3gasBusy(f[XjXs g; f[Y jYs g)mutate aseA=f[XjXs g?asBusy(Xs;Ys) ( X == Y;X== sleepmutate tryasBusy(A;f[ sleepjYs g)mutate hnfY=sleep?asBusy(A;Ys)tryIn general, denitional trees show how to ompute goals by following theddsm strategy. In our example at hand, the evaluation of a all asBusy(e1 ; e2 ),e1; e2 2 E(DV ), requires the evaluation of e2 to head normal form (h2) in orderto look for either the empty multiset (rule (R1 )) or the multiset onstru tor(rules (R2 ); (R3 )). In the root, position 2 is uniformly demanded by all rulesof asBusy , thus the root is a ase-node. If h2 and the empty multiset unify,5 Be ause of the invariant properties.

Page 17: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

10 M. Abengozar, P. Arenas, A. Gilthe solution true is returned (try-node). Otherwise, if h2 and f[Y jYs g unify,we have two possibles rules ((R2 ), (R3 )) to ontinue (or -node), whi h do notdemand uniformly any new position. The leftmost subtree of the or -node worksonly on rule (R2 ). Sin e su h a rule has the onstru tor sleep as rst element ofthe multiset o urring at se ond argument, then a mutate hnf -node is required.Su h a node indi ates that the multiset f[Y jYs g must be mutated in orderto put as head of the multiset the onstant symbol sleep (this pro ess will bedone by predi ate mutateHnf des ribed in Se t. 3.2). After this, a re ursive all asBusy(A;Ys) is exe uted (try-node). The rightmost subtree of the or -nodeuses rule (R3 ). This rule demands the evaluation of e1 to head normal form (h1)without forgetting that we are in presen e of a multiset. For su h a reason amutate ase-node is required in order to possibly mutate the multiset f[Y jYs g.If the uni ation between h1 and f[X jXs g su eeds, we an then apply rule(R3 ). But sin e the last uni ation involved a multiset, now it is needed to usea mutate try-node to take into a ount the possible mutations of f[X jXs g.As we have just seen in the above example, a denitional tree may haveor (item (b)), ase (item (a.2.2)) and try (item ( .2)) nodes (similarly to [18)together with three new types of nodes (to manage multisets): mutate ase (item(a.2.1)), mutate try (item ( .1)) and mutate hnf (item (a.1)). mutate ase andmutate try nodes are needed to implement the uni ation modulo the equationalaxiom (mset). A mutate hnf node, also manages multiset uni ation, avoidingrevaluations of head normal forms, as shown at the beginning of this se tion.mutate try nodes are similar to try nodes, i.e., they are used to apply pro-gram rules in order to return a solution. The dieren e between these two nodesrelies on the presen e of multisets. If the last uni ation pro ess in the tree in-volved multisets, then a mutate try node is required in order to possibly mutatethe multiset before getting a solution. mutate ase and mutate hnf nodes aresimilar to ase nodes in the sense that there exists a uniformly demanded posi-tion. Again, the dieren e relies on the presen e of multisets whi h requires themutation of the multiset (mutate ase and mutate hnf nodes) before evaluat-ing to head normal form the demanded position. However, there are substantialdieren es between mutate ase and mutate hnf nodes. A mutate ase node isused in presen e of multisets not having demanded elements6. Hen e, there is noevaluation to head normal form of elements! On the ontrary, a mutate hnf nodeis used in presen e of multisets of the form f[ tjXs g, where t has a onstru torat head (i.e., the position of the rst element is demanded). In su h a ase weneed to mutate the multiset but also to ompute the head normal form of thedemanded element (trying not to lose it). For su h a reason, a mutate hnf nodedoes a spe ial kind of mutation whi h, simultaneously, evaluates the element tohead normal form and does the mutation. Any other possible mutation of themultiset would not destroy the head normal form previously omputed.3.2 Prolog translation of program rulesFrom a given denitional tree for a fun tion symbol f , we an generate theProlog ode for f . The generated ode makes use of several auxiliary predi ates,for whi h we are going to give a brief des ription:. hnf (E ;H ) omputes a head normal for E in H . We remark that an expressionis in head normal form i it is either a variable or an expression with a onstru tor at head. The Prolog lauses for hnf are:6 Given a multiset f[ t1; t2; : : : ; tnjX g, by elements we mean t1; : : : ; tn.

Page 18: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Demand Driven Strategy for Lazy Narrowing with Multisets 11hnf (f (En);H ) :- !; f (En ;H ):hnf (E ;H ) :- H = E :Note that the head normal form for a fun tion all is omputed by alling topredi ate f (En ;H ). This last predi ate will be spe ied below, when givingthe algorithm whi h translates the denitional tree of f into Prolog lauses(whi h simulates the ddsm strategy).. unifyHnf (E ;T ) unies synta ti ally E and T (whi h are in head normalform). Its asso iated Prolog lauses are:unifyHnf (E ;T ) :- var(E); !; extra tAndPropagateCtr(E); E = T :unifyHnf (E ;T ) :- T = E :The rst lause of unifyHnf unies a variable with a term. Sin e SETA in- orporates onstraints, before doing the uni ation E = T , we need to he kthat E is not \ onstrained" by T . For instan e, if the variable E has as asso i-ated onstraint E== T , then the uni ation between E and T is not possible.This is he ked by predi ate extra tAndPropagateCtr whi h imposes on T allthe onstraints asso iated to E . All onstraints asso iated to a variable willbe stored in a onstraint store. Whenever we impose a onstraint on a variableX , su h a onstraint will be stored in the onstraint store. Similarly, when-ever a variable X is bound to a term T , we will impose on T all onstraintsfor X . The onstraint store is also used to ompute the nal solution, more on retely, the part referring to onstraints in solved form. For su h a reason,the onstraint store only ontains onstraints in solved form. Due to the la kof spa e, we have fo used on the ddsm strategy, dis arding the managementof onstraints. Interested readers an onsult, e.g., [5.Note that, dierently to [5, the predi ate unifyHnf does synta ti uni ation.In [5 the uni ation is done modulo the equational axiom (mset).. mutateHnf (E ;R) reorganizes the representation of a multiset trying to bringall the elements ( omputing their head normal form) at the head position.For instan e, onsider the program rules f = 2 and g = 3, and the multisetf[ f; g g. A all to mutateHnf (f[ f ; g g;R) would return f[ 2; g g as rst solutionand f[ 3; 2 g as se ond solution. The predi ate mutate is similar to predi atemutateHnf but without omputing head normal forms for elements. Thus, a all to mutate(f[ f ; g g;H ) would return f[ f; g g as rst solution and f[ g; f gas se ond solution. The Prolog ode for mutateHnf and mutate is:mutateHnf (Xs;R) :- var(Xs); !; extra tAndPropagateCtr(Xs); Xs = R:mutateHnf (f[E jEs g;R) :- hnf (E ;HE);mutate aux (f[HE jEs g;R):mutate aux (f[E jEs g;R) :- R = f[E jEs g:mutate aux (f[E jEs g; f[Y ;E jYs g) :- hnf (Es;HEs);mutateHnf (HEs; f[Y jYs g):mutate(Xs;R) :- var(Xs); !; extra tAndPropagateCtr(Xs); Xs = R:mutate(f[E jEs g;R) :- R = f[E jEs g:mutate(f[E jEs g; f[Y ;E jYs g) :- hnf (Es;HEs);mutate(HEs; f[Y jYs g):The g -algorithmThe g -algorithm generates all Prolog predi ates asso iated to a fun tionf 2 FSn by means of its asso iated denitional tree (the rst argument ofg ). The names of su h predi ates are built from the demanded positions in Rf ,hen e the algorithm will have a se ond argument in whi h to keep the sequen e ofdemanded positions (of the form u1 u2 : : : un). A generi all to g has the formg (tree; positions), whereas an initial all has the form g (dt(f ( Xn); f ( Xn));Rf ); "),

Page 19: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

12 M. Abengozar, P. Arenas, A. Gilwhere " is the empty sequen e of positions. A all to g (tree; positions) generatesProlog lauses as follows:(1) If tree = ; then g (tree; positions) = ;.(2) If tree = pat mutate hnf 1 : tree1 2 : tree2: : : m : treemthen, let NY be a new variable. By onstru tion of the denitional tree,oldpat = f (tj ), 1 j n, and pat = oldpat [Y =f[Z jZs g. Let u 1 be theposition of Z and then u the position of the multiset f[ZjZs g in pat . Buildt0j as tj [Y=f[ZjZs g. Then the following lause is generated:f positions(tj ;H ) :- mutateHnf (Y ;NY ); unifyHnf (NY ; f[Z jZs g);f positions u:1 (t 0j ;H ):and the alls g (treei ; positions u:1 ), 1 i m, are generated.(3) If tree = pat mutate ase X of 1 : tree1 2 : tree2: : : m : treemthen let NY be a new variable. By onstru tion of the denitional tree,oldpat = f (tj ), 1 j n, and pat = odpat [Y =f[Z jZs g. Let u be the positionof X in pat and HX be a new variable. Build t0j as tj [Y=f[ZjZs g[X=HX .Then the following lause is generated:f positions(tj ;H ) :- mutate(Y ;NY ); unifyHnf (NY ; f[Z jZs g);hnf (X ;HX ); f positions u(t 0j ;H ):and the alls g (treei ; positions u), 1 i m, are generated.(4) If tree = pat ase X of 1 : tree1 2 : tree2: : : m : treemthen let u be the position of X in pat and HX be a new variable.(4.1) If oldpat = pat = f (tj ), 1 j n, then build t0j as tj [X=HX . Thefollowing Prolog lause is generated:f positions(tj ;H ) :- hnf (X ;HX ); f positions u(t 0j ;H ):(4.2) If oldpat = f (tj ), 1 j n, and pat = oldpat [Y =d( Zk ) where d 2DC kff[ j gg, then build t0j as tj [Y=d( Zk)[X=HX . Then the followingProlog lause is generated:f positions(tj ;H ) :- unifyHnf (Y ; d( Zk)); hnf (X ;HX ); f positions u(t 0j ;H ):In both ases the alls g (treei ; positions u), 1 i m, are generated.(5) If tree = pat ortree0tree1: : :treekthen we have the ode generated by the alls g (treei ; positions), 0 i k.(6) If tree = pat mutate tryhr1 ( '1jr2 ( '2: : :jrm ( 'mi

Page 20: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Demand Driven Strategy for Lazy Narrowing with Multisets 13then let NY be a new variable. By onstru tion of the denitional tree,oldpat = f (tj ), 1 j n, and pat = odpat [Y =f[Z jZs g. Build r0i as ri[Y=f[ZjZs gand '0i as 'i[Y=f[ZjZs g. Then, for ea h alternative, the following Prolog lause is generated:f positions(tj ;H ) :- mutate(Y ;NY ); unifyHnf (NY ; f[Z jZs g); solve('0i); hnf (r 0i ;H ):These lauses are generated in the textual order of rules of f in the program.(7) If tree = pat tryhr1 ( '1jr2 ( '2: : :jrm ( 'mi(7.1) If oldpat = pat f (tj ), 1 j n, then for ea h alternative, generatethe lause:f positions(tj ;H ) :- solve('i); hnf (ri ;H ):(7.2) If oldpat = f (tj ), 1 j n, and pat = oldpat [Y =d( Zk ) where d 2DC k ff[ j gg, then build r0i as ri[Y=d( Zk) and '0i as 'i[Y=d( Zk). Forea h alternative, generate the lause:f positions(tj ;H ) :- unifyHnf (Y ; d( Zn)); solve('0i); hnf (r 0i ;H ):In both ases, lauses are generated a ording to textual order of the rules off in the program. On the other hand, the predi ate solve solves the ondition( onstraints) of a rule.Example 2. The Prolog translation for fun tion asBusy in Example 1 generatesthe following Prolog lauses:asBusy(A;B ;H ) :- hnf (B ;HB); asBusy 2 (A;HB ;H ):asBusy 2 (A;B ;H ) :- unifyHnf (B ; f[ g); hnf (true;H ):asBusy 2 (A;B ;H ) :- mutateHnf (B ;HB); unifyHnf (HB ; f[Y jYs g)asBusy 2 2 :1 (A; f[Y jYs g;H ):asBusy 2 (A;B ;H ) :- mutate(B ;HB); unifyHnf (HB ; f[Y jYs g); hnf (A;HA);asBusy 2 1 (HA; f[Y jYs g;H ):asBusy 2 2 :1 (A; f[Y jYs g;H ) :- unifyHnf (Y ; sleep); hnf (asBusy(A;Ys);H ):asBusy 2 1 (A; f[Y jYs g;H ) :- mutate(A;HA); unifyHnf (HA; f[X jXs g);solve([X == sleep;X == Y ); hnf (asBusy(Xs;Ys);H ):4 ImplementationCurrently we have implemented ddms, the naive strategy in [5 and the demanddriven strategy (dds in the table below) in [18 modied to support multisetmanagement. The three strategies have been in orporated into the system T OY[19 (implemented in Si stus Prolog) as independent modules. For an eÆ ientimplementation, several optimizations are required. As an example, following ate hnique introdu ed by Cheong [9, we modify the representation of expressionsto support sharing. The system T OY in luding the module for ddms an beloaded from http://titan.sip.u m.es/toy/multisets.tar.gzOur implementation extends the language SETA presented in Se t. 2 witharithmeti onstraints and also with ardinality onstraints. As ommented inSe tion 3, the in orporation of ardinality onstraints to SETA lose the syn-tax of the language to omputed answers. The management of onstraints, as

Page 21: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

14 M. Abengozar, P. Arenas, A. Gil ommented in Se tion 3.2, is ontrolled by a onstraint store whi h keeps those onstraints asso iated to a variable. Su h a onstraint store is updated ea h timea onstraint is imposed on a variable. Also plays an important role when bindingvariables, sin e it is ne essary to he k (by onsulting the onstraint store) thatthe binding is possible.To illustrate the performan e of our strategy we use the SETA program pre-sented in Se tion 3 but adding a new onstant symbol and modifying thefun tions g1 , g2 as follows:g1 = b( genList(20000 ) == L genList(0) = [ g2 = a( genList(20000 ) == L genList(N) = [ jgenList(N 1)( N > 0The table below shows the time onsumed to obtain either all solutions orthe rst one (as shown in the table) of the orresponding goals. For the ase ofall solutions, the time needed to dete t that a goal has no more solutions is alsoin luded. Time is measured in millise onds. On the other hand, in order to gettimes, we have hanged the textual order of both rules of p. The goal -whi h isa s heme goal over the parameter N - is p(f[ ; : : : ; | z N ; g1; g2 g) == L.N=0 N=1 N=1 N=5 N=8(all solutions) (all solutions) (rst solution) (rst solution) (rst solution)naive 16330 19140 8150 8150 8150dds 10920 27070 24080 9575300 ddms 5670 5730 5750 5750 57505 Con lusionsThe previous work [5 deals with the problem of implementing lazy narrowingwith multiset onstraints using the te hnique of translating into Prolog. More on retely, the authors proposed a naive strategy for translating programs rulesinto Prolog based on the idea of representing multisets as Prolog terms whi hkeep information about multiset ardinalitites. As ommented in [18 (but with-out multisets), the naive strategy performs redundant work be ause of revalua-tions of head normal forms. More eÆ ient strategies, su h as the demand driven[18, adapted to manage multiset uni ation, are not very appropriated be ause omputed head normal forms of multiset elements are, in general, lost. What wehave proposed here is a new strategy (ddsm) for lazy narrowing with multisetswhi h repairs some of the problems presented by the other strategies.On the other hand, we have extended the syntax of SETA in [5 to support ardinality onstraints and arithmeti onstraints. This repairs the problem in[5, where omputed answers ontain information about ardinalities not allowedin the syntax of the language. Due to the la k of spa e, we have fo used on thepresentation of ddsm, ommenting brie y on the rest of details.Finally, we have developed a omplete Prolog-based implementation for SETA,in orporating it into the system T OY [19,[4. Furthermore, we have also imple-mented the naive strategy [5 and the demand driven strategy [18 (modied tomanage multisets), proving that, in general, the behaviour of ddsm improves theother strategies.

Page 22: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Demand Driven Strategy for Lazy Narrowing with Multisets 15Referen es1. S. Antoy. Denitional Trees. Pro . ALP'92, Springer LNCS 632, pp. 143157, 1992.2. S. Antoy, R. E hahed, M. Hanus. A Needed Narrowing Strategy. Pro . POPL'94,ACM Press, pp. 268-279, 1994.3. S. Antoy, R. E hahed, M. Hanus. A Needed Narrowing Strategy. Journal of theACM, 47(4):776822, 2000.4. M. Abengozar-Carneros, P. Arenas-San hez et al. T OY: A Multiparadigm De lar-ative Language, vs. 2.0. TR SIP-106/00, 2000. http://titan.sip.u m.es/toy/5. P. Arenas-San hez, F.J. Lopez-Fraguas, M. Rodrguez-Artalejo. Embedding Multi-set Constraints into a Lazy Fun tional Logi Language. Pro . PLILP'98, SpringerLNCS 1490, pp. 429444, 1998.6. P. Arenas-San hez, F.J. Lopez-Fraguas, M. Rodrguez-Artalejo. Fun tional plusLogi Programming with Built-in and Symboli Constraints. Pro . PPDP99.Springer LNCS 1702, pp. 152169, 1999.7. P. Arenas-San hez, M. Rodrguez-Artalejo. A General Framework for Lazy Fun -tional Logi Programming with Algebrai Polymorphi Types. Theory and Pra ti eof Logi Programming, 1(2):185245, 2001.8. J.P. Banatre, D. Le Metayer. The Gamma Model and its Dis ipline of Program-ming. S ien e of Computer Programming, 15:5577, 1990.9. P.H. Cheong, L. Fribourg. Implementation of Narrowing: The Prolog-based Ap-proa h. In Apt, de Kakker, and Rutten, editors. Logi Programming Languages:Constraints, Fun tions and Obje ts. The MIT Press, pp. 120, 1993.10. A. Dovier, E. Omodeo, E. Ponelli, G. Rossi. fLogg:A Language for Programmingin Logi with Finite Sets. Journal of Logi Programming, 28(1):144, 1996.11. J.C. Gonzalez-Moreno, T. Hortala-Gonzalez, F.J. Lopez-Fraguas, M. Rodrguez-Artalejo. An Approa h to De larative Programming Based on a Rewriting Logi .Journal of Logi Programming, 40(1):4787, 1999.12. G. Groe, S. Holldobler, J. S hneeberger, U. Sigmund, M. Thiels her. EquationalLogi Programming, A tions, and Change. Pro . ICLP92, The MIT Press, pp. 177191, 1992.13. M. Hanus. The Integration of Fun tions into Logi Programming. A Survey. Jour-nal of Logi Programming, Spe ial issue Ten Years of Logi Programming, (19 &20):583628, 1994.14. J.P. Jouannaud, C. Kir hner. Solving Equations in Abstra t Algebras: A Rule-BasedSurvey of Uni ation. In J.L. Lassez and G. Plotking (eds), Computational Logi ,essays in Honor of Alan Robinson. The MIT Press, pp. 257321, 1991.15. B. Jayaraman, D.A. Plaisted. Programming with Equations, Subsets, and Relations.Pro . ICLP89, Vol. 2, the MIT Press, pp. 10511068, 1989.16. B. Legeard. Programmation en Logique ave Constraintes sur les Ensembles, Mul-tiensembles et Sequen es. Utilisation en Prototypage de Logi iels. PhD thesis, Uni-versite de Fran he-Comte, 1994.17. J.W. Lloyd. Programming in an Integrated Fun tional and Logi Language. Journalof Logi and Fun tional Programming, 1999(3), 1999.18. R. Loogen, F.J. Lopez-Fraguas, M. Rodrguez-Artalejo. A Demand Driven Com-putation Strategy for Lazy Narrowing. Pro PLILP'93, Springer LNCS 714, pp.184200, 1993.19. F.J. Lopez-Fraguas, J. San hez-Hernandez. T OY: A Multiparadigm De larativeSystem. Pro RTA'99, Springer LNCS 1631, pp. 244-247, 1999.20. N. Mart-Oliet, J. Meseguer. A tion and Change in Rewriting Logi . In Pares hi, R.and Fronhofer, B. (eds), Theoreti al Approa hes to Dynami Worlds in ComputerS ien e and Arti ial Intelligen e. Cambrigde M.P., 1995.21. Si stus Prolog User's Manual. Programming Systems Group. Swedish Institute ofComputer S ien e, 1995.

Page 23: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 24: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Computational properties of term rewriting withstrategy annotations?Salvador LucasDSIC, Universidad Politecnica de ValenciaCamino de Vera s/n, E-46022 Valencia, Spaine.mail: [email protected]. Strategy annotations have been used in several programminglanguages to improve termination and eciency of computations. Eager(rewriting-based) languages (e.g., Lisp, OBJ*, CafeOBJ, or Maude) inter-pret them as replacement restrictions in order to become `more lazy', thus(hopefully) avoiding nontermination. In this paper, we investigate somecomputational properties (termination and completeness) of programswhose execution is controlled by strategy annotations.Keywords: Declarative programming, replacement restrictions, termrewriting, termination.1 IntroductionA number of programming languages permit the explicit specication of strate-gies aimed at controlling the execution of the programs. For instance, strategyannotations have been used in the OBJ family of languages1 (OBJ2 [FGJM85],OBJ3 [GWMFJ00], CafeOBJ [FN97], or Maude [CELM96]) to introduce replace-ment restrictions aimed at improving eciency of computations (by reducingthe number of attempted matchings). Their usefulness has been demonstratedin practice: in [FGJM85] the authors remark that, due to their use in OBJ2 pro-grams, `the ratio between attempted matches and successful matches is usuallyaround 2=3, which is really impressive'. For instance, OBJs built-in conditionaloperator has the following (implicit) strategy annotation [GWMFJ00]op if_then_else : Bool Int Int -> Int [strat (1 0)]which says to evaluate the rst argument until it is reduced, and then applyrules at the top (indicated by `0'). Intuitively, this strategy annotation improveseciency, since reducing the second or third argument of if only makes senseafter knowing the value of the rst argument. The presence of such `true' re-placement restrictions (e.g., by forbidding replacements in the second and thirdarguments of if) is also invoked to justify that OBJ programs are able to avoidnontermination ([GWMFJ00], Section 2.4.4; [OF00]).? This work has been partially supported by Spanish CICYT and Conselleria de Cul-tura y Educacio de la Generalitat Valenciana.1 As in [GWMFJ00], by OBJ we mean OBJ2, OBJ3, CafeOBJ, or Maude.

Page 25: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

18 S. Lu asExample 1. The following OBJ3 program (borrowed from [OF97]):obj EXAMPLE issorts Sort .op 0 : -> Sort .op s : Sort -> Sort .op _::_ : Sort Sort -> Sort [strat: (1 0)] .op inf : Sort -> Sort .op nth : Sort Sort -> Sort .var X Y L : Sort .eq nth(s(X),Y::L) = nth(X,L) .eq nth(0,X::L) = X .eq inf(X) = X::inf(s(X)) .endospecies an explicit strategy annotation for the list constructor `::' which dis-ables replacements on the second argument. In this way, the evaluation of ex-pression nth(s(0),inf(0)) always nishes and produces the term s(0), evenif the `innite list' inf(0) is a part of the expression.Using restrictions of rewriting may give rise to incomplete computations, i.e.,normal forms of some terms could be unreachable by restricted computation.In order to avoid this, negative indices have been introduced aimed at enablingreductions on arguments `on-demand', where a `demand' is an attempt to matcha pattern to the term that occurs in such an argument position [OF00].Example 2. The following CafeOBJ program (borrowed from [NO01]):mod! TEST [T]op 0 : -> Top s : T -> T strat: (1)op _::_ : T T -> T strat: (1 -2)op 2nd : T -> T strat: (1 0)op from : T -> T strat: (0)vars X Y Z : Teq from(X) = X::from(s(X)) .eq 2nd(X::(Y::Z)) = Y .species negative indices in the strategy for ::. A local strategy such as (1)disables the evaluation of 2nd(0::from(s(0))) into s(0), since reducing thesecond argument of `::' is not allowed. On the other hand, with (1 2), thefollowing innite reduction sequence is possible:2nd(from(0)) ! 2nd(0::from(s(0))) ! 2nd(0::s(0)::from(s(s(0)))) ! Negative indices are aimed at keeping computations terminating, but providingmore opportunities for achieving completeness.

Page 26: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Computational properties of term rewriting with strategy annotations 19In this paper, we investigate termination and completeness of programs whoseexecution is controlled by strategy annotations. Following a recent classication([Vis01], Section 5.7), we consider the following kinds of computational strategiesassociated to strategy annotations:1. E-strategy [Eke98,GWMFJ00], which permits us to completely avoid theevaluation of some arguments of function symbols (in an ordered way).2. Just-in-time [Pol01], which is designed to delay the evaluation of argumentsas much as possible.3. On-demand E-strategy [OF00], which is similar to E-strategy, but enablesthe evaluation of subterms `on-demand'.4. Laziness annotations [FKW00], where the arguments of symbols can be an-notated as `lazy'. No reductions should be performed for subterms of thesearguments unless needed for matching.We use term rewriting systems (TRSs [BN98]) as a suitable computational modelfor programs written in more sophisticated programming languages. We showthat context-sensitive rewriting (CSR, a simple restriction of rewriting that for-bids reductions on selected arguments of functions [Luc98]) provides a suitableframework for describing and analyzing computations with programs using pos-itive strategy annotations (i.e., only non-negative integers are allowed) as usedin E-strategies and just-in-time. Due to lack of space, we discuss in detail onlythese two computational interpretations of strategy annotations. A preliminaryanalysis of completeness and termination of on-demand E-strategies and lazi-ness annotations (covering, e.g., termination and completeness of the programin Example 2) are given in [Luc01a,Luc01b].Section 2 gives some preliminary denitions. Section 3 introduces CSR. Sec-tions 4 and 5 discuss termination and completeness of computations under theE-strategy and just-in-time, respectively. Section 6 concludes.2 PreliminariesGiven a set A, P(A) denotes the set of all subsets ofA. Let R AA be a binaryrelation on a set A. We denote the re exive closure of R by R=, its transitiveclosure by R+, and its re exive and transitive closure by R. An element a 2 A isan R-normal form, if there exists no b such that a R b; NFR is the set of R-normalforms. We say that b is an R-normal form of a (and that a is R-normalizing), ifb is an R-normal form and a Rb. We say that R is terminating i there is noinnite sequence a1 R a2 R a3 . Throughout the paper, X denotes a countableset of variables and denotes a set of function symbols ff; g; : : :g, each having axed arity given by a function ar : ! N.We denote the set of terms built from and X by T (;X ). A context C[ ] is a term from T ( [ f2g;X ), where 2 is anew constant symbol. A term is said to be linear if it has no multiple occurrencesof a single variable. Terms are viewed as labelled trees in the usual way. Positionsp; q; : : : are represented by chains of positive natural numbers used to addresssubterms of t. By , we denote the empty chain. Given positions p; q, we denote

Page 27: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

20 S. Lu asits concatenation by p:q. Positions are ordered by the usual prex ordering .Given a set of positions P , minimal(P ) (maximal(P )) is the set of minimal(resp. maximal) positions of P w.r.t. . If p is a position, and Q is a set ofpositions, p:Q is the set fp:q j q 2 Qg. By Pos(t) we denote the set of positionsof a term t. Positions of non-variable symbols in t are denoted as Pos(t) andPosX (t) are the variable occurrences. The subterm at position p of t is denotedas tjp and t[s]p is the term t with the subterm at position p replaced by s. IfP = fp1; : : : ; png is a set of disjoint positions (i.e., incomparable according to), then we write t[s]P instead of t[s]p1 [s]pn . The symbol labelling the rootof t is denoted as root(t). A substitution is a mapping : X ! T (;X ) whichhomomorphically extends to a mapping : T (;X )! T (;X ).A rewrite rule is an ordered pair (l; r), written l ! r, with l; r 2 T (;X ),l 62 X and Var(r) Var(l). The left-hand side (lhs) of the rule is l and the right-hand side (rhs) is r. A TRS is a pair R = (;R) where R is a set of rewriterules. L(R) denotes the set of lhs's of R. R is left-linear if L(R) is a set of linearterms. An instance (l) of a lhs l 2 L(R) is a redex. The set of redex positionsin t is PosR(t). A term t 2 T (;X ) rewrites to s (at position p), written t p!R s(or just t ! s), if tjp = (l) and s = t[(r)]p, for some l ! r 2 R, p 2 Pos(t)and substitution . A term is a normal form if it is a !-normal form. Let NFRbe the set of normal forms of R. A term t is a head-normal form if it cannot berewritten to a redex. A TRS is terminating if ! is terminating. We say that tinnermost rewrites to s, written t !i s, if t p! s and p 2 maximal(PosR(t)).A TRS is innermost terminating if !i is terminating.3 Rewriting with syntactic replacement restrictionsGiven a signature , a mapping : ! P(N) is a replacement map (or -map) if for all f 2 ; (f) f1; : : : ; ar(f)g [Luc98]. The inclusion ordering on P(N) extends to an ordering v on M , the set of all -maps: v 0 if for allf 2 , (f) 0(f). Thus, v 0 means that considers less positions than0 (for reduction). We also say that is more restrictive than 0.A replacement map species the argument positions which can be reducedfor each symbol in . Accordingly, the set of -replacing positions Pos(t) of t 2T (;X ) is: Pos(t) = fg, if t 2 X and Pos(t) = fg[Si2(root(t)) i:Pos(tji),if t 62 X . The set of positions of replacing redexes in t is PosR(t) = PosR(t) \Pos(t). In context-sensitive rewriting (CSR), we (only) rewrite redexes at re-placing positions: t -rewrites to s, written t ,! s, if t p!R s and p 2 Pos(t).Example 3. Consider the TRS [NO01]:2nd(x:y:z) ! yfrom(x) ! x:from(s(x))and (:) = (2nd) = (from) = (s) = f1g. Then we have:2nd(from(0)) ,! 2nd(0:from(s(0)))where, since 1:2 62 Pos(2nd(0:from(s(0)))), -rewritting stops here.

Page 28: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Computational properties of term rewriting with strategy annotations 21The ,!-normal forms are called -normal forms. Let NFR be the set of -normal forms of R. A term is -normalizing if it is ,!-normalizing. A TRSR is -terminating if ,! is terminating (see [Luc96]). With innermost context-sensitive rewriting#, we only contractmaximal positions (w.r.t.) of replacingredexes: t # s if t p!R s and p 2 maximal(PosR(t)). We say that R isinnermost -terminating if # is terminating.A (non-deterministic) rewriting strategy for a TRS R is a function S thatassigns a non-empty set of non-empty nite rewrite sequences each beginningwith t to every term t which is not a normal form. A (non-deterministic) context-sensitive rewriting strategy (or just -strategy) for R is a function H that assignsa non-empty set of non-empty nite -rewrite sequences each beginning with tto every term t which is not a -normal form [Luc00]. We write t ,!H s ifH(t) contains a -reduction sequence ending with s. Given a -strategy H, a-reduction sequence of the form t1 ,!H t2 ,!H is called a H-sequence. AnH-sequence t1 ,!H t2 ,!H ,!H tn is maximal if tn is a -normal form. The-strategy H is -normalizing if, for all -normalizing term t, there is no inniteH-sequence starting from t.The maximal replacing context MRC(t) of t consists of the maximal part oft whose positions are -replacing in t, see [Luc00]. Every one-step -strategy Hcan be extended to a one-step strategy SH as follows:SH(t) = 8>><>>:H(t) if t 62 NFRC[SH(t1); : : : ; SH(tn)] if t 2 NFR NFR, whereC[ ] = MRC(t) and t = C[t1; : : : ; tn]? otherwiseHere, for a given context C[ ] and sets of rewrite sequences S1; : : : ; Sn, issuedform terms t1; : : : ; tn, C[S1; : : : ; Sn] is the set of sequences C[t1; : : : ; tn] !+C[s1; : : : ; sn], where either si = ti (during the whole sequence) or si is the endpoint of a sequence in Si (also, at least one of the si must be taken in this way).4 E-strategyA positive local strategy (or E-strategy) for a k-ary symbol f 2 is a sequence'(f) of integers taken from f0; 1; : : : ; kg which are given in parentheses (seeExample 1). A mapping ' that associates a local strategy '(f) to every f 2 is called an E-strategy map [NO01]. Nagaya describes the operational semanticsof term rewriting under E-strategy maps as follows [Nag99]: Let L be the setof all lists consisting of natural numbers. By Ln, we denote the set of all listsof natural numbers not exceding n 2 N. We use the signature L = ffL j f 2 ^L 2 Lar(f)g and labelled variables XL = fxnil j x 2 Xg. An E-strategy map' for is extended to a mapping from T (;X ) to T (L;XL) as follows:'(t) = xnil if t = x 2 Xf'(f)('(t1); : : : ; '(tk)) if t = f(t1; : : : ; tk)

Page 29: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

22 S. Lu asThe mapping erase : T (L;XL) ! T (;X ) removes labellings from symbols inthe obvious way. The binary relation !' on T (L;XL) N+ (i.e., pairs ht; piof labelled terms t and positions p) is [NO01,Nag99]: ht; pi !' hs; qi if and onlyif p 2 Pos(t) and either1. root(tjp) = fnil, s = t and p = q:i for some i; or2. tjp = fi:L(t1; : : : ; tk) with i > 0, s = t[fL(t1; : : : ; tk)]p and q = p:i; or3. tjp = f0:L(t1; : : : ; tk), erase(tjp) is not a redex, s = t[fL(t1; : : : ; tk)]p, q = p;or4. tjp = f0:L(t1; : : : ; tk) = (l0), erase(l0) = l, s = t[('(r))]p for some l ! r 2R and substitution , q = p.We write e 2 L to denote that item e appears somewhere within the list L.Given a E-strategy map ' for , we dene ' 2 M as follows: for all f 2 ,'(f) = fi > 0 j i 2 '(f)g. We will drop superscript ' if no confusion arises.We have the following.Theorem 1. [Luc01b] Let R be a TRS and ' be a positive E-strategy map. Lett 2 T (L;XL), and p 2 Pos(erase(t)) be s.t. root(tjp) = fL for some sux Lof '(f). If ht; pi !' hs; qi, then q 2 Pos(erase(s)) and erase(t) ,!= erase(s).Algebraic languages OBJ2, OBJ3, CafeOBJ, and Maude admit the specicationof E-strategies. Symbols without an explicit local strategy are given a defaultone whose concrete shape depends on the language2 considered. Semantics ofOBJ programs under a given E-evaluation map ' is usually given by meansof a recursive evaluation function eval' (from terms to their sets of `computedvalues') rather than specifying the concrete rewrite steps leading to computedvalues [Eke98]. Nakamura and Ogata describe the evaluation strategy eval' forpositive E-strategy maps by using the reduction relation !' [NO01]: given aTRS R = (;R) and a positive E-strategy map ' for , eval' : T (;X ) !P(T (;X )) is dened as eval'(t) = ferase(s) 2 T (;X ) j h'(t);i !' hs;i 2NF!'g.Example 4. Consider the following TRS R [Eke98]:f(b) ! c h(c) ! g(f(a))g(x) ! h(x) a ! band the E-strategy map ' given by '(f) = (0 1), '(g) = '(h) = (1 0), '(a) =(0), and '(b) = nil. Consider the evaluation of t = g(f(a)) (more precisely, theevaluation of '(t) = g(1 0)(f(0 1)(a(0)))) using !' (we underline contractedredexes in the `term' component of pairs):hg(1 0)(f(0 1)(a(0))); i !' hg(0)(f(0 1)(a(0))); 1i!' hg(0)(f(1)(a(0))); 1i !' hg(0)(fnil(a(0)));1:1i!' hg(0)(fnil(bnil)); 1:1i !' hg(0)(fnil(bnil));1i!' hg(0)(fnil(bnil)); i !' hh(1 0)(fnil(bnil));i2 For instance, in Maude, the default local strategy associated to a k-ary symbol f , is(1; 2; : : : ; k; 0), see [Eke98].

Page 30: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Computational properties of term rewriting with strategy annotations 23!' hh(0)(fnil(bnil)); 1i !' hh(0)(fnil(bnil)); i!' hhnil(fnil(bnil));iwhere hhnil(fnil(bnil)));i is a !'-normal form. Then, h(f(b)) 2 eval'(t).4.1 TerminationGiven an OBJ program P with positive E-strategy map ', we let RP and be the TRS and replacement map associated to it. According to the previousdenition of eval', we can say thatP (or RP) is ('-)terminating if, for all t 2 T (;X ), there is no innite!'-rewrite sequence starting from h'(t);i.Thus, according to Theorem 1, we have the following.Theorem 2. [Luc01b] An OBJ program P with positive E-strategy map ' isterminating if RP is -terminating.Theorem 2 connects termination of CSR and termination of OBJ programswith positive evaluation strategies. Termination of CSR has been studied in[GM99,Luc96,Zan97]. For instance, the OBJ program in Example 1 can be proventerminating by using Zantema's techniques (see Examples 2 and 3 of [Zan97]).However, termination of CSR only approximates termination of such OBJ pro-grams.Example 5. Consider the TRS [Gra96]:f(a) ! f(a)a ! band a local strategy ' such that '(f) = (1 0) and '(a) = (0). This TRS is'-terminating, but it is not -terminating, since we have:f(a) ,! f(a) ,! The point here is that OBJ computations are `basically' innermost. Innermostrewriting computations can be terminating even though the TRS is not termi-nating. This gives rise to the topic of innermost termination of rewriting whichhas been studied in e.g., [AG97,Gra96].Given R = (;R), we consider as the disjoint union = C]F of symbolsc 2 C, called constructors and symbols f 2 F , called dened functions, whereF = froot(l) j l ! r 2 Rg and C = F . We say that an E-strategy map ' iselementary if for all f 2 F , '(f) = (i1 in 0) and ij > 0 for 1 j n.Remark 1. Contiguous occurrences of zero can be simplied into a single one(Corollary 3.3 in [Eke98]). Since [Eke98,Nag99] largely motivate the interest inrequiring that 0 be the last index of local strategies associated to dened symbols,the only critical requirement which is introduced with elementary strategies isthat 0 occur only at the end of the local strategy.

Page 31: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

24 S. Lu asComputations with elementary strategies can be modeled using innermost CSR.Theorem 3. Let R = (C ] F ; R) be a TRS and ' be a positive elementaryE-strategy map. Let t 2 T (;X ). If h'(t);i !' hs; pi, then t# erase(s).Without requiring elementarity of ', Theorem 3 does not hold.Example 6. Consider R, ', and t as in Example 4. According to Theorem 1, the-rewriting steps associated to the evaluation of t are:g(f(a)) # g(f(b)) ,! h(f(b))Due to redex f(b), the second -rewriting step is not innermost,Theorem 4. An OBJ program P with positive elementary E-strategy map ' isterminating if RP is innermost -terminating.For nonelementary E-strategies, Theorem 5 can fail to hold.Example 7. Consider the TRS R of Example 5 and ' given by '(f) = (0 1 0),'(a) = (0), and '(b) = nil. Note that R is innermost -terminating. However,R is not '-terminating, since we have:hf(0 1 0)(a(0));i !' hf(0 1 0)(a(0));i !' Since -termination implies innermost -termination (but not vice versa), an-alyzing innermost termination of CSR provides a more accurate framework forproving termination of OBJ programs with positive, elementary E-strategies.Theorem 5. Let P be an OBJ program with positive elementary E-strategy map'. If P is terminating, then RP is innermost -terminating.Without elementarity, '-termination may not imply innermost -termination.Example 8. Consider R and ' as in Example 4. Note that R is not innermost-terminating, since we have:h(c) # g(f(a)) # g(f(b)) # g(c) # h(c) # However, R is '-terminating, since, as shown in Example 4, whenever (the la-belled version of) the term g(f(a)) is reached, the derivation stops in h(f(b))without producing h(c) which is needed to generate the cycle.Related work In [FGK01], an inductive method is proposed to prove (ground)termination of rewriting with positive E-strategies. We have checked that thetwo examples used in [FGK01] to illustrate their technique can be easily proventerminating by using Zantema's transformation [Zan97] and an automatic toolsuch as Contejean and Marche's CiME 2.0 system3. Moreover, we note that onlyTheorem 2 is necessary to deal with these examples. On the other hand, in orderto be able to use their methods, it is necessary to use a dierent technique to3 Available at http://www.lri.fr/~demons/cime.html.

Page 32: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Computational properties of term rewriting with strategy annotations 25ensure that the constant symbols are terminating (w.r.t. computations guidedby the strategies). This is easy if there is no rewrite rule c! r associated to anyconstant symbol c. Note that '-termination of (a TRS containing) the TRS R,a ! f(a)with '(f) = nil, could not be proven in this way. However, '-termination ofR is easily proved by using the -contractive transformation of [Luc96] (thatessentially removes the non--replacing subterms from left and right-hand sidesof rules), since the transformed TRS:a ! fis clearly terminating.4.2 CompletenessComputations with programs that use replacement restrictions may not directlycompute normal forms (i.e., terms without redexes), but rather normal formsw.r.t. the reduction relation that is used for implementing computations (e.g.,!'). This is the case with OBJ programs, where terms returned by eval' arecalled E-normal forms (ENF s). We have the following.Theorem 6. [Luc01b] Let R = (C ] F ; R) be a TRS and ' be a positive E-strategy map such that for all f 2 F , '(f) ends in 0. If s 2 eval'(t), then s isa -normal form.Correctness of OBJ computations (i.e., if s 2 eval'(t), then s 2 NFR) has beenstudied in [Nag99] (Theorem 6.1.12) and [NO01] (Theorem 3.2 and Corollary3.8). Here we consider completeness (regarding normalizations), i.e., if thereexists s 2 NFR such that t! s, we want that s 2 eval'(t).Normal forms of a term t can be obtained by successively computing its -normal forms s, splitting s as s = C[s1; : : : ; sn] where C[ ] = MRC(s) and con-tinuing the evaluation of t by (recursively) normalizing s1; : : : ; sn (normalizationvia -normalization [Luc00]). This works for replacement maps which are lessrestrictive than the canonical replacement map canR . Given a TRS R = (;R),canR is the most restrictive replacement map (in M) ensuring that the non-variable subterms of the left-hand sides of the rules of R are replacing, i.e., theminimum-map such that 8l 2 L(R);Pos(l) Pos(l) [Luc98,Luc00].Theorem 7 (Normalization via -normalization [Luc00]). Let R = (;R)be a left-linear, con uent TRS and 2 M be such that canR v . If H is a-normalizing -strategy, then SH is normalizing.IfR is '-terminating and ENF s are -normal forms, then, according to Theorem1, eval' could be seen as the -strategy that associates to each term t the setof all possible -rewrite sequences obtained by applying erase to terms in !'-sequences issued from '(t). Then, we have the following.Theorem 8 (Normalization via '-normalization). Let R = (;R) be aleft-linear, con uent TRS and ' be an E-strategy map such that for all f 2 F ,'(f) ends in 0 and canR v . If R is '-terminating, then Seval' is normalizing.

Page 33: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

26 S. Lu asRelated work With regard to the computation of normal forms by directly us-ing the E-strategy, Nagaya provides conditions (on the TRS and the E-strategy') ensuring that ' is normalizing, i.e., it is able to compute a normal form ofa term whenever it exists (i.e., he studies completeness of the E-strategy w.r.t.normalization). However, these results concern quite a restricted subclass of or-thogonal TRSs. Complementarily, Theorem 8 establishes that completeness ispossible for left-linear, con uent and '-terminating TRSs. However, we need a`meta-operation' (namely, Seval') that uses eval' to obtain partially evaluatedresults (i.e., E-normal forms) in order to obtain normal forms.5 Just-in-timeLetR = (;R) be a TRS. According to van de Pol [Pol01], a strategy annotationassociated to a given symbol f 2 is a list &(f) whose elements can be either1. a number i with 1 i ar(f); or2. a rule l ! r 2 R such that root(t) = f .In principle, strategy annotations contain no duplicated items.Example 9. Consider the TRS [Pol01]: : if(true,x,y) ! x : if(b,x,x) ! x : if(false,x,y) ! yThen, a possible strategy annotation for if is &(if) = [1,,,2,3, ].We say that & is r-full if for all l! r 2 R, l ! r 2 &(root(l)).Given a strategy annotation, van de Pol describes the rewriting strategy thatit species. A strategy is seen as a function that, given a term t, yields eithersome rewrite of t, i.e., a pair (p; s) such that t p! s, or ? if no rewrite step hasbeen selected. Given a term t and a strategy annotation &, rewr& indicates the(unique, if any) rewrite step that can be issued on t.Denition 1. [Pol01] Let R = (;R) be a TRS, & be a strategy annotation,and t 2 T (;X ). Then, rewr&(t) = rewr&(t; &(root(t))), whererewr&(t; nil) = ?rewr&(t; (l! r : L)) = (; (r)) if t = (l) for some rewr&(t; L) otherwiserewr&(t; (i : L)) = (i:p; t[s]i) if rewr&(tji) = (p; s) for some p; srewr&(t; L) otherwiseWe write t p!& s (or just t !& s) if (p; s) = rewr&(t) 6= ?. Thus, t is a !&-normal form (or just a &-normal form) if and only if rewr&(t) = ?. Given astrategy annotation & for , we dene & 2 M as follows: for all f 2 ,&(f) = fi 2 N j i 2 &(f)g. We will drop superscript & if no confusion arises. Thefollowing theorem establishes a very close connection between !& and ,!.

Page 34: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Computational properties of term rewriting with strategy annotations 27Theorem 9. Let R be a TRS, & be a strategy annotation, and t; s 2 T (;X ).If t !& s, then t ,! s.According to the denition of !&, given terms t; s, and s0, it follows that t !& sand t !& s0 imply that s = s0, i.e., each !&-reduction step is deterministic.5.1 TerminationGiven a term t and a strategy annotation, van de Pol denes the reductionsequence associated to t by concatenating !&-steps (see Section 2.3 of [Pol01]).Thus, we say that a TRS is &-terminating if !& is terminating. According toTheorem 9, we have the following immediate consequence.Theorem 10. Let R be a TRS and & be a strategy annotation. If R is -terminating, then it is &-terminating.Terminationof!& can be more accurately characterized as innermost -termination.Conditions for doing this are similar to those given in Section 4.1 for E-strategies.5.2 CompletenessAccording to Theorem 9, -normal forms are always &-normal forms. We alsohave the following.Theorem 11. Let R be a TRS, & be an r-full strategy annotation, and t 2T (;X ). If t is a &-normal form, then t is a -normal form.Therefore, for r-full strategy annotations, &-normal forms and -normal formscoincide. In this case, !& can be thought of as the reduction relation ,!H&associated to a (one-step, deterministic) context-sensitive rewriting strategy H&given by H&(t) = ft!& sg.The main concern of [Pol01] is to achieve normalization using !&. The au-thor introduces the notion of full (and in-time) strategy annotation. A strategyannotation & is full if it is r-full and for all f 2 and i 2 f1; : : : ; ar(f)g, i 2 &(f).A strategy annotation & is in-time if for all f 2 , : l ! r 2 R such thatroot(l) = f , and i 2 f1; : : : ; ar(f)g, whenever &(f) = L1L2iL3, then i is notneeded for . Here, index i is needed for a rule : l ! r if lji 62 X or lji 2 Xoccurs in ljj for i 6= j. For example, the strategy of Example 9 is full and in-time4. There is a trivial connection between needed indices and the canonicalreplacement map canR .Proposition 1. Let R = (;R) be a left-linear TRS and : l ! r 2 R. Ifi 2 f1; : : : ; ar(root(l))g is needed for , then i 2 canR (root(l)).4 The name just-in-time that entitles this section (and van de Pol's paper) correspondsto the full and in-time strategy that can be automatically associated to a given TRS(see Section 4 of [Pol01]). The just-in-time strategy is aimed at delaying (as much aspossible) the evaluation of arguments of function symbols. For instance, strategy & inExample 9 is the just-in-time strategy that corresponds to the TRS in the example.

Page 35: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

28 S. Lu asHowever, there can be indices in canR (f) that are not needed for any rule l ! rsuch that root(l) = f .Example 10. Consider the TRS R (based on [Pol01]): : f(x,a) ! f(b,c) : b ! c : g(f(c,c)) ! cIndex 1 is not needed for (which is the only rule associated to f). However,1 2 canR (f).Van de Pol also provides the following normalization (partial) function:Denition 2. [Pol01] Let R = (;R) be a TRS, & be a strategy annotation,and t 2 T (;X ). Then, norm&(t) = norm&(t; &(root(t))), wherenorm&(t; nil) = tnorm& (t; (l! r : L)) = norm&((r)) if t = (l) for some norm&(t; L) otherwisenorm&(t; (i : L)) = norm&(t[norm&(tji)]i; L)Then, he proves the following theorems.Theorem 12. [Pol01] If & is in-time, then norm& (t) is the last element of themaximal !&-reduction sequence starting from t.Theorem 13 (Correctness [Pol01]). Let & be full and in-time. If s 2 norm& (t),then s is a normal form.Unfortunately, no analysis of completeness is given for5 norm& . According toTheorem 10 and Theorem 12, -termination of R implies that norm& is denedon all terms, i.e., it is actually a mapping. On the other hand, if & is full (asrequired in Theorem 13), -termination and termination coincide. Thus, no clear(or easily provable) benet is obtained (regarding termination) from restrictingcomputations. We can improve this situation as follows.Theorem 14. Let R = (;R) be a TRS and & be r-full and in-time. If s 2norm&(t), then s is a -normal form.5 In page 40 of [Pol01], van de Pol calls `a strategy annotation (&) complete if norm& ispartially correct', i.e., `if norm& (t) = s, then s is a normal form of t'. We think thatthis terminology is misleading, since it does not correspond to the standard notionof completeness. This can eventually confuse the reader when the author claims that`full and in-time are sucient syntactic criteria for completeness'.Moreover, in page41, the author refers to completeness of E-strategy annotations which `is proved inTheorem 6.1.12 of [Nag99] for full annotations ending in 0'. However, as remarkedabove, this result concerns correctness; completeness (or normalizability in Nagaya'sterminology) is studied elsewhere in [Nag99], e.g., Theorems 6.2.8 and 6.3.8. On theother hand, Nakamura and Ogata do not study completeness in [NO01].

Page 36: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Computational properties of term rewriting with strategy annotations 29Now, if R can be proved &-terminating (e.g., by using Theorem 10), we canuse norm& (or H&) as a -normalizing -strategy (where norm& (t) is the sin-gleton containing the unique nite !& sequence starting from t and endingin a -normal form of t) which can be used within the normalization via -normalization process described in Section 4.2.Theorem 15 (Normalization via &-normalization). Let R = (;R) be aleft-linear, con uent TRS and & be an r-full and in-time strategy annotation suchthat canR v . If R is -terminating, then Snorm& (and SH& ) is normalizing.Unfortunately, r-full and in-time alone (i.e., without requiring canR v ) do notensure correctness of the procedure.Example 11. Consider the TRS R of Example 10 and the r-full and in-timestrategy annotation & given by &(f) = [2,], &(g) = [1,], &(b) = [ ]. Hence,(f) = f2g, (g) = f1g, and (b) = ?. Then we have,norm& (g(f(b,b))) = g(f(b,c))which is not a normal form (but it is a -normal form).Now, by the normalizationvia &-normalization process, and since the only non--replacing position of s =g(f(b,c)) is 1:1, we recursively normalize sj1:1 = b and obtain s[norm&(b)]1:1 =g(f(c,c)) which is not a normal form. Note that canR 6v .The reason for this `bad' behavior of r-full and in-time strategy annotations isthat `in-time' does not ensure that computations under (not full, but possiblyr-full) strategy annotations nally obtain head-normal forms.Example 12. (continuing Example 10) Term g(f(b,c)) obtained as the evalua-tion of g(f(b,b)) is not a head-normal form, since we haveg(f(b,c)) ! g(f(c,c))and g(f(c,c)) is a redex.However, we have the following.Theorem 16. [Luc98] Let R = (;R) be a left-linear TRS and 2 M besuch that canR v . Every -normal form is a head-normal form.And hence, according to Theorems 14 and 16, we have:Corollary 1. Let R = (;R) be a left-linear TRS, & be r-full and in-time suchthat canR v . If s 2 norm&(t), then s is a head-normal form.We note that left-linearity cannot be dismissed in this result.Example 13. Consider the following TRS R [Luc01b]: : f(x,x) ! c(x) : a ! bwhich is not left-linear, and let & be &(f) = [1,2,], &(a) = [], and &(b) =&(c) = []. Note that & is r-full and in-time. Term t = f(c(a),c(b)) is notroot-stable:f(c(a),c(b)) ! f(c(b),c(b))and f(c(b),c(b)) is a redex. However, norm& (t) = t.

Page 37: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

30 S. Lu asRelated work We think it fair to point out that `in-time' alone (i.e., withoutfullness, or even with r-fullness) does not provide better results than obtained us-ingE-strategies (concerning the ability of computing head-normal forms [NO01]).This complements van de Pol's claim in the introduction of [Pol01] (see page 41):`we generalize the mentioned results (by Nakamura and Ogata) by having a moreliberal criteria on a larger class of TRSs', since Nakamura and Ogata's analysisalso concerns strategy annotations which are not full. Moreover, Nagaya's resulton correctness of E-strategies (Theorem 6.1.12 of [Nag99]) is also valid for ar-bitrary TRSs. However, Nagaya requires that strategy annotations end in 0, atleast for dened symbols; this is not necessary in van de Pol's approach.6 Conclusions and future workWe have shown that the theory of CSR is useful for analyzing computations withstrategy annotations. The analysis of (innermost) termination of CSR providesa characterization (which can even be complete) of termination of OBJ programswith positive local strategies.Nakamura and Ogata prove that E-strategies '0 which compute head-normalforms (i.e., such that if s 2 eval'0 (t), then s is a head-normal form of t) can becompleted to E-strategies ' which compute normal forms (i.e., such that if s 2eval'(t), then s is a normal form of t, see Theorem 3.2 in [NO01]). Therefore, thisis a result which ensures correctness of eval' if constructed from an appropriate'0. We conjecture that '0-termination of such E-strategies ensures completenessof ', even without any `meta-operation' (e.g., Seval'0 ). In this way, proofs oftermination of CSR would be useful for ensuring completeness (or normalization)of full E-strategies (and also full and in-time strategy annotation). A similarstatement would hold for just-in-time style. We plan to address these problemsin future work.References[AG97] T. Arts and J. Giesl. Proving Innermost Normalisation Automatically. InProc. of RTA'97, LNCS 1232:157-171, Springer-Verlag, Berlin, 1997.[BN98] F. Baader and T. Nipkow. Term Rewriting and All That. CambridgeUniversity Press, 1998.[CELM96] M. Clavel, S. Eker, P. Lincoln, and J. Meseguer. Principles of Maude.Electronic Notes in Theoretical Computer Science, volume 4, 25 pages,1996.[Der87] N. Dershowitz. Termination of rewriting. Journal of Symbolic Computa-tion, 3:69-115, 1987.[Eke98] S. Eker. Term Rewriting with Operator Evaluation Strategies. ElectronicNotes in Theoretical Computer Science, volume 15, 20 pages, 1998.[FGJM85] K. Futatsugi, J. Goguen, J.-P. Jouannaud, and J. Meseguer. Principlesof OBJ2. In Proc. of POPL'85, pages 52-66, ACM Press, 1985.[FGK01] O. Fissore, I. Gnaedig, and H. Kirchner. Termination of rewriting withlocal strategies. In Proc. of STRATEGIES'01, pages 35-54, 2001.

Page 38: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Computational properties of term rewriting with strategy annotations 31[FKW00] W. Fokkink, J. Kamperman and P. Walters. Lazy Rewriting and EagerMachinery. ACM Transactions on Programming Languages and Systems,22(1):45-86, 2000.[FN97] K. Futatsugi and A. Nakagawa. An Overview of CAFE Specication Envi-ronment An algebraic approach for creating, verifying, and maintainingformal specication over networks . In Proc. of 1st International Con-ference on Formal Engineering Methods, 1997.[GL01] B. Gramlich and S. Lucas (editors). 1st International Workshop on Re-duction Strategies in Rewriting and Programming, WRS'01. Proceedings,volume 2359, Servicio de Publicaciones de la Universidad Politecnica deValencia, 2001.[GM99] J. Giesl and A. Middeldorp. Transforming Context-Sensitive Rewrite Sys-tems. In Proc. of RTA'99, LNCS 1631:271-285, Springer-Verlag, Berlin,1999.[Gra96] B. Gramlich. On Proving Termination by Innermost Termination. InProc. of RTA'96, LNCS 1103:97-107, Springer-Verlag, Berlin, 1996.[GWMFJ00] J.A. Goguen, T. Winkler, J. Meseguer, K. Futatsugi, and J.-P. Jouan-naud. Introducing OBJ. In J. Goguen and G. Malcolm, editors, SoftwareEngineering with OBJ: algebraic specication in action, Kluwer, 2000.[Luc96] S. Lucas. Termination of context-sensitive rewriting by rewriting. In Proc.of ICALP'96, LNCS 1099:122-133, Springer-Verlag, Berlin, 1996.[Luc98] S. Lucas. Context-sensitive computations in functional and functionallogic programs. Journal of Functional and Logic Programming, 1998(1):1-61, January 1998.[Luc00] S. Lucas. Context-sensitive rewriting strategies. TR DSIC-II/7/00, 2000.Available: http://www.dsic.upv.es/users/elp/slucas/papers.html[Luc01a] S. Lucas. Context-Sensitive Rewriting, Lazy Rewriting, and On-demandRewriting. In Proc. of WFLP'01, pages 197-210, Technical Report 2017,Christian-Albrechts-Universitat zu Kiel, 2001.[Luc01b] S. Lucas. Termination of on-demand rewriting and termination of OBJprograms. In Proc. of PPDP'01, pages 82-93, ACM Press, 2001.[Nag99] T. Nagaya. Reduction Strategies for Term Rewriting Systems. PhD The-sis, School of Information Science, Japan Advanced Institute of Scienceand Technology, March 1999.[NO01] M. Nakamura and K. Ogata. The evaluation strategy for head normalform with and without on-demand ags. Electronic Notes in TheoreticalComputer Science, volume 36, 17 pages, 2001.[OF97] K. Ogata and K. Futatsugi. Implementation of Term Rewritings with theEvaluation Strategy. In Proc of PLILP'97, LNCS 1292:225-239, Springer-Verlag, Berlin, 1997.[OF00] K. Ogata and K. Futatsugi. Operational Semantics of Rewriting with theOn-demand Evaluation Strategy. In Proc of SAC'00, pages 756-763, ACMPress, 2000.[Pol01] J. van de Pol. Just-in-time: on Strategy Annotations. In [GL01], pages39-58.[Vis01] E. Visser. A Survey of Strategies in Program Transformation Systems. In[GL01], pages 97-128.[Zan97] H. Zantema. Termination of Context-Sensitive Rewriting. In Proc. ofRTA'97, LNCS 1232:172-186, Springer-Verlag, Berlin, 1997.

Page 39: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 40: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Proof of Correctness for the STG Machine?Alberto de la Encina and Ricardo Pe~naDepartamento de Sistemas Informaticos y ProgramacionUniversidad Complutense de Madrid, Spaine-mail: falbertoe,[email protected]. J. Launchbury gave an operational semantics for lazy evalu-ation and showed that it was correct and complete w.r.t. a denotationalsemantics of the language. P. Sestoft then introduced several abstractmachines for lazy evaluation and showed that they were correct andcomplete w.r.t. Launchbury's operational semantics. We go a step for-ward and show that the Spineless Tagless G-machine is complete and(almost) correct w.r.t. one of Sestoft's machines. In the way to this goalwe also prove some interesting properties about the operational seman-tics and about Sestoft's machines which clarify some minor points ongarbage collection and on closures' local environments. Unboxed valuesand primitive operators are excluded from the study.1 IntroductionOne of the most successful abstract machines for executing lazy functional lan-guages is the Spineless Tagless G-machine (STG machine) [5] which is at theheart of the Glasgow Haskell Compiler (GHC) [6]. The compiler receives a pro-gram written in Haskell [7] and, after some steps and intermediate transforma-tions, produces a program in a very simple functional language called the STGlanguage. This is the input for the STG machine. The back-end then generatesimperative code emulating the transitions of the machine.The STG machine has proved to be ecient compared with some other ma-chines for lazy languages such as the G-machine [2] or the TIM (Three Instruc-tions Machine) [1]. But until recently there has been no formal proof of its cor-rectness. This was provided for the rst time by J. Mountjoy in [4]. There, theauthor starts from Launchbury's natural semantics for lazy evaluation [3] andtransforms it to successive more elaborated semantics. From these semantics hederives a STG-like machine and proves its correctness w.r.t. the semantics. Themachine has a single stack (instead of three) and does not treat constructions asnormal forms. Additionally, he proves that the more elaborated semantics are infact equivalent to Launchbury's.Launchbury's semantics is a good starting point because it has been acceptedde facto as the reference for dening the meaning of lazy evaluation. It is howeverdebatable whether the right approach to proving the correctness of a machine isto rene the specication so that it gets closer and closer to the desired opera-tional behaviour.? Work partially supported by the Spanish-British Accion Integrada HB 1999-0102and Spanish project TIC 2000-0738.

Page 41: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

34 A. de la En ina, R. Pe~naIn order to prove the correctness of the STG machine, we have followed adierent strategy. We accept Launchbury's semantics as the specication andwe continue with the abstract machines developed by Sestoft in [9] which wereshown to be correct and complete w.r.t. Launchbury's semantics. In order tohave a common language, we dene a language similar to that of STG whichcan be considered a subset of the language used by Sestoft's machines. Then,we dene and prove a bisimulation between the Sestoft machine called Mark-2and the STG. The bisimulation holds for a single-stack STG machine. The onedescribed in [5] and implemented in the rst versions of the GHC compiler hadthree separate stacks. We show that the three stack machine is not correct w.r.t.to the semantics for some ill-typed programs.Other contributions are: improvements to Sestoft's semantics in order to solvea small problem related to freshness of variables and to take into account garbagecollection. Also, a property about Sestoft's machines environments is proved.The plan of the paper is as follows: After this introduction, in Section 2Launchbury's semantics is summarized. Then, Sestoft's and our improvementsare presented. Section 3 introduces Sestoft's Mark-2 machine and presents ourproposition about its environments. Section 4 denes the STG-like language, thesingle-stack STG machine and proves the bisimulation with the Mark-2 machine.Section 5 shows that the three-stack STG machine is complete but not correctw.r.t. the semantics. Finally, Section 6 draws some conclusions.12 Natural Semantics2.1 Launchbury's original proposalA well-known work from Launchbury [3] denes a big-step operational seman-tics for lazy evaluation. The only machinery needed is an explicit heap wherebindings are kept. A heap is considered to be a nite mapping from variables toexpressions, i.e. duplicated bindings to the same variable are disallowed. The lan-guage used was a normalized -calculus, extended with recursive let, (saturated)constructor applications and case expressions. To ensure sharing, arguments ofapplications are forced to be variables. A grammar for this language is givenin Figure 1 where the overline notation Ai denotes a vector A1; : : : ; An of sub-scripted entities.To avoid variable capture, the normalized language has the additional re-striction that all bound variables (either lambda, let or case bound) in the ini-tial expression must be distinct. (Weak head) normal forms are either lambdaabstractions or constructions. Throughout the paper, the symbol w will be usedto denote normal forms. The semantic rules are reproduced in Figure 2. There,a judgement : e + : w means that expression e, with free variables bound inheap , reduces to normal form w and produces a nal heap . The notationw means expression w where all bound variables have been replaced by freshnames. We say that : e + : w is a (successful) derivation if it can be provedby using the rules. A derivation can fail to be proved for instance because ofentering in a blackhole. This would happen in rule Var when a reference to vari-able x appears while reducing expression e and before reaching a normal form.1 Propositions proofs can be found at http://dalila.sip.ucm.es/~albertoe.

Page 42: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Proof of Corre tness for the STG Ma hine 35e! x -- variablej x:e -- lambda abstractionj e x -- applicationj letrec xi = ei in e -- recursive letj C xi -- constructor applicationj case e of Ci xij ! ei -- case expressionFig. 1. Launchbury's normalized -calculus

: x:e + : x:e Lam : C xi + : C xi Cons : e + : y:e0 : e0[x=y] + : w : e x + : w App : e + : w [ [x 7! e] : x + [ [x 7! w] : w V ar [ [xi 7! ei] : e + : w : letrec xi = ei in e + : w Letrec : e + : Ck xj : ek[xj=ykj ] + : w : case e of Ci yij ! ei + : w CaseFig. 2. Launchbury's natural semanticsAs this is done in a heap not containing a binding for x, no rule can be ap-plied and the derivation cannot be completed. Other forms of failure are thosecorresponding to ill-typed programs or innite loops.The main theorem in [3] is that the operational semantics is correct and completewith respect to a non-strict denotational semantics for the language, i.e. if e isa closed expression, then [[e]] 0 = v 6= ? if and only if there exist and w suchthat f g : e + : w and [[w]] = v, being 0 the empty environment and anenvironment dening the free variables of w and obtained from heap .2.2 Sestoft's improvementsSestoft introduces in [9] two main changes to the operational semantics of Fig-ure 2: (1) to move the renaming of variables from the Var rule to the Letrec one,and (2) to make in the Letrec rule the freshness condition locally checkable byextending judgements with a set A of variables under evaluation. The rst mod-ication aims at getting the semantics closer to an implementation in terms ofabstract machines. In the usual implementations, fresh variables (i.e. pointers)are created when introducing new closures in the heap in the Letrec rule. This isalso more economical than renaming all bound variables in a normal form. Thesecond modication makes more precise the denition of freshness: a variable isfresh in a judgement : e +A : w if it does not belong to either dom orA, and it is not bound either in range or e. The modied rules can be seen inFigure 3. In the Letrec rule, the notation e means the renaming e[pi=xi] wherepi are fresh variables in the judgement : letrec xi = ei in e +A : w.The dierence between the new rules and the ones in Figure 2 is the placewhere renaming is done. So, the only thing needed to prove the equivalencebetween the two sets of rules is that there is neither name capture nor duplicatedbindings to the same variable.Proposition 1 (Sestoft) Let e be a closed expression and fg : e +fg : wa successful derivation. Then, in no instance of rule App there can be variablecapture in e0[p=x], and in no instance of rule Var is p already bound in .Moreover, Sestoft proves that, in every derivation tree, there is a clean distinctionbetween free variables and bound variables in expressions appearing in judge-ments and in heaps. The rst ones are always pointers (in Figure 3 and in what

Page 43: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

36 A. de la En ina, R. Pe~na : x:e +A : x:e Lam : C pi +A : C pi Cons : e +A : x:e0 : e0[p=x] +A : w : e p +A : w App : e +A[fpg : w [ [p 7! e] : p +A [ [p 7! w] : w V ar [ [pi 7! ei] : e +A : w : letrec xi = ei in e +A : w where pi fresh Letrec : e +A : Ck pj : ek[pj=xkj ] +A : w : case e of Ci xij ! ei +A : w CaseFig. 3. Sestoft's natural semanticsfollows, they are denoted by p), and they are either bound in the correspond-ing heap, or they are under evaluation and belongs to A. The second ones areprogram variables belonging to the original expression (in Figure 3 and in whatfollows, they are denoted by x or y).Unfortunately, the proof of the theorem was done before introducing caseexpressions and constructors and, when the latter were introduced, the theoremwas not redone. With the current Case rule the freshness property is not locallycheckable anymore. While reducing the discriminant in judgement : e +A :Ck pj , fresh variables may be created with the same names as bound variables inthe alternatives, without violating the freshness condition. Then, in the secondpart of the premise, name capture may occur in expression ek[pj=xkj ].In the next section we introduce a modication to the rules in order to keepthe freshness locally checkable in presence of case expressions.A problem not addressed by Sestoft is garbage collection. One invariant ofthe derivation of any expression is that heaps always grow with new bindings,i.e. in every judgement : e +A : w, it turns out that dom dom .We are interested in having a semantics re ecting that garbage collection mayhappen at any time without altering the result of the evaluation. To this aim,we develop a set of rules in which all heaps are assumed to contain only livebindings. So, the garbage collector must be explicitly activated in certain rules.This forces us to maintain new sets during a derivation in order to keep all theroots of live bindings. This extension is also done in the next section.2.3 A modied natural semanticsTo solve the rst problem, i.e. having freshness locally checkable, we introduce amultiset C of continuations associated to every judgement. The alternatives ofa case are stored in this multiset during the evaluation of the discriminant. Wesay then that a variable is fresh in a judgement : e +AC : w if it does notbelong either to dom or to A, and it is not a bound variable either in e, or inrange . or in any continuation of C.To provide for garbage collection, we must rst decide which are the rootsof live closures. Of course, free variables of the current expression belong to the

Page 44: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Proof of Corre tness for the STG Ma hine 37set of roots. By observing the rules, it is clear that the continuations in setC should also provide additional roots. Otherwise, a minimal heap during thederivation of the discriminant might not include bindings for the free variablesof the alternatives. Symmetrically, during the derivation of the normal form offunction e in rule App, we should include the argument p of an application in theset of roots. So, we introduce an additional multiset B in judgements standingfor arguments of pending applications. A judgement will have the following form: : e +ABC : w where the intention is that be minimal w.r.t. e;B and C,and be minimal w.r.t. w;B and C.As the knowledgeable reader may have already noticed, set A is not an ad-ditional source of roots. This set represents bindings currently under evaluationor, in more operational terms, pending updates. If the only reference to a pend-ing update is that of set A, this means that the value of the corresponding freevariable will not be used anymore in the future. So, the variable can be safelydeleted from A, and the corresponding update avoided2. Moreover, we want tohave also minimal sets of pending updates in our derivations. This means thatthe set A associated to the initial expression of a given judgement needs not bethe same anymore than the set A0 associated to the nal expression. To takethis into account, a last modication of judgements is needed. Their nal formis the following one: A : e +BC A0 : wwhere and A are minimal w.r.t. e;B and C, and and A0 are minimal w.r.t.w;B and C. Its meaning is that expression e reduces to normal form w startingwith heap and set A, and ending with heap and set A0.That heaps and sets of pending updates are minimal is just a property thatmust be proved. To preserve this property in derivations, garbage collections andtrimming of pending updates must be activated at certain points. The semanticrules exactly clarify which these points are.Denition 2 Given a heap , an expression e, a multiset B of variables, anda multiset C of continuations, we dene the set of live variables of w.r.t. B;Cand e, denoted liveBCe :liveBCe = x (L : L [ fv e [ B [ fv C [ [p2Lffv e0 j (p 7! e0) 2 g)where fv e denotes the set of free variables of expression e, fv C is the obviousextension to a continuation and x denotes the least xed-point.Denition 3 Given a heap , a set of pending updates A, an expression e, amultiset B of variables, and a multiset C of continuations, we dene the liveheap of w.r.t. B;C and e, denoted BCegc , and the subset of live updates of Aw.r.t. ;B;C and e, denoted ABCegc :BCegc = fp 7! e j (p 7! e) 2 ^ p 2 liveBCe gABCegc = A \ liveBCe2 This trimming of the set of pending updates is done in the STG machine after eachgarbage collection. See [5, Section 10.7].

Page 45: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

38 A. de la En ina, R. Pe~naIn a judgement A : e +BC A0 : w, if a minimal heap and update set shouldbe ensured before the derivation starts, we will write gcAgc : e +BC A0 : w,meaning that the initial heap and update set should respectively be BCegc andABCegc . These gc annotations exactly mark the points in a derivation where agarbage collection or/and a trimming of the update set may be needed.The new set of rules is shown in Figure 4. Some explanations follow:Maintaining the correct set of roots When evaluating the discriminant ofa case (see rule Case), the pending alternatives must be included in set C inorder to avoid losing bindings for the free variables of the alternatives. Also,when evaluating the function of an application (see rules AppA and AppB), theargument must be included in set B in order to avoid losing the binding for it.Activating garbage collection in the appropriate points The gc annota-tion, meaning the trimming of a heap or of an update set, must be written inthose points where there may be the danger of dead bindings. These are: in rule AppB, when the parameter of the function does not appear in thebody. There is a danger that the binding for p in becomes dead. in rules VarA and VarB, when the reference to p disappear from the currentexpression. There may be no other reference to p either in e;B or C. in rule Case, when a particular alternative is chosen. The discarded alterna-tives may have free variables that now are dead.Avoiding unnecessary updates This is re ected in rule VarB. Assuming thatthe pair (;A0) is minimal w.r.t. w;B and C, and knowing that p =2 A0, thenthe update for variable p may be safely discarded (compare with rule VarA).Assuming no dead code in letrec Notice in the antecedent of rule Letrec thatno garbage collection is launched. So, we are assuming that all the new bindingsare live. This is not true if there exists dead code in the letrec expression. Itis easy for a compiler to eliminate unreachable bindings in a letrec. In whatfollows we will assume that dead code has been eliminated in our programs.New denition of freshness In the consequent of rule Letrec a set pi of freshvariables is created. A variable is fresh in judgement A : e +BC A0 : w if itdoes not belong to either dom or A, and it is not bound either in range , eor C.We will see now that the properties desired for our semantics in fact hold.Denition 4 Given a judgement A : e +BC A0 : w, we say that the cong-uration : e is ABC-good, if1. A \ dom = ;2. liveBCe = A [ dom 3. (bv [ bv e [ bv C) \ (A [ dom ) = ;where bv e denotes the bound variables of expression e, bv its extension to allexpressions in range , and bv C its extension to a continuation.The rst property has a similar counterpart in Sestoft's semantics and itasserts that variables under evaluation are not at the same time dened in theheap. The second one asserts that every free variable is either dened in theheap or is under evaluation and also that the pair (;A) is minimal w.r.t. B;Cand e. The third one asserts that free variables are dierent from bound ones.

Page 46: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Proof of Corre tness for the STG Ma hine 39A : x:e +BC A : x:e LamA : C0 pi +BC A : C0 pi ConsA : e +(B[fpg)C A0 : x:e0 x 2 fv e0 A0 : e0[p=x] +BC A00 : wA : e p +BC A00 : w AppAA : e +(B[fpg)C A0 : x:e0 x 62 fv e0 gcA0gc : e0 +BC A00 : wA : e p +BC A00 : w AppB (A [ fpg)gc : e +BC (A0 [ fpg) : w [ [p 7! e]A : p +BC [ [p 7! w] A0 : w V arA (A [ fpg)gc : e +BC A0 : w p 62 A0 [ [p 7! e]A : p +BC A0 : w V arB [ [pi 7! ei] A : e +BC A0 : wA : letrec xi = ei in e +BC A0 : w where pi fresh LetrecA : e +B(C[faltsg) A0 : Ck pj gcA0gc : ek[pj=xkj ] +BC A00 : wA : case e of alts +BC A00 : w CaseFig. 4. A natural semantics with minimal heaps and minimal update setsDenition 5 A judgement A : e +BC A0 : w is promising if the congura-tion : e is ABC-good.This denition ensures that the starting point of a derivation already meets therequirements we want for the whole derivation. The following proposition andcorollary establish that the desired properties in fact hold.Proposition 6 Let A : e +BC A0 : w be a derivation using the rules of thesemantics. If it is a promising judgement, then1. The conguration : w is A0BC-good2. A0 A3. Every judgement in the derivation is a promising one.Corollary 7 Let e be a closed expression and fg : e +fgfg A : w be aderivation. Then,1. In no instance of rules AppA and Case there can be variable capture insubstitutions of the form e[p=x].2. In no instance of rule VarA is p already bound in .The dierences between our semantics and Sestoft's are two:1. Sestoft's rules App and Var have been split into two in our semantics. Inthe rst case, the distinction is due to the desire of not launching garbagecollection when it is not needed, but in fact both rules could be combined inthe following single one:A : e +(B[fpg)C A0 : x:e0 gcA0gc : e0[p=x] +BC A00 : wA : e p +BC A00 : wIn the second case, our rule VarB does not add to the heap a binding [p 7! w]that is known to be dead.2. Our heaps and update sets are minimal in the corresponding judgements.Otherwise, the semantic rules are the same. Once we have proved that freevariables in judgements are either dened in the heap, or they belong to thepending updates set, both semantics produce exactly the same derivations.

Page 47: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

40 A. de la En ina, R. Pe~naHeap Control Environment Stack rule (e x) E [ [x 7! p] S app1=) e E [ [x 7! p] p : S y:e E p : S app2=) e E [ [y 7! p] S [ [p 7! (e0; E0)] x E [ [x 7! p] S var1=) e0 E0 #p : S y:e E #p : S var2=) [ [p 7! (y:e;E)] y:e E S letrec fxi = eig in e E S letrec ()=) [ [pi 7! (ei; E0)] e E0 S case e of alts E S case1=) e E (alts;E) : S Ck xi E [ [xi 7! pi] (alts;E0) : S case2 ()=) ek E0 [ [yki 7! pi] S Ck xi E #p : S var3=) [ [p 7! (Ck xi; E)] Ck xi E S() pi are distinct and fresh w.r.t. , letrec fxi = eig in e, and S. E0 = E [ [xi 7! pi]() Expression ek corresponds to alternative Ck yki ! ek in altsFig. 5. Abstract machine Mark-23 Sestoft's machine Mark-2After revising Launchbury's semantics, Sestoft introduces in [9] several abstractmachines in sequence, respectively called Mark-1, Mark-2 and Mark-3. The onewe will use for deriving an STG-like machine is Mark-2. There, a congurationconsists of a heap , a control expression e possibly having free variables, anenvironment E mapping free variables to pointers in the heap, and a stack S.The heap is a function from pointers to closures, each one (e; E) consistingof an expression e and an environment E binding its free variables to pointers.The stack contains three kinds of objects: (1) arguments of pending applications,represented by pointers; (2) continuations of pending pattern matchings, eachone consisting of a pair (alts ; E) where alts is a vector of case alternatives andE is an environment binding its free variables; and (3) update markers of theform #p, where p is a pointer.The reader may have already recognized that stack S represents in fact theunion of sets B;C and A we introduced in the revised semantics of Section 2.3.The main dierence now is that these entities form a list instead of a set ora multiset, and that they appear ordered from more recent to older ones. InFigure 5 the operational rules of Mark-2 machine are shown.We have followed Sestoft's convention that program variables are denoted byx or y, and pointers by p. The machine never makes explicit substitutions ofpointers for program (free) variables as the semantics does. Instead, it maintainsenvironments mapping program variables to pointers. If e is a closed expression,the initial conguration is (fg; e; fg; [ ]). The machine stops when no rule canbe applied. If the nal conguration has the form (;w;E; [ ]), then w has beensuccessfully derived from e and we write (fg; e; fg; [ ])) (;w;E; [ ]).The main theorem proved by Sestoft, is that successful derivations of themachine are exactly the same as those of the semantics.

Page 48: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Proof of Corre tness for the STG Ma hine 41Proposition 8 (Sestoft) For any closed expression e, then(fg; e; fg; [ ]) ) (;w;E; [ ]) if and only if fg e :+fg : wIt is worth to note that the correctness and completeness of machine Mark-2w.r.t. the operational semantics (by transitivity, w.r.t. the denotational seman-tics), does not rely on programs being well typed. If a program is ill-typed boththe machine and the semantics will be unable to derive a normal form for it.3.1 Some properties of environmentsMark-2 environments have a complex evolution: they grow with lambda applica-tions, pattern matching and letrec execution; they are stored either in closuresor in the stack in some transitions, and they are retrieved from there in someother transitions. It is natural to wonder about how much can they grow.Denition 9 A closure (e; E), is consistent if1. fv e \ bv e = ; and all variables in bv e are distinct.2. fv e dom E.3. bv e \ dom E = ;This denition can be easily extended to a continuation of the form (alts ; E)and to a heap consisting of a set of closures.Denition 10 A conguration (; e; E; S) of machine Mark-2 is consistent if1. is consistent.2. The pair (e; E) is consistent.3. All continuations (alts ; E) 2 S are consistent.These denitions only take care of program variables being well dened in envi-ronments. That pointers are well dened in the heap (or they belong to stack Sas update markers) was already proved by Sestoft for all his machines.Proposition 11 Let e be a closed expression in which all bound variables aredistinct, and (fg; e; fg; [ ]) ) (; e0; E; S) any (possibly partial) derivation ofmachine Mark-2. Then,1. (; e0; E; S) is consistent.2. E exactly binds all variables in scope in expression e0.3. In any closure (ei; Ei) 2 , Ei exactly binds all variables in scope in ei.4. In any pair (alts; E) 2 S, E exactly binds all variables in scope in alts.4 The abstract machine STG-1S4.1 The common languageIn order to get closer to the STG machine, rstly we dene a common -calculusfor both machines, Mark-2 and STG. This is presented in Figure 6 and we call itFUN. It is equivalent to the STG language (STGL) excluding primitive valuesan expressed in a more traditional -calculus syntax.Compared to the original Mark-2 -calculus (see Figure 1), it is clear thatFUN is just a subset of it, having the restrictions: that lambda abstractions mayonly appear in bindings and that applications have the form x xin understoodby Mark-2 as (: : : (x x1) : : :) xn.

Page 49: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

42 A. de la En ina, R. Pe~nae ! x xin -- n 0, application/variablej letrec bind i in e -- recursive letj C xi -- constructor applicationj case e of alti jt -- case expressionbind ! x = lf jtlf ! xin:e -- n 0, lambda formalt ! C xj ! eFig. 6. Denition of FUNThe notation xin:e is an abbreviation of xn: :x1:e, where the argu-ments have been numbered downwards for convenience. In this way, xin1:emeans xn1: :x1:e and x xin means x x1 : : : xn. When n = 0 we willsimply write e instead of xin:e and x instead of x xin.A last feature added to FUN is trimmers. The notation lf jt means that alambda form is annotated at compile time with the set t of its free variables. Thisset t was called a trimmer in [9]. It will be used when constructing a closure inthe heap for the lambda form. The environment stored in the closure will onlybind the variables contained in the trimmer. This implies a small penalty interms of execution time but a lot of space saving. Analogously, alti jt means theannotation of a set of case alternatives with the trimmer t of its free variables.When alti is pushed into the stack, its associated environment will be trimmedaccording to t. Both optimizations are done in the STG machine, even thoughthe second one is not re ected in the rules given in [5].4.2 Mark-2 machine for language FUNIn Figure 7, the transition rules of Mark-2 for language FUN are shown. Let usnote that the control expression is in general a lambda form lf . In particular, itcan also be an expression e, if lf = xi0:e. Also, all occurrences of superscripts nare assumed to be n > 0. Note that, this is not a dierent machine, but just thesame machine Mark-2 executed with a restricted input language. Additionally,there are some optimizations which do not essentially aect the original behavior: Original rule var1 has been split into three: the one corresponding to theoriginal var1 is now called var1c; the two other rules are just special casesin which the expression referenced by pointer p is a normal form. The orig-inal Mark-2 machine will execute in sequence either rule var1 followed byrule var2, or rule var1 followed by rule var3. These sequences have beenrespectively subsumed in the new rules var1a and var1b. Trimmer sets have been added to lambda forms and to continuations. En-vironments are trimmed to the set of free variables when new closures arecreated in the heap in rules letrec and var3, and also when continuations arestored in the stack in rule case1. This modication only aects to the setof live closures in the heap which now is smaller. Otherwise, the machinebehavior is the same.In Figure 7, a new column Last has been added recording the last rule executedby the machine. This eld is important to dene stable congurations, which willbe used to compare the evolution of Mark-2 and STG-1S (see Section 4.3).

Page 50: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Proof of Corre tness for the STG Ma hine 43Heap Control Environment Stack Last rule x xin E [ [xn 7! p] S l app1=) x xin1 E [ [xn 7! p] p : S app1 xin:e E p : S l app2=) xin1:e E [ [xn 7! p] S app2 [ [p 7! (xin:e0; E0)] x E [ [x 7! p] S l var1a=) [ [p 7! (xin:e0; E0)] xin:e0 E0 S var1a [ [p 7! (C xi; E0)] x E [ [x 7! p] S l var1b=) [ [p 7! (C xi; E0)] C xi E0 S var1b [ [p 7! (e0; E0)] x E [ [x 7! p] S l var1c ()=) e0 E0 #p : S var1c xin:e E #p : S l var2=) [ [p 7! (xin:e; E)] xin:e E S var2 letrec xi = lf i jti in e E S l letrec ()=) [ [pi 7! (lf i; E0 jti)] e E0 S letrec case e of alts jt E S l case1=) e E (alts;E jt) : S case1 Ck xi E [ [xi 7! pi] (alts;E0) : S l case2 ()=) ek E0 [ [yki 7! pi] S case2 Ck xi E #p : S l var3=) [ [p 7! (Ck xi; E jfxig)] Ck xi E S var3() e0 6= C xi y e0 6= xin:e() Variables pi are distinct and fresh w.r.t. , letrec xi = lf i jti in e, and S, E0 = E [ [xi 7! pi]() Expression ek corresponds to alternative Ck yki ! ek in altsFig. 7. Abstract machine Mark-2 for FUNDenition 12 A conguration (; lf ; E; S; l) of machine Mark-2 is stable if oneof these two conditions hold:1. lf = e ^ l =2 fapp1 ; var3 g, or2. S = [ ] ^ ((lf = xin:e ^ n > 0) _ lf = C xi)In the STG machine, lambda abstractions never appear in the control expression,so it seems natural to exclude lambda abstractions from stable congurations.If the last rule executed is app1, then Mark-2 is still pushing arguments in thestack and it has not yet evaluated the variable x corresponding to the function tobe applied. In the STG all these intermediate states do not exist. If the last ruleapplied is var3, then the STG is probably still doing updates and, in any case,pattern matching has not been done yet. As we want to compare congurationsin which a FUN expression appears in the control, all these states must beregarded as `internal'. The second possibility is just a termination state.Denition 13 Let us assume that m and m0 are stable congurations of Mark-2machine, and m)+ m0, (i.e. there must be at least one transition) and there isno other stable conguration between m and m0. We will say that m evolves tom0 and will denote it by m)+s m0.4.3 The machine STG-1SIn this section we dene an abstract machine very close to the STG [5] and showthat it is correct and complete w.r.t. Mark-2 of Figure 7. We call it STG-1S

Page 51: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

44 A. de la En ina, R. Pe~naHeap Control Environment S rule Eval (x xin) E [ [x 7! p; xi 7! pi] S 1=) Enter p fg pi : S [ [p 7! (xin:e; E)] Enter p fg pin : S 2=) [ [p 7! (xin:e; E)] Eval e E [ [xi 7! pi] S [ [p 7! (C xi; E)] Enter p fg S 20=) [ [p 7! (C xi; E)] Eval (C xi) E S Eval (letrec fxi = lf i jtig in e) E S 3 (1)=) [ [pi 7! (lf i; E0 jti)] Eval e E0 S Eval (case e of alts jt) E S 4=) Eval e E (alts;E jt) : S Eval (C xi) E [ [xi 7! pi] S 5=) ReturnCon C pi fg S ReturnCon Ck pi fg (alts;E) : S 6 (2)=) Eval ek E [ [yki 7! pi] S [ [p 7! (e; E)] Enter p fg S 15 (3)=) Eval e E #p : S ReturnCon C pi fg #p : S 16 (4)=) [ [p 7! (C xi; [xi 7! pi])] ReturnCon C pi fg S [ [p 7! (nxi:e; E)] Enter p fg pik : #p0 : S 17 (5)=) 0 Enter p fg pik : S(1) Variables pi are distinct and fresh w.r.t. , letrec xi = lf i jti in e, and S, E0 = E [ [xi 7! pi](2) Expression ek corresponds to alternative Ck yki ! ek in alts(3) Expression e 6= C xi y e 6= xin:e0(4) In rule 16, xi are arbitrary distinct variables.(5) k < n and 0 = [ [p 7! (nxi:e; E); p0 7! (nkxi:e; E [ [xi 7! pik])]Fig. 8. Abstract machine STG-1Sbecause the main dierence with the actual STG is that it has one stack insteadof three. The single stack of STG-1S, contains the three usual kind of objects:arguments of applications, continuations and update markers. Being faithful toSTGL, the control expression of STG-1S may have three dierent forms: Eval e E, where e is a FUN expression (we recall that this excludes lambdaforms) and E is an environment mapping e's free variables to heap pointers. Enter p, where p is a heap pointer. Notice that there is no environment. ReturnCon C pi, where C is a data constructor and pi are its argumentsgiven as a vector of heap pointers. Also, there is no environment here.We will call each of these expressions an instruction, and use the symbol i todenote them. In order to better compare it with the Mark-2 machine, we willconsider a conguration of the STG-1S to be a 4-tuple (; i; E; S), where is a heap mapping pointers to closures, i is the control instruction, E is theenvironment associated to instruction i in case the instruction is of the form Evale, and the empty environment fg otherwise, and S is the stack. In Figure 8, thetransition rules of STG-1S are shown.We have numbered the rules with the same numbers used in [5] for easyreference. As there is no explicit ag \ in FUN lambda forms in order to avoidunnecessary updates, rules 2 and 20 re ect that no update frame is pushed inthe stack when explicit normal forms in the heap are referenced. Rule 20 doesnot appear in [5], but it is implicit in rule 2.

Page 52: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Proof of Corre tness for the STG Ma hine 45Now we proceed with the comparison. As in Mark-2, we rst dene stablecongurations in STG-1S. A stable conguration corresponds either to the eval-uation of a FUN expression or to a termination state.Denition 14 A conguration s = (; i; E; S) of machine STG-1S is stable if1. i = Eval e for some e, or2. s = (;ReturnCon C pi; fg; [ ]), or3. s = ( [ [p 7! (xin:e; E0)];Enter p; fg; [p1; : : : ; pk]) ^ n > k 0.Congurations 2 and 3 correspond to termination states. Notice in 3 that theSTG-1S may successfully stop with a non-empty stack. This would happen whenthe initial expression evaluates to a lambda abstraction. As in Mark-2 machine,we will use s )+s s0 to denote the evolution between two stable congurationsin STG-1S with no intermediate stable ones, and say that s evolves to s0. Thenotion of consistent conguration for the STG-1S machine is the same given inDenition 10 for machine Mark-2.We will now compare two evolutions, one in each machine starting fromequivalent states, and show that they exactly pass through the same number ofstable congurations and that the corresponding congurations are equivalent.This amounts to saying that there exists a bisimulation between the machines.To simplify to notion of conguration equivalence, we will assume that bothmachines use exactly the same fresh name generator in rule letrec. So, if thegenerator is given the same inputs (i.e. the same control expression, heap andstack), it will generate the same set of fresh variables.Denition 15 A conguration m = (; lf ; E; S; l) in a stable state of machineMark-2 and a conguration s = ( 0; i; E0; S0) in a stable state of machine STG-1S are said to be equivalent, written m s, if = 0, and one of the following possibilities holds:1. i = Eval e ^ lf = e ^ E = E0 ^ S = S02. i = ReturnCon C pi ^ lf = C xi ^ pi = E xi ^ S = S0 = [ ]3. i = Enter p ^ 0 p = (xin:e; E00) ^ S0 = [p1; : : : ; pk] ^ n > k 0 ^ lf = xink:e ^ E [xn; : : : ; xnk+1] = [p1; : : : ; pk]The following proposition and corollary establish that STG-1S and Mark-2 ma-chines bisimulate each other. By transitivity this shows that STG-1S is correctand complete w.r.t. Launchbury's natural semantics.Proposition 16 Given two stable and consistent congurations m and s in re-spectively Mark-2 and STG-1S machines such that m s,1. If m )+s m0, then there exists a stable and consistent conguration s0 suchthat s)+s s0 and m0 s0.2. If s )+s s0, then there exists a stable and consistent conguration m0 suchthat m)+s m0 and m0 s0.Corollary 17 If e is a closed FUN expression, then (fg; e; fg; [ ];?) ) mfin Mark-2 machine with mf = (;w;E; [ ]) if and only if there exists a stableconguration sf such that (fg;Eval e; fg; [ ])) sf in STG-1S and mf sf .

Page 53: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

46 A. de la En ina, R. Pe~na5 The abstract machine STGIt has three stacks: the argument stack as containing arguments for pendingapplications; the return stack rs containing pairs (alts ; E); and the update stackus containing update frames. An update frame is a triple (as ; rs ; p) consisting ofan argument stack, a return stack and a pointer p to the closure to be updated.We do not show the STG rules as they can be easily derived from those ofSTG-1S. A conguration will be a 6-tuple (; i; E; as; rs; us).The two dierences with the STG-1S machine of previous section are: Pushing and popping is done in the appropriate stack according to the rule. Instead of pushing update markers, the STG machine pushes update framesand leaves empty argument and return stacks in the conguration. When anormal form is reached with empty stacks, an update is triggered.Apparently, these dierences are not essential and one may think that the be-haviours of both machines are the same. This is not the case as we will see in amoment. The splitting of the single stack into three has the unfortunate conse-quence of losing the temporal order of events between stacks as and rs. Then, acontinuation pushed into rs before an argument is pushed into as can be retrievedalso before the argument is retrieved form as instead of after, as it would be thecase in the STG-1S machine. Consider the following ill-typed program:e = letrec y1 = Nil; id = x:x in case y1 y1 of Nil ! idwhich has no semantics. The STG machine reduces it as follows:(fg; e; fg; [ ]; [ ]; [ ])) (1; Eval (case y1 y1 of Nil! id); E1; [ ]; [ ]; [ ])) (1; Eval (y1 y1); E1; [ ]; [(Nil! id; E1)]; [ ])) (1; Enter p1; fg; [p1]; [(Nil! id; E1)]; [ ])) (1; Eval Nil; fg; [p1]; [(Nil! id; E1)]; [ ])) (1; ReturnCon Nil fg; [p1]; [(Nil! id; E1)]; [ ])) (1; Eval id; E1; [p1]; [ ]; [ ])) (1; Enter p2; fg; [p1]; [ ]; [ ])) (1; Eval x; [x 7! p1]; [ ]; [ ]; [ ])) (1; Eval Nil; fg; [ ]; [ ]; [ ])) (1; ReturnCon Nil fg; [ ]; [ ]; [ ])where 1 = [p1 7! (Nil; fg); p2 7! (x:x; fg)] and E1 = [y1 7! p1; id 7! p2].So, the correctness of the STG machine with three stacks relies on programsbeing well-typed. This was not the case with the STG-1S machine: if a programis ill-typed, both Launchbury's semantics and STG-1S will be unable to derivea normal form for it.However, the STG is complete in the sense that every successful derivationdone by the STG-1S can obviously be done by the STG. For every congurationof the STG-1S we can exactly compute a single equivalent conguration in theSTG machine. The opposite is not true, i.e. given the three stacks as, rs and usof STG, many dierent stacks for the STG-1S can be constructed by interleavingthe contents of the corresponding sections of stacks as and rs.

Page 54: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Proof of Corre tness for the STG Ma hine 476 ConclusionsThe paper has followed all the way from an abstract operational semantics forlazy evaluation such as Launchbury's, to a very concrete and ecient abstractmachine such as the STG. Part of that way had already been followed by Sestoftin [9]. We have started at one of his machines, the Mark-2, and have shown thata STG machine with one stack can be derived from it, and that a bisimulationcan be dened between both.We have solved a small problem of Sestoft's semantics regarding freshness ofvariables and also added some garbage collection considerations to his semantics.As a result, the stack of Sestoft's machines appears very naturally as a trans-formation of some sets A;B and C needed by the semantics in order to have acomplete control over freshness and over live closures. It is interesting to notethat the optimization of not using the set of update markers as roots for thegarbage collector can be easily understood at the semantic level.We have also shown that the correctness of the three stacks STG machineas described in [5] relies on program being well-typed. This was an underlyingassumption which was not explicitly stated in that description.The obvious solution to this `problem' is to come back to a single stack ma-chine, and this seems to be the option recently chosen by GHC's implementors(although probably due to dierent reasons) [8]. Having only one stack com-plicates the garbage collector task because pointers and non-pointers must beclearly distinguished. The presence of unboxed primitive values in the stackmakes the problem even worse. In compensation, update markers are smallerthan update frames and, most important of all, the temporal order of events ispreserved.References1. J. Fairbairn and S. C. Wray. TIM: A Simple, Lazy Abstract Machine to ExecuteSupercombinators. In Proc. of the 1987 Conference on Functional ProgrammingLanguages and Computer Architecture, Portland, Oregon, September 1987.2. T. Johnsson. Ecient Compilation of Lazy Evaluation. ACM SIGPLAN Notices,19(6):5869, June 1984.3. J. Launchbury. A Natural Semantics for Lazy Evaluation. In Proc. Conference onPrinciples of Programming Languages, POPL'93. ACM, 1993.4. J. Mountjoy. The Spineless Tagless G-machine, Naturally. In Third InternationalConference on Functional Programming, ICFP'98, Baltimore. ACM Press, 1998.5. S. L. Peyton Jones. Implementing Lazy Functional Languages on Stock Hardware:the Spineless Tagless G-machine, Version 2.5. Journal of Functional Programming,2(2):127202, April 1992.6. S. L. Peyton Jones, C. V. Hall, K. Hammond, W. D. Partain, and P. L. Wadler.The Glasgow Haskell Compiler: A Technical Overview. In Joint Framework for Inf.Technology, Keele, pages 249257, 1993.7. S. L. Peyton Jones and J. Hughes, editors. Report on the Programming LanguageHaskell 98. URL http://www.haskell.org, February 1999.8. S. L. Peyton Jones, S. Marlow, and A. Reid. The STG Runtime System (revised).http://www.haskell.org/ghc/docs, 1999.9. P. Sestoft. Deriving a Lazy Abstract Machine. Journal of Functional Programming,7(3):231264, May 1997.

Page 55: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 56: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Improving the EÆ ien y ofNon-Deterministi ComputationsSergio Antoy1 Pas ual Julian Iranzo2;3 Bart Massey1Computer S ien e DepartmentPortland State UniversityPortland, Oregonantoy,pjulian,bart s.pdx.eduAbstra t. Non-deterministi omputations greatly enhan e the expres-sive power of fun tional logi programs, but are often omputationallyexpensive. We analyze two programming te hniques that improve thetime and memory eÆ ien y of some non-deterministi omputations.These te hniques rely on the introdu tion of a new symbol into the sig-nature of a program. In one te hnique this symbol is a polymorphi dened operation, in the other an overloaded onstru tor. Our program-ming te hniques may save exe ution time by redu ing the number ofsteps of a omputation, as well as memory o upation, by redu ing thenumber of terms onstru ted by a omputation. We show how to applyour te hniques using some examples, and informally reason about theiree ts.1 Introdu tionFun tional logi programming studies the design and implementation of pro-gramming languages that integrate both fun tional programming and logi pro-gramming into a homogeneous paradigm. In re ent years, it has be ome in reas-ingly evident that non-determinism is an essential feature of these integratedlanguages. Non-determinism is a ornerstone of logi programming. It allowsproblem solving using programs that are textually shorter, easier to understandand maintain, and more de larative than their deterministi ounterparts.In a fun tional logi programming language, non-deterministi omputationsare modeled by the dened operations of a onstru tor-based left linear ondi-tional rewrite system. With respe t to logi omputations, whi h are based onresolution, fun tional logi omputations are nested and therefore an be lazilyexe uted. The ombination of these features makes fun tional logi languagesboth more expressive than fun tional languages and more eÆ ient than tradi-tional logi languages.1 Supported in part by the NSF grant INT-9981317.2 Supported by the Spanish Knowledge So iety Foundation.3 Permanent Address: Univ. Castilla La-Man ha, Spain, pjulianinf- r.u lm.es.

Page 57: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

50 S. Antoy, P. Julian, B. MasseyA typi al approa h to the denition of non-deterministi omputations is bymeans of the dened operations of a onstru tor based non- on uent rewritesystem. The following emblemati example [8, Ex. 2 denes an operation, oin,that non-deterministi ally returns either zero or one. Natural numbers, repre-sented in Peano notation, are dened by the datatype (or sort) nat.datatype nat = 0 | s nat oin = 0 oin = s 0Rewrite systems with operations su h as oin are non- on uent. A omputationin these rewrite systems may have distin t normal forms and/or non terminate.To understand non-determinism in the ontext of a omputation, onsider thefollowing operations:add 0 Y = Yadd (s X) Y = s (add X Y)positive 0 = falsepositive (s -) = trueThe evaluation of a term su h as positive (add oin 0) requires the eval-uation of subterm oin. This subterm has two repla ements, i.e., 0 and s 0.Ea h repla ement leads to a dierent nal result. The hoi e between these tworepla ements is non-deterministi . Assuming that non-determinism is appropri-ately used in the program where the evaluation o urs, there is no feasible meansof de iding whi h repla ement should be hosen at the time oin is evaluated.Therefore, evaluation under both repla ements must be onsidered.To ensure operational ompleteness, all the possible repla ements of a non-deterministi omputation must be exe uted fairly. In fa t, if one repla ementis exe uted only after the omputation of another repla ement is ompleted,the se ond repla ement will never be exe uted if the omputation of the rstrepla ement does not terminate. Thus, ontinuing with our example, to om-pute positive (add oin 0) one must ompute fairly and independently bothpositive (add 0 0) and positive (add (s 0) 0).This approa h, whi h we refer to as fair independent omputations, apturesthe intended semanti s, but learly it is omputationally ostly. In some situa-tions the ost of fair independent omputations might be avoided. For example,dene a \bigger" variant of oin:bigger = s 0bigger = s (s 0)and onsider again the previous example, but invoking bigger instead of oin.The evaluation of positive (add bigger 0), whi h will be shown in its entiretylater, may be arried on, as in the previous example, using fair independent omputations. However, this is not ne essary. The omputation has a single resultthat may be obtained using only deterministi hoi es. Avoiding fair independent omputations saves exe ution time, memory o upation, and the dupli ation ofthe result.In this paper, we dis uss two programming te hniques that have been onsid-ered within a proje t aiming at the implementation of a ba k-end for a wide lassof fun tional logi languages [7. In some ases, these te hniques have the po-

Page 58: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Improving the Efficiency of Non-Deterministics Computations 51tential to oer substantial improvements. In other ases, they tend to onsumeslightly more memory, but without a substantial slowdown. We are urrentlyworking to assess whether either or both te hniques should be deployed in theba k-end: this do ument is a report of our preliminary ndings.Se tion 2 dis usses the usefulness of non-deterministi omputations in fun -tional logi programs and how they are related to our work. Se tion 3 justiesour overall approa h to measuring the eÆ ien y of a omputation. Se tion 4presents the programming te hniques that are the fo us of our work. In some ases, these te hniques redu e the omputing time and/or the memory onsump-tion attributed to non-deterministi omputations. Se tion 5 dis usses, both the-oreti ally and experimentally, the ee ts of our te hniques on some examples.Se tion 6 ontains our on lusions.2 Non-DeterminismNon-determinism is an essential feature of logi programming, perhaps the singlemost important reason for its a eptan e and su ess. Some early proposalsof fun tional logi programming languages negle ted this aspe t. Programs inthese early languages were modeled by weakly orthogonal rewrite systems. Inthese languages, the results of non-deterministi omputations are obtained byinstantiating the arguments of a predi ate. A serious drawba k of this situation isthat a non-deterministi omputation annot be fun tionally nested in another omputation. The lazy evaluation of non-deterministi omputations be omesimpossible and the eÆ ien y of a program may in ur severe losses.More re ently [4, 8, non-determinism in fun tional logi programming hasbeen des ribed using the operations of a non- on uent Term Rewriting System(TRS). These operations are quite expressive, in that they allow a programmerto translate problems into programs with a minimal eort. For example, thefollowing operation omputes a non-empty regular expression over an alphabetof symbols. Ea h non-empty regular expression is obtained by appropriate non-deterministi hoi es of a omputation.regexp X = Xregexp X = "(" ++ regexp X ++ ")"regexp X = regexp X ++ regexp Xregexp X = regexp X ++ "*"regexp X = regexp X ++ "|" ++ regexp XThe denition of operation regexp losely resembles the formal denition ofregular expression, e.g., as found in [1, p. 94. This transparen y in semanti s an be very onvenient for the programmer. For example, to re ognize whether astring s denotes a well-formed non-empty regular expression over some alphabeta, it suÆ es to evaluate regexp a = s,Non-deterministi operations support a terse programming style, but mayimpose a sti penalty on exe ution performan e. In pra ti e, several omputa-tions originating from a non-deterministi hoi e may have to be exe uted fairly.Therefore, te hniques to improve the eÆ ien y of non-deterministi omputa-tions, in parti ular to limit the number of fair independent omputations that

Page 59: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

52 S. Antoy, P. Julian, B. Masseyoriginate from a non-deterministi hoi e, are quite useful. The overall goal ofthis paper is the study of two te hniques for this purpose.3 Cost AnalysisThe most ommon approa h to analyzing the eÆ ien y of a program is mea-suring its exe ution time and memory o upation. We measure the exe utiontime of ben hmark programs by means of primitives available in our run-timeenvironment. In addition to measuring the amount of memory used during theexe ution of a program by means of primitives, we ompute the amount of mem-ory used by simple ben hmarks using a theoreti al te hnique. In this se tion, wedis uss this theoreti al approa h to memory usage measurement.Our starting point is the number of appli ations ost riterion dened in ear-lier work on partial evaluation [2, Def. 2. This riterion intends to measure thestorage that must be allo ated for exe uting a omputation. We adapt the rite-rion to the behavior of our run-time environment. We also address the problemsof non-deterministi steps. We show that non-determinism, whi h is not onsid-ered in the earlier denition, adds an interesting twist to the situation.The following denitions formalize our adaptation of the ost riterion \num-ber of appli ations."Denition 1 (number of appli ations). We denote by A an overloaded fun -tion, alled the number of appli ations, as follows:- If t is a term, A(t) = p2P(t) (arity(root(tjp)) + 1), where P(u) is the setof positions of non variable symbols of arity greater than zero in any termu, root(u) is the root symbol of any term u, and arity(f) is the arity of anysymbol f .- If R l! r is a rewrite rule,1 we dene A(R) = A(r).- If C t !R1 t1 !R2 !Rn tn is a omputation of a term t to a on-stru tor term tn, we dene A(C) = A(tn) +ni=1A(Ri).The number of appli ations of a term t is the total number of o urren es ofn-ary symbols, with n > 0, in t, plus their arities. In our run-time environment(and, we believe, in many lazy language implementations) it is appropriate to onsider both dened operation and onstru tor symbols o urring in the term.The number of appli ations of a omputation a ounts for the number of appli- ations of ea h step and the number of appli ations of the result. In a run-timeenvironment that supports in-pla e updates, it would not be ne essary to a - ount for the number of appli ations of the result. We use the implementation ofnarrowing in Prolog des ribed in [6. We have veried on several simple programsthat this implementation allo ates memory in a ordan e to our denition.Earlier work [2 shows that the number of redu tion steps of a omputationis weakly orrelated to its exe ution time. Nevertheless, we ount the number ofsteps [2, Def. 1 of a omputation, sin e the omputation of all ost riteria inthis work is based on steps.1 Without loss of generality, we onsider only un onditional rules [5.

Page 60: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Improving the Efficiency of Non-Deterministics Computations 53Most ost analysis te hniques in the literature are proposed for deterministi omputations. Non-deterministi omputations in fun tional logi programmingare a relatively newer on ept, and introdu e signi ant theoreti al and pra ti al ompli ations.To ensure operational ompleteness, non-deterministi omputations must beexe uted fairly. A onsequen e of this ondition is that when a program outputs aresult (derived, for example, by using the rst alternative in a non-deterministi omputation) the time and spa e resour es onsumed from the beginning ofthe exe ution to the time of the output may not be a orre t indi ation ofthe ost of omputing that result. The reason is that the measured values mayin lude resour es spent to partially ompute other results that have not yet beenoutput. The extent of these omputations, and onsequently a quanti ation ofthe resour es spent by these omputations, are generally diÆ ult to estimate.A better approa h would be to measure the resour es needed to ompute allthe results of a non-deterministi omputation, but this is impossible in pra ti efor omputations over an innite sear h spa e, su h as the omputation of theregexp operation presented earlier.To deal with these diÆ ulties, whi h to date have no universally a eptedsolution, we onsider only simple examples. In parti ular, we reason with naturalnumbers in Peano notation. This de ision is quite onvenient for explanationpurposes. In pra ti e, one te hnique that we will dis uss in the next se tion maynot be well suited for builtin types, su h as binary integers.We informally reason about the number of steps of a omputation and thememory o upied to represent terms. In typi al implementations of rewrite sys-tems and fun tional logi programs, terms are represented by dynami (linked)data stru tures. In these stru tures, ea h o urren e of a symbol of arity ngreater than zero takes n+1 units of dynami (heap) memory. Nullary symbolsare allo ated in global (stati ) memory. Variables are lo al to rules or lauses andare allo ated in lo al (sta k) memory. The following pi ture informally shows the5 units of memory allo ated to represent the term positive (add oin 0). Thesymbols in the right olumn are allo ated in global memory. They are not notspe i ally allo ated to represent any term, but are shared by all terms. Thenumber of arguments of an o urren e of a symbol is not a part of the termbe ause in our run-time environment, Prolog, symbols are fully applied. // positive // // add // oin // 0The previous analysis [2 and the adaptation introdu ed in this se tion arelimited to deterministi omputations. The extension to non-deterministi om-putations would be a non-trivial task. We believe that our less formal dis ussionis appropriate for our goals and easier to grasp than a more rigorous approa h.To understand why the treatment of non-deterministi omputations is more ompli ated, onsider the evaluation of t = s oin. This term has two normal

Page 61: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

54 S. Antoy, P. Julian, B. Masseyforms, s 0 and s (s 0). The root symbol of ea h normal form an be tra ed ba kto the root symbol t. This shows that fair independent omputations may have todupli ate the portion of a term above a redex with distin t redu ts. Hen e, evenin run-time environments that support in-pla e updates, the ost of a step maydepend on its ontext. This onsideration further supports the appropriatenessof in luding the number of appli ations of the result of a omputation in thenumber of appli ations of the omputation itself.4 Programming Te hniquesWe attempt to improve the eÆ ien y of non-deterministi omputations byavoiding the dupli ation of both redu tion steps and term representations thato ur within fair independent omputations. We use two programming te h-niques that a hieve some improvements in some ases. In other words, our ap-proa h is a guideline for the programmer, i.e., a suggestion on how to ode ertainproblems into programs. However, we envision that an optimizing ompiler ora similar spe ialized tool ould automati ally transform a program in the sameway. In fa t, several experimental variations of the se ond te hnique have beenautomati ally implemented in our urrent system [7.Both of our programming te hniques are based on the introdu tion of a newsymbol into the signature of the TRS modeling a fun tional logi program. Onete hnique regards the new symbol as a polymorphi dened operation, the otheras an overloaded onstru tor. The rst approa h is not new [8: our ontributionin this ase is limited to re ognition that there are potential benets of thiste hnique in the ontext of modern FLP implementation, and the quanti ationof these benets. The new symbol that we introdu e, is denoted by the inxoperator \!", and read as alternative.4.1 The Alternative OperatorIn the rst programming te hnique, the alternative operation is dened by therules:X ! Y = XX ! Y = YAn operation with these rules is alled alt and denoted by \==" in the work ofGonzalez-Moreno et. al. [8, 9. We ould regard this symbol as left asso iativeor overload it for arbitrarily long argument lists: in our examples the symbol isalways binary, so the dieren e is irrelevant.The alternative operation allows us to give a dierent, though equivalent,denition of the operation bigger presented earlier.bigger = s (0 ! s 0)The signi ant dieren e is that a ommon portion of the right-hand sides ofthe two rewrite rules of the original denition of bigger has been \fa tored".This new denition an be dire tly oded by the programmer or it ould beautomati ally obtained from the original denition by an optimizing ompiler orother spe ialized tool.

Page 62: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Improving the Efficiency of Non-Deterministics Computations 55The advantage of this denition of bigger with respe t to the original oneis that if only the fa tored portion of the two alternative right-hand sides of therewrite rules of bigger is needed by a ontext, no fair independent omputationsare reated by a needed strategy [4. A single deterministi omputation suÆ esin this ase. This is exa tly what the omposition of positive and add requires,as shown by the following derivation:positive (add bigger 0)! positive (add (s (0 ! s 0)) 0)! positive (s (add (0 ! s 0)) 0)! trueTwo omputations have been repla ed by a single omputation of the samelength. In ases where fa toring the right-hand sides of two rewrite rules doesnot eliminate the need of fair independent omputations, the run-time ost ofthe fa torization is a single additional rewrite step. For realisti programs, this ost is negligible. Hen e, the fa torization of right-hand sides is a worthwhilepotential improvement. In the best ase, it saves omputing time and/or storagefor representing terms. In the worst ase, it osts one extra step and very littleadditional memory.4.2 The Alternative Constru torOur se ond approa h is to onsider the alternative symbol as a onstru tor.Sin e fun tional logi programs are generally strongly typed, they are modeledby many-sorted rewrite systems. This ondition requires overloading the symbol\!" for ea h sort in whi h it is introdu ed.The onsequen es of introdu ing su h an overloaded onstru tor are inter-esting. For example, the new denition of bigger is like the previous onebigger = s (0 ! s 0)ex ept that the right-hand side is an irredu ible ( onstru tor) term. In this ex-ample, new onstru tor terms should be interpreted as non-deterministi hoi esin sets of terms. The right-hand side of the denition of bigger is interpretedas an element in the set fs 0; s (s 0)g. In general, we think that extendingbuiltin types, (su h as the integers or booleans) or well-known types (su h asthe naturals) is inappropriate. Extending a sort with new onstru tor symbolsradi ally hanges the nature of that sort. The interpretation of the new termsof an extended sort may be diÆ ult. Nevertheless, we do it here for the sort natfor its immediateness and to ease the omparison with the examples presentedfor the rst te hnique.The introdu tion of a new onstru tor symbol makes some formerly well-dened operations in ompletely dened. It is relatively easy to orre t this prob-lem in the lass of the overlapping indu tively sequential TRSs [4. Every oper-ation in this lass has a denitional tree [3. The ne essary additional rules maybe determined from this tree. For example, onsider the operation that halves anatural:half 0 = 0half (s 0) = 0

Page 63: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

56 S. Antoy, P. Julian, B. Masseyhalf (s (s X)) = s (half X)If the type natural is extended by an alternative onstru tor, the following ad-ditional rewrite rules omplete the denition of half:half (X ! Y) = (half X) ! (half Y)half (s (X ! Y)) = (half (s X)) ! (half (s Y))In general, a new rewrite rule is needed for ea h bran h of the tree. If is thepattern of a bran h and p is the indu tive position of , then the required rewriterule is:[X ! Y p ! [Xp ! [Y pThe advantages of fa toring right-hand sides when the alternative symbol is anoperation are preserved by additional rewrite rules of this kind when the alterna-tive symbol is a onstru tor as well. However, when one of the new rewrite rules isapplied, additional storage is required for the representation of terms. Referringto the example under dis ussion, the representation of half (s X) ! half (s Y)takes more storage|exa tly three units for the top o urren e of the alternative onstru tor|than the representations of half (s X) and half (s Y) ombined.In general, it is not possible to say whether dening the alternative sym-bol as a onstru tor will in rease or de rease the storage used to represent theterms of a omputation. In some ase, the alternative symbol allows a more ompa t representation of some results of a omputation. For example, onsiderthe evaluation of:add (s 0) oin! s (add 0 oin)! s ( oin)! s (0 ! s 0)If the alternative symbol were not a onstru tor, the last term of the above omputation would reate two fair independent omputations. To omplete these omputations both additional steps would be exe uted and additional storagewould be needed for the exe ution of these steps.A onsequen e of dening the alternative symbol as a onstru tor is thatseveral alternative normal forms are represented by a single term. Therefore, itis likely inappropriate to adopt this programming te hnique to ode problemswhere only a small fra tion of the potentially omputed values of a omputationare a tually needed.5 ExamplesIn order to reason about the advantages and disadvantages of our te hniques,we analyze a few omputations using the ost riterion dis ussed in Se tion 3.As noted there, the theory that we use has previously been studied only for de-terministi omputations. In our simple examples, where the omputation spa eis nite, we adapt it to non-deterministi omputations as follows.Consider a omplete independent omputation for ea h non-deterministi step, and two independent omputations that dier for a non-deterministi re-pla ement. In our implementation [7, some fair independent omputations may

Page 64: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Improving the Efficiency of Non-Deterministics Computations 57share steps and terms. In these ases, our theory would predi t that the storageallo ated for all the omputations of a term is higher than it is a tually is.We onsider the omputations of positive (add bigger 0) with and withoutusing our rst te hnique. In the following tables, ea h line represents a stepof a omputation. We measure both the number of steps and the number ofappli ations of a omputation. The olumns of a table respe tively show the step ounter, the rewrite rule applied in the step, and the number of appli ations ofthe step. The result does not ontribute to the number of appli ations of the omputation be ause it is a onstant (a nullary symbol).Tables 13 show that when bigger is dened by two rewrite rules, the re-sour es spent to ompute positive (add bigger 0) are 6 steps and 16 units ofmemory. By ontrast, our rst te hnique uts the number of steps in half andredu es the memory onsumption by 25%. These exa t savings are also obtainedwith our se ond te hnique.Step Rule A1 bigger ! s 0 22 add (s X) Y ! s (add X Y) 53 positive (s -) ! true 0 Table 1. Computation when biggernon-deterministi ally rewrites to s 0.Total resour es: steps 3, memory units 7.Step Rule A1 bigger ! s (s 0) 42 add (s X) Y ! s (add X Y) 53 positive (s -) ! true 0 Table 2. Computation when biggernon-deterministi ally rewrites to s (s 0).Total resour es: steps 3, memory units 9.Step Rule A1 bigger ! s (0 ! s 0) 72 add (s X) Y ! s (add X Y) 53 positive (s -) ! true 0 Table 3. Computation when biggerrewrites to s (0 ! s 0) and \!" is an oper-ation.Total resour es: steps 3, memory units 12.A similar analysis for the omputation of half bigger shows that whenbigger is dened by two rules, the resour es spent by all the omputations are 5steps and 12 units of memory. By ontrast, using our se ond te hnique (i.e., whenbigger rewrites to s (0 ! s 0) and \!" is a onstru tor) the resour es used are 5steps and 27 units of memory: there is a 108% in rease in memory onsumption.The rst te hnique uses 6 steps and 19 units of memory, an in rease of 58%.On these examples, the implementation of [6 allo ates memory a ording toour theoreti al model. However, the above examples are too small and arti ialfor understanding the ee ts of our programming te hniques in pra ti e. Also,our theoreti al analysis is diÆ ult to apply to programs that make more than afew steps. For this reason, we ben hmark both the memory onsumption and theexe ution times of larger programs. Our programming language is Curry [10.The ompiler is PAKCS, whi h transforms Curry sour e ode into Prolog forexe ution.The rst program that we ben hmark is an implementation of the game of 24.Some of us rst en ountered this problem at a meeting of the Portland Extreme

Page 65: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

58 S. Antoy, P. Julian, B. MasseyProgramming User Group on June 5, 2001: it is inspired by a ommer ial gameintended to develop mathemati al skills in middle s hool students. The game isplayed as follows: given four 1-digit positive integers nd an arithmeti expressionin whi h ea h digit o urs exa tly on e and that evaluates to 24. A number anbe divided only by its fa tors. For example, a solution for the instan e [2; 3; 6; 8is (2+8) 3 6. There are 25 other distin t solutions of this instan e (in luding ommutatively and asso iatively equivalent solutions), in luding 3 (2 + 8) 6and 6 3 + (8 2).The program for this problem, shown in its entirety in the Appendix, pro eedsvia straightforward generate-and-test. Table 4 shows the CPU time (on a SunSPARCStation running Solaris) spent for omputing all the solutions of a fewproblems, and the global and lo al sta k allo ations for the omputation reportedby the Curry primitive evalSpa e. The rst group of data is for a version of theprogram that does not use our te hniques. The se ond group is for a programthat uses our rst te hnique, i.e., the alternative symbol is a dened operation.The se ond te hnique is not appropriate for this problem. The runtime measuresare nearly identi al over several exe utions. The memory measures are onstantfor every exe ution.The data shows that our te hnique onsumes slightly more memory, butspeeds the exe ution of the program by 44% on average. The speedups for variousproblems range from 27% to 58%. (The speedup a hieved by our te hnique is omputed by (t1 t2)=t1 where t1 and t2 are the averages of the exe ution timesof the programs not using and using the te hnique respe tively. This speedupindi ates the per entage of exe ution time saved by the te hnique.)Table 4. Runtime (mse .) and memory usage (bytes) for \24" instan es.regular program rst te hniqueproblem Runtime G. sta k L. sta k Runtime G. sta k L. sta k Speedup[2,3,6,8 66 2596 932 48 2800 1100 27%[2,3,4,9 94 2632 860 52 2836 972 45%[3,4,5,8 65 2476 868 27 2680 1036 58%[1,2,6,8 64 2812 868 36 2816 980 44%[4,6,8,9 38 2416 832 19 2620 1000 50%Average 65 2586 872 36 2750 1017 44%Our se ond example is a parser that takes a string representing a parenthe-sized arithmeti expression and returns a parse tree of the input. Our implemen-tation is simplied to the extreme and serves only as a proof of on ept. Theabstra t syntax generated by the parser is dened by the type:data AST = Num String | Bin Char AST ASTFor example, on input "1+(2-3)" the parser generatesBin'+'(Num"1")(Bin'-'(Num"2")(Num"3")):

Page 66: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Improving the Efficiency of Non-Deterministics Computations 59Repla ing the argument of Num with an integer and the Bin Char ombinationwith a token would be more appropriate, but it would add to the program detailsthat are irrelevant to our analysis. The language re ognized by the parser isgenerated by the following grammar:expression ::= term `+' expressionj term `-' expressionj termterm ::= `(' expression `)'j digitsSequen es of digits are re ognized by a s anner.The parser is implemented using two dened operations: expression and term.The type of both operations is [Char ! [Char ! AST. For all strings s andr, expression s r evaluates to a if and only if there exists a string u su h thats = u r and a is the parse tree of u. Operation term is analogous. For example,term "1+(2-3)" "+(2-3)" evaluates to Num"1". To parse an entire string,operation expression is initially alled with its se ond argument equal to theempty string. In re ursive alls, the se ond argument is a free variable.Table 5 shows exe ution time and memory usage on a 233MHz Pentium PCrunning Linux. In this program, too, the data show that our rst te hnique on-sumes more memory, but substantially uts the exe ution time to parse ertainstrings. The speedup is highly dependent on the stru ture of the input string.Table 5. Runtime (mse .) and memory usage (bytes) while parsing.regular program rst te hniqueinput Runtm G. st k L. st k Runtm G. st k L. st k Speedup"1+1+1+1+1+1+1+1" 10 12528 736 10 16152 1012 0%"((((((0))))))" 1440 2676 8 5 6992 568 99%"5-((2+1)+3+(5-4))" 60 10468 528 10 15240 1144 83%Average 500 8557 424 8 12795 908 98%6 Con lusionsNon-deterministi omputations are an essential feature of fun tional logi pro-gramming languages. Often, a non-deterministi omputation is implemented asa set of fair independent omputations whose results are used, and possibly dis- arded, by a ontext. A non-deterministi omputation an be ostly to exe ute:any reasonable attempt to improve its eÆ ien y is worthwhile.In this paper, we have proposed two simple programming te hniques intendedto improve the eÆ ien y of ertain non-deterministi omputations. Both te h-niques are based on the introdu tion of a new symbol, alled alternative, intothe signature of a program. In one te hnique, the alternative symbol is a poly-morphi dened operation. In the other te hnique, the alternative symbol is

Page 67: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

60 S. Antoy, P. Julian, B. Masseyan overloaded onstru tor. This symbol allows a program to fa tor a ommonportion of the non-deterministi repla ements of a redex.Either te hnique may improve the eÆ ien y of a omputation by redu ing thenumber of omputation steps or the memory used in representing terms. Thesesavings are obtained in two situations. For both te hniques, savings are obtainedwhen fair independent omputations are avoided be ause only the fa tored por-tion of non-deterministi repla ements is needed. For the se ond te hnique, sav-ings are obtained when distin t non-deterministi results are more ompa tlyrepresented by sharing a ommon fa tor. In some ases, the improvements of-fered by these te hniques are substantial. In all ases, the ost of applying therst te hnique is small. There are ases in whi h the appli ation of the se ondte hnique may a tually result in omputations that onsume more memory.We have dis ussed how to apply our te hniques, and we have quantied theee ts of the appli ation of these te hniques in simple examples. Our te hniquesare appli able to programs oded in many existing or proposed fun tional logi programming languages. Our te hniques an be dire tly adopted by program-mers or an be introdu ed into a program automati ally at ompile time.Referen es1. A.V. Aho, R. Sethi, and J.D. Ullman. Compilers: Prin iples, Te hniques and Tools.Addison-Wesley, 1985.2. E. Albert, S. Antoy, and G. Vidal. Measuring the ee tiveness of partial evalua-tion in fun tional logi languages. In Pro . of 10th Int'l Workshop on Logi -basedProgram Synthesis and Transformation (LOPSTR'2000), pages 103124. SpringerLNCS 2042, 2001.3. S. Antoy. Denitional trees. In Pro . of the 3rd International Conferen e onAlgebrai and Logi Programming (ALP'92), pages 143157. Springer LNCS 632,1992.4. S. Antoy. Optimal non-deterministi fun tional logi omputations. In Pro . Inter-national Conferen e on Algebrai and Logi Programming (ALP'97), pages 1630.Springer LNCS 1298, 1997.5. S. Antoy. Constru tor-based onditional narrowing. In Pro . of 3rd Int'l Conf. onPrin iples and Pra ti e of De larative Programming (PPDP'01). Springer LNCS,2001. To appear.6. S. Antoy and M. Hanus. Compiling multi-paradigm de larative programs into pro-log. In Pro . of the 3rd International Workshop on Frontiers of Combining Systems(FroCoS 2000), pages 171185, Nan y, Fran e, Mar h 2000. Springer LNCS 1794.7. S. Antoy, M. Hanus, B. Massey, and F. Steiner. An implementation of narrowingstrategies. In Pro . of 3rd Int'l Conf. on Prin iples and Pra ti e of De larativeProgramming (PPDP'01). Springer LNCS, 2001. To appear.8. J.C. Gonzalez-Moreno, M.T. Hortala-Gonzalez, F.J. Lopez-Fraguas, andM. Rodrguez-Artalejo. A rewriting logi for de larative programming. In Pro .ESOP'96, pages 156172. Springer LNCS 1058, 1996.9. J.C. Gonzalez-Moreno, F.J. Lopez-Fraguas, M.T. Hortala-Gonzalez, andM. Rodrguez-Artalejo. An approa h to de larative programming based on arewriting logi . The Journal of Logi Programming, 40:4787, 1999.10. M. Hanus (ed.). Curry: An Integrated Fun tional Logi Language (Version0.71). Web do ument http://www.informatik.uni-kiel.de/~mh/ urry/report.html (a essed Jul 10, 2001 04:07 UTC), 2000.

Page 68: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Improving the Efficiency of Non-Deterministics Computations 61AppendixThe Game of 24This program solves the game of 24.infixr 5 +++(+++) eval flex[ +++ x = x(x:xs) +++ y = x:xs +++ ypermute [ = [permute (x:xs) | u+++v =:= permute xs = u++[x++v where u,v freedata exp = num Int| add exp exp| mul exp exp| sub exp exp| dvv exp expgenerate [y = num ygenerate (y:y1:ys)| (y:y1:ys) =:= u:us+++v:vs= add (generate (u:us)) (generate (v:vs)) where u,us,v,vs freegenerate (y:y1:ys)| (y:y1:ys) =:= u:us+++v:vs= mul (generate (u:us)) (generate (v:vs)) where u,us,v,vs freegenerate (y:y1:ys)| (y:y1:ys) =:= u:us+++v:vs= sub (generate (u:us)) (generate (v:vs)) where u,us,v,vs freegenerate (y:y1:ys)| (y:y1:ys) =:= u:us+++v:vs= dvv (generate (u:us)) (generate (v:vs)) where u,us,v,vs freetest (num y) = ytest (add x y) = test x + test ytest (mul x y) = test x * test ytest (sub x y) = test x - test ytest (dvv x y) = opdvv (test x) (test y)where opdvv x y = if y == 0 || not (x `mod` y == 0)then failed else x `div` ysolve p | test x == 24 = x where x = generate (permute p)-- example: solve [2,3,6,8The appli ation of our te hnique alls for the denition of the alternativefun tion and the repla ement of operation generate.infixl 0 !x ! _ = x_ ! y = y

Page 69: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

62 S. Antoy, P. Julian, B. Masseygenerate [y = num ygenerate (y:y1:ys)| (y:y1:ys) =:= u:us+++v:vs= (add ! mul ! sub ! dvv) (generate (u:us)) (generate (v:vs))where u,us,v,vs freeThe ParserThis is a parser for parenthesized arithmeti expressions.--import Chardata AST = Num String | Bin Char AST ASTexpression X0 X3| A1 =:= term X0 X1 &>'+':X2 =:= X1 &>A2 =:= expression X2 X3= Bin '+' A1 A2 where X1, X2, A1, A2 freeexpression X0 X3| A1 =:= term X0 X1 &>'-':X2 =:= X1 &>A2 =:= expression X2 X3= Bin '-' A1 A2 where X1, X2, A1, A2 freeexpression X0 X1 = term X0 X1term X0 X2| X:X1 =:= takeWhile isDigit X0 &> X0 =:= X:X1 ++ X2= Num (X:X1)| X0 =:= '(':Y0= expression Y0 (')':X2)where Y0, X, X1 free-- example: expression "1+(2-3)" ""The appli ation of our te hnique alls for the denition of the alternativefun tion, as in the previous program, and the repla ement of operation expressionwith the following ode.expression X0 X3| A1 =:= term X0 X1 &>( ( OP:X2 =:= X1 &>OP =:= ('+'!'-') &>A2 =:= expression X2 X3 &>TREE =:= Bin OP A1 A2 )! (X3 =:= X1 &> TREE =:= A1))= TREE where OP, X1, X2, A1, A2, TREE free

Page 70: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Dynamic Programming of Partial Parses

David Cabrero Souto2, Jesus Vilares Ferro1, and Manuel Vilares Ferro1

1 Universidad de A CorunaDepartamento de Computacion

Campus de Elvina s/n, 15071 A Coruna, [email protected], [email protected]

2 Universidad de VigoArea de Ciencias de la Computacion e Inteligencia Artificial

Edificio Politecnico32004 Ourense, Spain

[email protected]

Abstract. The last years have seen a renewal of interest in applying dynamicprogramming to natural language processing. The main advantage is the com-pactness of the representations, which is turning this paradigm into a commonway of dealing with highly redundant computations related to phenomena suchas non-determinism.Natural language parsing adds another challenge, since grammatical informationis often insufficient. We describe an extension of parsing techniques for partialparsing in dynamic programming. Our aim is to obtain as much information aspossible, that is incomplete parses, while preserving compactness of the repre-sentations.Keywords:Partial parsing, dynamic programming, deductive parsing scheme.

1 Introduction

Highly redundant computations are usual when we deal with complex grammar for-malisms. This claim has been used to motivate parsing techniques that encode trees andcomputations in some kind of shared structure. A major area of application is naturallanguage processing (NLP), where dynamic programming has been known for a longtime [3]. In particular, natural language parsing comes across the problem of partialinformation. This lack of information is due to the errors informer stages of analysisand the fact that practical grammars and lexicons are incomplete and even incorrect.

We refer to standard parsing ascomplete parsing, reserving the termpartial parsingfor all the possible subcomputations of a complete parsing.Our aim is to obtain everycorrect partial parse even when there is no complete parse.

Previous studies have illustrated the practical suitability of dynamic programmingfor dealing with context-free grammars (CFGs) [11], middle-sensitive grammars [1]and definite clause grammars [10]. Our goal is to show the validity of these results forpartial parsing. We approach the problem by extending models from complete to partialparsing while preserving the related benefits of dynamic programming.

Often, these techniques improve performance by pruning thesearch space by meansof the inclusion of static control. Unfortunately, while dealing with partial parses, the

Page 71: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

64 D. Cabrero, J. Vilares, M. Vilaresstatic control will prune some analysis branches that are useless in a complete parse, butwhich are necessary in some partial parses. To overcome thisproblem we deal with thestarting and finishing points of a partial parse like any other source of non determinism.The static control is modified to take them into account.

In contrast to previous works in the domain of partial parsing, our proposal intro-duces a parsing framework based on the notion of deduction scheme [7]. This clearlydifferentiates our work from approaches oriented to particular parsing architectures [5,9, 6], and provides a uniform description and operational formalism to validate the per-formance in each case.

In Section 2 of this paper we introduce a uniform parsing framework, describingdifferent schema for both complete and partial parsing. These schema include classictop-down and bottom-up approaches, but also mixed strategies with dynamic and staticcontrol. Section 3 gives a survey of the dynamic interpretation process. In Section 4we compare in practice the schema introduced, with preliminary experimental results.Finally, Section 5 is a conclusion about the work presented.

a b a b a ba

Fig. 1. Partial parses ofaababab

2 On partial parsing

In order to obtain a practical definition of partial parsing,we must relax the conditionswe apply to the standard concept. The notion of grammar includes an initial symbolor axiom,S, leading to the parse of all sentences of the language generated by thegrammar. Instead of this, we use a set of initial symbols,S, following theentry pointconcept [4], a classic auxiliary structure in the abstract syntax that enables the parsingof program fragments. We introduce a CFG as a 4-tupleG = (N, Σ, P,S), whereN

is a finite set of non-terminal categories,Σ is a finite alphabet andP is a finite set ofcontext-free rules. As mentioned,S is the set of initial symbols leading to completeor partial parses. We assumeL(G) to be the language generated byG, and we try todetermine the partial parses of an input stringw1..n, of lengthn.

In particular, we discuss the extension to the partial case of classical context-freeparsing methods including pure top-down and pure bottom-uparchitectures, Earley’salgorithm [3] as representative of a mixed-strategy with dynamic prediction and aLR(1)proposal as representative of a mixed-strategy with staticprediction.

For the sake of a better exposition we have chosen a common descriptive frame-work, the deductive parsing scheme [7], close to the parsingschemata proposal [8].

Page 72: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Dynami Programming of Partial Parses 65The deduction system consists of a set ofitemsrepresenting parsing states and a set ofdeduction steps performing over those items.

As our running example we shall consider the language,P , of palindromes over thealphabetΣ = a, b, generated by the grammar that follows:

Palin → a Palin → b

Palin → a Palin a Palin → b Palin b

Observe, for example, that although the input string isaababab 6∈ P , it contains sub-strings that do belong to the language, as is the case of the trees in Fig. 1.

2.1 A top-down scheme

The scheme for top-down complete parsing is shown in Fig. 2. We have a singleaxiomthat predicts the analysis of the initial symbol, and a singlegoalthat represents the parseof the complete input sentence. Now we will make a short description of the scheme.Each item has the form:[•β, j, (T )], stating that we have constructed the derivationS

∗⇒ w1 · · ·wjβ, andT is the parse tree. The dot is a reference to positionj in the input

string. The parse has reached this position and has to continue from there. Soundnessand correctness are proved in [7].

Item form [•β, j, T ]

Invariant S∗

⇒ w1 · · ·wjβ

Axioms [•S, 0, ()]

Goals [•, n, T ]

Scanning[•wj+1β, j, T1tree(B, α • wj+1β)T2][•β, j + 1, T1tree(B, αwj+1 • β)T2)]

Prediction[•Bβ, j, T1tree(A, α • BβT2)]

[•γβ, j, T1tree(A, αtree(B, •γ)β)T2]〈rk : B → γ ∈ R〉

Fig. 2. Top-down schema

The parse starts at position 0 and symbolS, yielding axiom item[•S, 0, ()]. We thenapply the following deduction steps:

Scanning: It moves the point one position forward. This rule is obtained after observ-ing that items[•wj+1β, j, (T )] and[•β, j + 1, (Twj+1)] represent the same statein the derivationS

∗⇒ w1 · · ·wj+1β.

Prediction: It takes the next non terminal symbol to parse (B) and rewrites it as theright hand side of a matching rule (rk : B → γ). It predicts the use of the rulerk.

Page 73: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

66 D. Cabrero, J. Vilares, M. VilaresItem form [α•, j, T ]

Invariant αwj+1 · · ·wn∗

⇒ w1 · · ·wn

Axioms [•, 0, ()]

Goals [S•, n, T ]

Scanning[α•, j, T ]

[αwj+1•, j + 1, Twj+1]

Completion[αγ•, j, T1T2]

[αB•, j, T1tree(B,T2)]

rk : B → γ ∈ R,

‖γ‖ = ‖T2‖

Fig. 3. Bottom-up schema

Finally, w ∈ L(G) iff the goal item [•, n, (T )] is generated. This means thatS∗⇒

w1 · · ·wn, andT is the parse tree.In order to adapt this scheme for partial parsing, we consider a modified item form,

adding a reference to the starting position of the potentially partial parse. A partial parsecovers any piece of the input string. So, instead of an axiom item starting at position 0,we have now the following set of axioms:

Axioms= [•A, i, i, ()], A ∈ S, 0 ≤ i < n

The deductive steps remain as before, but keeping the starting point. As a partial parsemay cover any piece of the input string, it may start at any position, and it may finish atany position after the starting point. As consequence, we have that:

Goals= [•, i, j, T ], A ∈ S, 0 ≤ i ≤ j ≤ n

We shall generatem × n axioms, wherem = ‖S‖ andn is the input length. For eachof those axioms we will generate a new analysis branch, and, consequently, new items.In our running grammar, for an input stringaaba and a complete top-down parse, weneed to create30 items, instead of82 in the partial case.

2.2 A bottom-up scheme

We include in Fig. 3 the scheme for bottom-up complete parsing. Items are now of theform [α•, j, (T )], stating thatαwj+1 · · ·wn

∗⇒ w1 · · ·wn, T being the parse tree. The

dot indicates thatα reduces the input substring till positionj.Bottom-up parsing starts at position0 before reducing any piece of the input string.

Therefore the axiom is[•, 0, ()]. The deduction steps are:

Scanning: It shifts the next terminal and moves the dot one position forward.Completion: It reduces thekn symbols immediately after the dot. Those symbols must

match the right hand side of rulerk.

Page 74: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Dynami Programming of Partial Parses 67As usual,w ∈ L(G) iff the goal item[S•, n, (T )] is generated. This means thatS

∗⇒

w1 · · ·wn, whereT is the parse tree.In order to deal with partial parsing, items are extended with a reference to the

starting position. Regarding axioms, a partial parse may start at any position in theinput string. So, we have that:

Axioms= [•, i, i, ()], 0 ≤ i < n

In deduction steps we keep the starting position. Again, thegoal item is replaced by aset of items. To construct this set we must have taken into account that a partial parsemay finish at any symbol ofS, at any input position. So, we have that:

Goals= [A•, i, j, T ], A ∈ S, 0 ≤ i ≤ j ≤ n

As far as efficiency issues are concerned, the main difference with complete parsing isthe set of axioms. The size of this set isn, n being the length of the input. Retaking theformer example, this yields29 items for complete parsing and54 for partial parsing.

Item form [A → α • β, i, j, T ], A → αβ ∈ R

Invariant S∗

⇒ w1 · · ·wjβ

αwj+1 · · ·wn∗

⇒ w1 · · ·wn

Axioms [S′ → •S, 0, 0, ()]

Goals [S′ → S•, 0, n, T ]

Scanning[A → α • wj+1β, i, j, T ]

[A → αwj+1 • β, i, j + 1, Twj+1]

Prediction[A → α • Bβ, i, j, T ]

[B → •γ, j, j, ()]〈rk : B → γ ∈ R〉

Completion[A → α • Bβ, i, k, T1][B → γ•, k, j, T2]

[A → αB • β, i, j, T1tree(B, T2)]

Fig. 4.Earley’s scheme

2.3 Earley’s scheme

Earley’s algorithm [3] will illustrate the extension from complete to partial parsing us-ing a mixed-strategy with dynamic prediction. The completeparsing scheme is shownin Fig. 4.

We have now items of the form[A → α • β, i, j, T ]. The dot is still a referenceto positionj, but now the item represents the state in recognizing the rule A → αβ,whereα reduces some of the substring just before the dot andβ remains to be parsed.In relation toi, it points to the begining of the substring parsed byα. Consequently

Page 75: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

68 D. Cabrero, J. Vilares, M. Vilaresitems represent a local state of parsing process instead of aglobal one. Having localinformation enclosed makes it easier to share computationsamong items.

The grammar is augmented with an artificial ruleS′ → S, whereS′ is a distinctsymbol. This facilitates the definition for axioms and goals. The parse starts with theaxiom [S′ → •S, 0, 0, ()], at position0 we want to reduce the initial symbolS. Thededuction steps are as follows:

Scanning: After recognition of terminalwj+1, it moves the pointer from positionj toj + 1.

Prediction: It predicts all the rulesB → γ, because they may reduceB from positionj.

Completion: After we finish the parse of a ruleB → γ, from positionk to j, it searchesfor items whose next symbol to analyze isB at positionk. For those items it gen-erates a new one by moving the dot to just afterB, positionj.

Once we generate the goal item[S′ → S•, 0, n, T ], we knoww0...n reduces to theinitial symbolS, andw ∈ L(G).

We need to modify axioms and goal items in order to deal with partial parses. Ax-ioms start with any initial symbol inS at any position:

Axioms= [S′ → •A, i, i, ()], A ∈ S, 0 ≤ i < n

and goals finish at any position after the starting point:

Goals= [S′ → A•, i, j, T ], A ∈ S, 0 ≤ i ≤ j ≤ n

The comparison between complete and partial parsing is similar to that we made forthe top-down scheme, the number of axioms growing from one ton×m, wheren is theinput string length andm = ‖S‖. So, returning to our running grammar, this incrementmeans that we need35 items for a complete parse and52 for a partial one.

2.4 A mixed-strategy with static control

We introduce now the complete parsing scheme for anLR(0) based parse. A prelimi-nary description of the deductive interpretation, where wehave omitted the finite statecontrol in order to make the differences with Earley’s scheme clear, is shown in Fig. 5.This difference is rooted in the meaning of the items. In Earley’s case, the sequence ofsymbolsα, immediately to the left of the dot, reduce the substringwi...j. In LR(0), onlythe symbolX (α = α′X) immediately on the left of the dot reduces the substring. Asaconsequence, we need different deduction steps to manage different items:

Shift: It is similar to scanningin Earley’s case. The starting position reflects the lastsymbol analyzed,wj .

Reduce: It replaces thecompletionstep of Earley. In Earley’s scheme, we need an item[B → X1 · · ·Xm•, j0, jm, Tm] that reflects the recognition ofB → X1 · · ·Xm

between positionsj0 andjm.In LR(0) we needm items of the form[B → X1 . . . Xi . . . Xm, ji−1, ji, Ti]. Eachitem reflects the recognition of them symbols of the right hand side of the rule atadjacent positions betweenj0 andjm.

Page 76: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Dynami Programming of Partial Parses 69Item form [A → α • β, i, j, T ]

A → αβ ∈ R,

0 ≤ i ≤ j ≤ n

Invariant S∗

⇒ w1 · · ·wiXβ

X∗

⇒ wi+1 · · ·wj

α = α′X, ∃k, k ≤ i, α′ ∗

⇒ wk+1 · · ·wi

Axiom [S → •α, 0, 0, ()]

Goal [S → α•, 0, n, T ]

Shift[A → α • wjβ, i, j, T ]

[A → αwj • β, j, j + 1, wj ]

Prediction[A → α • Bβ, i, j, T ]

[B → •γ, j, j, ()]

Reduce

[B → X1X2 · · ·Xm•, jm−1, jm, Tm],. . . ,

[B → •X1X2 · · ·Xm, j0, j1, ()],[A → α • Bβ, i, j0, T0]

[A → αB • β, j0, jm, tree(B, T1 . . . Tm)]

Fig. 5. LR(0) scheme, omitting finite control

Prediction: The same as Earley’s scheme.

Next, we will get a more efficient scheme adding a finite state control. This impliesreplacing dotted rulesA → α •β by an state,st, representative of its equivalence class.In order to build the finite state control, we initst0 = [S → •α]. Then we build theother states with the closure of their items[A → α • Bβ]. More precisely, the closureoperation adds items[B → •γ] for each ruleB → γ. The closure is in fact equivalent tothepredictionstep. So, it will be removed from the LR parsing scheme with finite statecontrol, as shown in Fig. 6. Here,action(state, token)denotes a shift or reduce action inthe automaton for a givenstateandtoken. In the same way,goto(state, variable)looksfor a goto action. Finally,reveals(state)refers to all those states with a shift or gotoaction overstate.

To extend the scheme to partial parsing, it must be allowed tostart the parsing atany point of the input string, with any symbol ofS:

Axioms= [st0, i, i, ()], 0 ≤ i ≤ n]

and, to finish at any position after the starting point:

Goals= [stf , i, j, T ], 0 ≤ i ≤ j ≤ n]

We need to change the initialization step when building the finite state control. So,instead ofst0 = [S → •α], the first state must best0 = [A → •α] | A ∈ S.

We can improve the LR(0) parsers with a better finite state control. Now, whenbuilding the states, we must add information about which lookahead symbols are com-platible with their actions. This control could result in anLR(1) or LALR(1) parsing

Page 77: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

70 D. Cabrero, J. Vilares, M. VilaresItem form [st, i, j, T ]

Axiom [st0, 0, 0, ()]

Goal [stf , 0, n, T ]

Shift[st, i, j, T ]

[st′, j, j + 1, wj ]〈shiftst′ ∈ action(st, wj)〉

Reduce

[stm, jm−1, jm, Tm],. . . ,

[st1, j0, j1, ()],[st0, i, j0, T0]

[st, j0, jm, tree(r,T1 . . . Tm)]

reducer ∈ action(stm, wj),sti ∈ reveals(sti+1),st ∈ goto(st0, lhs(r)),m = length(rhs(r))

Fig. 6. LR(0) schema

Item form [st, b, i, j, T ]

Axiom [st0, $, 0, 0, ()]

Goal [stf , $, 0, n, T ]

Shift[st, b, i, j, T ]

[st′, b, j, j + 1, wj ]〈shiftst′ ∈ action(st,wj)〉

Reduce

[stm, b′, jm−1, jm, Tm],. . . ,

[st1, b′, j0, j1, ()],

[st0, b, i, j0, T0]

[st, b, j0, jm, tree(r, T1 . . . Tm)]

reducer ∈ action(stm, wjm ),sti ∈ reveals(sti+1),st ∈ goto(st0, lhs(r)),m = length(rhs(r))

Fig. 7. LALR (1) schema

algoritm, depending on the computation of the lookahead symbols. Next, in order toadapt the LR(0) scheme to use the LALR(1) control, we will addpreconditions to de-ductive steps. The preconditions will check that the lookahead is compatible with theoperation. The resulting scheme is shown in Fig. 7.

Actually action andgoto are the core the table of the LALR(1) automaton. Thistable changes for an LR(1) automaton, but its interpretation remains the same. As aconsecuence, we can use the same parsing schema for LALR(1) and LR(1), provindingwe change the finite state control.

Once again, the extension to partial parsing implies addingaxioms and goals, butwith one new consideration. Because a partial parse may finish at any input position,the finishing operation is compatible with any terminal, andnot only with the end of theinput terminal. So, we have that the set of axioms is

Axioms= [st0, , i, i, ()], 0 ≤ i ≤ n, A ∈ S

Page 78: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Dynami Programming of Partial Parses 71and the set of goals is

Goals= [stj, , i, j, T ], 0 ≤ i ≤ j ≤ n, A ∈ S

To build now the finite state control, we need the concept of avariable terminal thatmatches any terminal of the grammar. This may produce an exponential growth of thenumber of states. To mimic the intended behavior without modifying the set of states wemake the input string ambiguous. At each position, we have both the original terminal,wi, and the end of the input. The former is compatible with any operation that followsthe parsing process and the latter is compatible with finishing a parse which is probablypartial.

In our running example, the complete LR(0) scheme needs35 items, while the par-tial one needs52. The LALR(1) schema need, respectively,32 and42 items.

Item form [A, st, i, j, T ] ∪ [∇r,s, st, i, j, T ]

Axiom [−, st0, 0, 0, ()]

Goal [S′, stf , 0, n, T ]

InitShift[A, st, i, j, T ]

[Ar,1, st′

, j, j + 1, wj ]

Ar,1 = wj∧shiftst′ ∈ action(st,wj)

Shift[Ar,s, st, i, j, T ]

[Ar,s+1, st′

, j, j + 1, wj ]

Ar,s+1 = wj∧shiftst′ ∈ action(st,wj)

Sel[Ar,n, st, i, j, T ][∇r,n, st, j, j, ()]

〈reducer ∈ action(st, wj)〉

Red[∇r,s, st, k, j, T1] [Ar,s, st, i, k, T2]

[∇r,s−1, st′

, i, j, T2T1]〈st′ ∈ reveals(st)〉

Head[∇r,0, st, i, j, T ]

[Ar,0, st′

, i, j, tree(Ar,0, T )]〈st′ ∈ goto(st, Ar,0)〉

Fig. 8. LALR (1) scheme with implicit binarization

3 The dynamic interpretation

Given that actions on the automaton depend on the first, and possibly the second, el-ements in the stack, we implicitly consider a grammar which is a 2-form one. As aconsequence, we obtain two interesting features that are not usual in other context-freeparsing algorithms:

– Time complexity for the parser isO(n3), wheren is the length of the sentence. Thisresult is achieved without the need for the language grammarto be in ChomskyNormal Form.

Page 79: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

72 D. Cabrero, J. Vilares, M. Vilares– Sharing of computations on the parsing of a tail of sons in a node is possible. More

exactly, bottom-up parsing may share only the rightmost constituents, while top-down parsing may only share the leftmost ones. The reason is simple and relies tothe type of search used to built the forest. Breadth-first search results in bottom-up constructions and depth-first search results in top-downones, as is shown infigure 9.

n1RULE : γ1Φ α β δ ρn2RULE : γ2Φ α β δ ρ

γ1 γ2

Φ

α β δ ρ α β δ ρ

Classic forest representation without sharing.

Shared nodes using a top-down parser, with AND-OR graphs.

Shared nodes using a bottom-up parser, with AND-OR graphs.

AND-OR representation with sharing,for a top-down parsing.

n1

γ2 n2

γ1

nil

nil

nil

α β δ ρ

α β δ ρ

Φ

AND-OR representation with sharing,for a bottom-up parsing.

γ2

γ1

n2

n1

δ ρ

α β

α β

δ ρ

nil

nil

Φ nil

Fig. 9. Sharing of a tail of sons in a node

In order to obtainO(n3) complexity in the general case, we can use a implicitbinarization of rules. We do this by splitting each reduction involving m elements inthe reduction ofm + 1 rules with at most2 elements on their right-hand side. Thus, thereduction of a ruleAr,0 → Ar,1 · · ·Ar,nr

is equivalently performed as the reduction ofthe followingnr + 1 rules:

Ar,0 → ∇r,0 ∇r,0 → Ar,1∇r,1

......

∇r,nr−1 → Ar,nr∇r,nr

∇r,nr→ ǫ

This treatment of reductions involves a change in the form ofthe items. We add a new el-ement, representing a symbol in a rule or a∇r,i meaning that elementsAr,i+1 . . . Ar,nr

have been reduced1.With respect to deduction steps, we must now differentiate between whether we

make the shift of the first symbol in the right hand side of a rule (InitShift) or the shiftof other symbols (Shift).

TheReducestep has also been refined into three steps. Theselectionof the rule tobe reduced (Sel), thereductionof the implicit binary rules (Red), and therecognizingofthe left-hand symbol of the rule to be reduced (Head). The resulting scheme is shownin Fig. 8. This scheme corresponds to a dynamic interpretation of LALR(1) parsingalgorithms using an inference system based onS1 items [2].

1 ∇r,i is equivalent to the dotted ruleAr,0 → αβ where α = Ar,1 . . . Ar,i and β =Ar,i+1 . . . Ar,nr .

Page 80: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Dynami Programming of Partial Parses 73The extension for partial parsing is analogous to previous schema, following an

identical approach for table construction, and adding new axioms and goals. So, the setof axioms is given by:

Axioms= [st0, , i, i, ()], 0 ≤ i ≤ n, A ∈ S

and the set of goals by:

Goals= [stj, , i, j, T ], 0 ≤ i ≤ j ≤ n, A ∈ S

1

10

100

1000

10000

100000

1e+06

2 4 6 8 10 12 14 16 18 20

Num

ber

of

item

s

Input length

Bottom-upTop Down

EarleyDynamic LALR(1)

Fig. 10.Num. of items in complete parsing

4 Experimental results

To illustrate the practical aspects of our proposal, we provide now some preliminary ex-perimental results. We have parsed several input strings with lengths varying from 1 to20, considering our running example, the languageP . The number of items is differenteven for input strings of the same length. So, for each lengthwe have parsed severalinput strings, computing the average number of items generated, both for complete andpartial parsing. The grammar we are using seems to be well-suited for top-down pars-ing, as shown in Fig. 10. Bottom-up parsing only performs well for short length inputs.On the other hand, dynamic programming approaches, both Earley parsing and dynamicinterpretation of LALR(1), perform as well as top-down parsing.

Page 81: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

74 D. Cabrero, J. Vilares, M. Vilares

1

10

100

1000

10000

100000

2 4 6 8 10 12 14 16 18 20

Num

ber

of

item

s

Input length

Bottom-upTop Down

EarleyDynamic LALR(1)

Fig. 11.Num. of items in partial parsing

Regarding partial parsing, Fig. 11, top-down parsing suffers a drop in performance,while bottom-up still performs well for short length inputs. Dynamic programming ap-proaches continue to show a good behavior.

In Fig. 12 we illustrate the relation between complete and partial parsing, synthe-sizing the last two figures. We have replaced the number of generated items by theincrement from the number of items in complete parsing to thenumber of items in par-tial parsing. As is shown, top-down partial parsing is not asadvantageous as it was forcomplete parsing. It suffers from exponential grown. On theother hand, the parsingschema with some kind of bottom-up strategy scale well.

5 Conclusions

We have described a practical approach to partial parsing inthe domain of CFGs. Incomparison with previous works, our proposal is based on a deductive parsing scheme,which provides a uniform framework to compare performancesbetween different pars-ing strategies for both complete and partial cases.

From a theoretical point of view, we have graduated the introduction of each pars-ing scheme in order to make clear the existing relationshipswith previous strategies.This leads to a better understanding of the mechanisms regulating the definition of thededuction rules and even of the structures manipulated by these. The evolution fromcomplete parses to partial ones is also justified in each case.

Page 82: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Dynami Programming of Partial Parses 75

100

200

300

400

500

600

700

800

900

1000

2 4 6 8 10 12 14 16 18 20

Rat

io (

%)

Input length

Top DownBottom Up

EarleyDynamic LALR(1)

Fig. 12.Ratio partial/complete parsing

6 Acknowledgments

This work has been partially supported by the European Union, Government of Spainand Autonomous Government of Galicia under projects 1FD97-0047-C04-02,TIC2000-0370-C02-01 and PGIDT99XI10502B, respectively.

The source code of the deduction scheme interpreter comes from the original oneof [7], and has been adapted by V.J. Dıaz Madrigal.

References

1. M.A. Alonso, D. Cabrero, E. de la Clergerie, and M. Vilares. Tabular algorithms for TAGparsing. InProc. of EACL’99, Ninth Conference of the European Chapter of the Associationfor Computational Linguistics, pages 150–157, Bergen, Norway, June 1999. ACL.

2. E. de la Clergerie.Automates a Piles et Programmation Dynamique. PhD thesis, Universityof Paris VII, France, 1993.

3. J. Earley. An efficient context-free parsing algorithm.Communications of the ACM,13(2):94–102, 1970.

4. I. Jacobs.TheCENTAUR 1.2 Manual. INRIA, Sophia-Antipolis, France, 1992.5. Christian Jacquemin. Receycling terms into a partial parser. InProc. of the 4th Conf. on

Applied Natural Language Processing. Stuttgart, DE, 13–15Oct 1994, pages 113–118, 1994.6. V. Rocio and J. G. Lopes. Partial parsing, deduction and tabling. In Proceedings of Tabula-

tion in Parsing and Deduction (TAPD’98), pages 52–61, Paris (FRANCE), April 1998.7. S.M. Shieber, Y. Schabes, and F.C.N. Pereira. Principlesand implementation of deductive

parsing.Journal of Logic Programming, 24(1-2):3–36, 1995.

Page 83: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

76 D. Cabrero, J. Vilares, M. Vilares8. K. Sikkel. Parsing Schemata. PhD thesis, University of Twente, The Netherlands, 1993.9. Michael Sperber and Peter Thiemann. The essence of LR parsing. InProceedings of the ACM

SIGPLAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation,pages 146–155, La Jolla, California, 21-23 June 1995.

10. M. Vilares and M.A. Alonso. An LALR extension for DCGs in dynamic programming.In Carlos Martın Vide, editor,Mathematical and Computational Analysis of Natural Lan-guage, volume 45 ofStudies in Functional and Structural Linguistics, pages 267–278. JohnBenjamins Publishing Company, Amsterdam & Philadelphia, 1998.

11. M. Vilares and B.A. Dion. Efficient incremental parsing for context-free languages. InProc. of the5th IEEE International Conference on Computer Languages, pages 241–252,Toulouse, France, 1994.

Page 84: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Applying Frameworks and Object-Oriented

Techniques for developing Language Processors Tools

M. Cándida Luengo, Juan M. Cueva, Jose E. Labra, Néstor García, David Basanta

Languages and Computer Systems Area

Department of Computer Science

University of Oviedo

Calvo Sotelo s/n

33007-OVIEDO (SPAIN)candi,labra,nestor,[email protected]

Abstract. While the most traditional applications for language

processors are the development of compilers and interpreters, they can

also be found in the XML parsers of most e-commerce systems, editors

with syntax highlighting like those used by programmers, analyzers of

complex configuration files like those of Sendmail or Apache, grammar

checkers like those present in word processing applications or in

component-based development environments, where small scripting

languages are used to glue components together. Compiler construction

tools have proven to be very useful for developers. In contrast to their

importance, traditional tools have failed to take advantage of the object-

oriented techniques in the field of computer science. This is particularly

unfortunate because compilers being very complex systems would

definitely benefit from the modularity and code reuse that object

orientation allows. In this paper, we present a tool called O2C2 that

brings into the world of compiler construction tools some of the

improvements that have taken place in computer science in the last two

decades. This tool has been used in several projects, to generate a newer

version of O2C2, to implement a XML non-validating parser and to

build a parser for the graphical user interface of O2C2. This tool is well

suited for projects either large or small.

1 Introduction

Since the 1970s, compilers are developed with the help of scanner and parser

generators like Lex[1] and YACC [2] and several versions of this tools like Jlex[3],

CUP[4], JavaCC [5] or ANTLR [6]. These tools vastly enhance the ability of

individuals to develop language processors and take benefit from a large user base.

The problem with these tools is that they have some drawbacks in the way they

operate and in the way that the analyzers they generate are designed.

Page 85: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

78 M. C. Luengo, D. Basanta, J. E. Labra, N. Gar a, J. M. Cueva• They read a specification that contains both the grammar of the language and

the actions associated with each alternative of a production of an element in the

grammar. This is a big software engineering problem and a fundamental flaw

due to its lack of modularity.

• The specifications tend to become huge and debugging requires the following

steps: writing action code, compiling the specification file, compiling the

resulting code, executing the resulting program to find errors, locating the

errors in the program and looking back in the specification file for the related

erroneous action code.

• The responsibility of keeping the specification and the code synchronized is

left to the programmer.

• Syntax predicates and semantic predicates are an integral part of the resulting

grammar in ANTLR. This makes the grammar obscure.

In this paper, we present a tool called O2C2 that brings into the world of compiler

construction tools some of the advancements that have appeared in computer science

in the last two decades [7, 8].

This paper is organized as follows. In section 2 we will study how object oriented

techniques could help easing those problems with traditional compiler construction

tools. In section 3 we describe the graphical user interface. In section 4 we use O2C2

to built an interpreter for a simple calculator. In section 5 O2C2 final remarks are

presented. In section 6 we discuss related work. In section 7 we describe future work

and in section 8 some conclusions are presented.

2 Object-Oriented Techniques and Frameworks in O2C2

Changing the way compilers are developed is no easy task. Compilers are expected to

work with a source text through a series of stages and that makes it easy to think

about procedural techniques.

We will define a framework as a reusable design of all or part of a software

system described by a set of abstract classes and the way instances of those classes

collaborate [9]. What this means is that we can develop a set of classes designed to

work together and with other external classes and that those classes will facilitate the

development of a certain kind of software systems that will work in a related field.

A framework can reduce the cost of developing this type of systems by making it

easy to reuse the design and the code in a well-defined domain. This means that

people with a basic knowledge of compiler theory can easily develop variants of

language processors. A well-defined set of classes is necessary in a framework in

order to achieve a consistency between the different software applications that could

be using that framework. However, a sufficient level of flexibility is also a must

because otherwise the compiler would not adapt to the language it is designed for.

The aim of O2C2 is to help developers create language processors by generating a

set of classes from a given syntactic specification of the language. O2C2 generated

classes are organized around a framework that represents an AST (Abstract Syntax

Tree). This AST’s nodes will be strictly typed so the data cannot be corrupted which

helps reducing debugging time.

Page 86: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Applying Frameworks and Obje t-Oriented Te hniques ... 792.1 The Main Framework

Each time O2C2 creates a new framework, it doesn't need to begin from scratch,

O2C2 relays on the O2C2-RT (O2C2 Run Time). O2C2-RT is the core of the

framework (as shown in figure 1) and remains the same no matter what language we

are working for, and allows a level of consistency between the language processors of

different languages.

Node is the root of every framework generated by O2C2. When an O2C2-based

analyzer is used, an AST is generated so any token found in the input automatically

becomes an instance of a class that inherits from Node. Node also has methods that

are common in every node in the AST.

The rest of the classes in this hierarchy are designed to work with the different

elements that could appear in a grammar expressed in EBNF notation. For instance, a

subclass of NodeChoice is created to treat each of the productions that a non-terminal

element in the grammar could have.

Node

void action()void callListeners()String getClassName()Object getValue()void init()void parse()void setValue()Vector getChildren()

NodeChoice

int getChoice()void parse()Object getValue()

NodeOptional

void parse()

NodeSeq

void parse()

NodeSeqOptional

void parse()

NodeToken

void parse()

Fig. 1. Core Framework in UML notation

NodeOptional is the superclass of all the classes that treat the elements of the

grammar whose appearance is not mandatory. This represents that some elements

may appear in a source text and may not appear in another one and both can be

following the rules as given by a grammar.

NodeSeq’s subclasses represent a sequence of elements of the grammar; let them

be terminals, non-terminals or EBNF elements that will be discussed later.

2.2 The Grammar and Specific Classes

A grammar in O2C2 is a set of rules that defines the syntax of a programming

language. As an example, consider the following grammar:

Page 87: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

80 M. C. Luengo, D. Basanta, J. E. Labra, N. Gar a, J. M. Cueva<S> ::= <num> <op> <num> " operation ";<op> ::= + " addition " | - " subtraction " | * " multiplication " | / " division " ;<num> ::= DIGIT DIGIT " number " ;

Non-terminals are represented by words between “<” and “>“, and terminals are

represented by capitalized words. With this tool, the user has to add links, quoted

words (in the example, "operation", "addition", …) in the sections of the grammar

where she would like her listener classes to be called. Then, the listener classes (in

section 2.3) only have to subscribe to classes whose name is that of the link.

With that input, O2C2 would complete the core framework with a group of classes

as illustrated by the diagram of figure 2.

Fig. 2. Object diagram in UML notation

The diagram shows that for each element and each production of the grammar a

class is generated. For instance, each non-terminal generates a class whose name is

the same as the non-terminal. Of course, all these classes are descendants from the

interfaces and classes that compose the core framework.

For instance, S is a subclass of NodeChoice. On the other hand operation is a

subclass of NodeSeq, which means that to parse operation we first have to parse num

(two times as seen in the grammar definition) and op.

numberEBNF0 is a special case. It is a subclass of NodeSeqOptional and its name

comes from the fact that there is a EBNF type repetition that occupies the first

position (hence the 0 in the name) in the production. This class will do when invoked

is parse while there is a DIGIT to be read at the input.

This diagram also represents the calling dependencies between the different classes

generated from the grammar. The process of parsing a source text whose structure

follows a grammar previously defined means calling the parse() method of the first

class in the object diagram, in the previous example this was class S. From this class,

the parser generated by O2C2 continues calling the parse() method of class operation

all the way down to a class that calls a NodeToken.

op

multiplication

num

number

numberE BNF0

division

s

operation

subtraction addition

Page 88: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Applying Frameworks and Obje t-Oriented Te hniques ... 81O2C2 is not a framework: it is a framework generator. With these classes and the

framework, the user already can obtain a working parser.

2.3 Listener Classes

When O2C2 finishes its work, the user gets a working analyzer ready to be compiledand used. O2C2 has already taken care of the analysis of the source but is up to theuser to do something with it.

When a parser generated by O2C2 reduces an expression, it calls an objectprovided by the user if there is one. So what the user has to do in order to providefunctionality is to create objects that can be called by the classes in the framework.

This way of adding code to the framework is also known as the listener pattern,and it is already popular among Java programmers because it is present in the JFC[10]framework. By using it, O2C2 allows the co-existence and communication ofclasses created by the user and its own classes.

Basically, a parser generated by O2C2 analyzes a source text trying to match theinput with an element of the grammar. When that element of the grammarcorresponds to a section attached to a link, an event is generated. This event may ormay not be interesting to the user. If it is, the user should create a class that registersto this class of event. In the example of the calculator we can create a class that willsubscribe to events generated by number. This means that every time the parser findsa group of tokens organized as described by a grammar section which is in the leftside of the number link, then a special method of the user’s class, calledperformAction(), will be called. In this method the user can do what she needs, andwhen it finishes the parsing is resumed.

Parser Generator

Yacc

Prog := fun S$..fun := ID $1...

stmt := ... Botton up. LR(k)

C Compiler

Language Processor

Text

(text)

Text Input Text xx yyy

0100111

Output

Debug

Grammar

Specification

+

User Code

Parser.c

s,x

s,x

Parser.Java

Parser Generator

O2C2

Prog := fun fun := ID stmt

stmt := ...

Gramática (EBNF) Top Down. LL(k)

class ...

Listeners

O2C2rt (class ...)

Framework

Compiler

Java

Language Processor

Text (text)

Text Input Text xx yyy

0100111

Output Debug

Fig. 3. Traditional versus modern compiler construction tools

As opposed to other tools, the user doesn’t need to create classes for all the eventsthat might appear in an analysis. When an event hasn’t got a listener subscribed then adefault action is performed by O2C2RT so the values of the event are preserved for

Page 89: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

82 M. C. Luengo, D. Basanta, J. E. Labra, N. Gar a, J. M. Cuevalater use in other stages of the analysis. This feature frees the user from having to

create action code that doesn’t provide anything meaningful to the parsing process.

The flexibility of the listener pattern approach has many advantages. An object can

register or de-register at run-time depending on the circumstances of the source that

has already been parsed. A grammar can be used with two or more sets of listener

classes. Compilers that work in multiple passes can be developed easily just

registering and de-registering some classes. A group of user classes that deal with the

same syntactic structure can be reused effortlessly. That means that if one or more

classes are in charge of an “if-then-else”, these classes could be reused completely in

almost any language with such a syntactic expression

The clear separation of the grammar specification from the action code associated

to that grammar means that a change in one side won’t affect the other. For example,

whenever a change is made to the action code, the specification has to be run trough

the YACC program and then through the C compiler. In O2C2, when a change is

made in the action code, only one class file has to be recompiled. This has the

potential to vastly shorten the edit-compile-debug cycle as shown by the diagram of

figure 3.

2.3 Error Handling and Recovery

Error handling and recovery uses the same listener pattern. By default, when an O2C2

generated parser finds an error, it displays a meaningful error message and exits, but it

is very easy to add extra code that will make the parser fault-tolerant.

3 The Graphical User Interface

The O2C2 system also includes a graphical user interface called O2C2ui (O2C2 user

interface). The aim of this user interface is threefold:

• A usable and intuitive user interface can ease things for the novice user and

guide him through the different stages of the development of a language

processor.

• Unlike similar tools, O2C2 doesn’t generate lexical analysers. This has some

advantages because it gives more choice to the user and makes O2C2 syntactic

specifications simpler. This is, an O2C2 specification file not contain the

lexical definitions. Nonetheless, it is not easy for novices to create lexical

analysers so O2C2ui helps the user create lexical specifications with jflex [11].

We plan to make O2C2ui able to work with other tools.

• O2C2ui also includes support for the semantic analysis. This means that with

O2C2ui it is possible to integrate the three stages of a language processor in

just one place, as shown in figure 4.

To give a semantic meaning to the language processor, the user has to include

action code in the classes generated whose name is that of the link in the grammar.

The skeleton of these classes appears in the section Actions with syntax highlighting,

as shown in figure 4.

Page 90: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Applying Frameworks and Obje t-Oriented Te hniques ... 83O2C2ui allows the creation of XML files with the information of the scanner, the

parser and the semantic specifications for a entire project. It makes easy the user to

work with his project in other environments, come back to O2C2ui to read the

XML file and to generate the parser if the user has all the specification lexical,

specification syntactic and actions code necessary.

Fig. 4. A screenshot taken from O2C2ui

4 General steps to built a language processors using O2C2

We present all the steps of building a language processor (interpreter) using O2C2 for

a simple calculator.

1. Creating a specification file for the grammar. Lets call it sintactical.o2c2:

<S> ::= <num> OP <num> "operation" ;<num> java.lang.Integer::= DIGIT DIGIT "number" ;

The words in uppercase are the tokens of the grammar and for the non-terminal

element num we only accept values of type Integer.

2. Creating a lexical analyzer that recognizes digits and operators. For this we will

use the jflex tool [11] and a specification file named lexical.flex. Here is the code.

%%%class lexer%extends symb%implements o2c2rt.Lexer%type stnode.Symbol%unicode%%

Definitions for each

of the non-terminals

Non-terminals

elements list

Editor

Lexicon

Semantic specification

and action code

Page 91: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

84 M. C. Luengo, D. Basanta, J. E. Labra, N. Gar a, J. M. CuevaLineTerminator = \r|\n|\r\nInputCharacter = [^\r\n]

/* Comments */COMMENT = TraditionalComment | EndOfLineComment |DocumentationCommentTraditionalComment = "/*" [^*] CommentContent \*+ "/"EndOfLineComment = "//" InputCharacter* LineTerminatorDocumentationComment = "/**" CommentContent \*+ "/"CommentContent = ( [^*] | \*+[^*/] )*DIGIT=[ 0- 9]WHITE_SPACE_CHAR=[\n\r\ \t\b\ 012 ]

%%DIGIT return new o2c2rt.Symbol (symb.DIGITO,yyline,yycolumn,yytext()); "+" return new o2c2rt.Symbol (symb.OP,yyline,yycolumn, "+" );"-" return new o2c2rt.Symbol (symb.OP,yyline,yycolumn, "-" );"/" return new o2c2rt.Symbol (symb.OP,yyline,yycolumn, "/" );"*" return new o2c2rt.Symbol (symb.OP,yyline,yycolumn, "*" );WHITE_SPACE_CHAR* /* ignoramos */ COMENTARIO /* ignoramos */ .|\n throw new RuntimeException( "Illegal Character\"" +yytext()+ "\" in line " +yyline+ ", column " +yycolumn);

We use some directives of the Jflex specification to indicate that the class name

that are going to generate is lexer. This class implement the o2c2rt.Lexer class and it

descends from the Symb class. The Symb class is generated by O2C2 and it contains

the constant associates to each token. Also we define that the class that we are going

to return is o2c2rt.Symbol and it is the type to return from yylex. Now, we generate

the syntactic analyzer and lexical analyzer.

% java o2c2.Main sintactical.o2c2

A parser directory will be created whith the classes generated for the syntactic

analyzer and the current directory will generate two files, if is that not existian

before, myparser.java and symb.java.

% jflex lexical.flex

% javac parser/*.java

% javac *.java

To test the parser generated we can create one file named input with only one line,

for example: 56+42

% java myParser input

In case of errors, the error handling and recovery system that incorporates O2C2

will output a message indicating where it has found it and that it was expected.

3. Creating the listeners.

If we have already created the specification and O2C2 has generated the

framework and some auxiliary classes, then we can begin the process of creating the

Page 92: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Applying Frameworks and Obje t-Oriented Te hniques ... 85listeners. In the grammar of the example there are only two productions and we are

interested in creating listeners for them. The first alternative is:

<num> ::= DIGIT DIGIT "number" ;

The class associated with the alternative <num> is called number. This means that

the class that we are going to create, will subscribe to it. This example shows how to

implement the interface Listener.

import parser.*;import o2c2rt.*;import java.util.Vector;public class Anumber implements Listener public Anumber () number.addListener ( this ); public void performAction (Node o) try number num = (number) o;

String s1 = (String) num.getValue(0); String s2 = "";

Vector v1 = (Vector)num.getValue(1); if (v1!=null) for (int contador=0;contador<v1.size(); contador++) String aux = (String) v1.elementAt( contador); s2 = s2+aux; num.setActionResult (new Integer(s1+s2)) ;

catch (ParserException e) e.printStackTrace();

;

The constructor adds the class to the set of listeners that have requested

subscription to any instance of number.

The functionality provided by this method is the following: collect the digits found

at the input and put them in a String forming a number.

As we have defined the non-terminal num of type Integer, when we call the

method setValue() it is necessary to use an Integer as the parameter.

In the method performAction(), the variable getValue(0) will be a digit, but we first

translate it to a string so we can concatenate it with the rest of digits

On the other hand, getValue(1), which is the variable that corresponds to DIGIT,

is of type EBNF, that is, while there are DIGITs to be read at the input, the class will

continue its work of making the analysis. As we don’t have any listener subscribed to

this class, the semantic value of the EBNF class is the default value, in this case, a list

(java.util.Vector) of the tokens that have been read by the class.

There is no need to create a listener for each elements of the grammar that has a

corresponding class in the framework generated by O2C2. If a class of the framework

has no listeners, then the values obtained are preserved for later use in the analysis.

Obviously this is not the easiest way to obtain a number. This task is in fact more

likely to be delegated to the lexical analyzer, not to the syntactic analyzer, but we

have done things this way for pedagogic reasons.

The other production we have to deal with is:

<S> ::= <num> OP <num> "operation" ;

Page 93: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

86 M. C. Luengo, D. Basanta, J. E. Labra, N. Gar a, J. M. CuevaThe class to which we will subscribe our listener will be called operation and the

listener is:

import o2c2rt.*;import parser.*;public class AOperation implements Listener public AOperation () operation.addListener ( this ); public void performAction (Node o)

int result= 0; int num1, num2;

String op; try operation s = (operation) o; num1 = ((Integer)n.getValue(0)).intVa lue(); num2 = ((Integer)n.getValue(2)).intVa lue(); op= (String) n.getValue(1); if (op.compareTo( "-" )== 0) resul=num1-num2; else if (op.compareTo( "+" )== 0) resul=num1+num2; else if (op.compareTo( "*" )== 0) resul=num1*num2; else if (op.compareTo( "/" )== 0)

if (num2== 0) throw new SemanticException

( "Error, division by zero" );else resul = num1/num2;

System.out.println ( "\nResult: " +result); catch (ParserException pe) pe.printStackTrace(); ;

The listener transforms getValue(0) and getValue(2), the two <num> of the

alternative, to two integers and getValue(1), which corresponds to <op>, is

transformed to a string. Depending of the content of getValue(1), the listener will

perform an operation or another and present the result to the user.

So far, the only thing we have got are two classes with their instances subscribed to

classes generated by O2C2 from a grammar specification. For the whole system to

work someone has to create instances of those classes and so far the only way to do

this is to make the modifications in the file myParser.java.

Those modifications consist in adding somewhere the code that is needed to create

instances of the listener classes. Class myParser is:

import o2c2rt.*;import parser.*;import java.io.*;public class myParser extends Parser implements Serializable

Node first; AOperation s; ANumber n;

public myParser (String in) super ();

try l = new lexer ( new FileReader(in));

catch (FileNotFoundException e) System.out.println(e);

first = new StS( this ); n = new Anumber();

Page 94: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Applying Frameworks and Obje t-Oriented Te hniques ... 87 s = new Aoperation();

public void parse () try first.parse(); catch (Exception e)

e.printStackTrace(); public static void main (String args[]) if (args.length== 0)

System.err.println ( "Parameters needed" );System.exit(- 1);

Parser p = new miParser (args[ 0]); p.parse();

;

The modifications are written in bold letters. Compiling again the class and the

listeners will result 98.

5 O2C2 and usability

The main purpose of O2C2 is to improve some features of language processors

development like extensibility, modularity, reusability and the length of the

development cycle using object-oriented techniques.

Now, we will see how the improvement of these features translates into an

improvement in usability [12]. Usability is a concept that many people apply only to

applications whose user interface (UI) plays an important role. This does not need to

be true so restricted and we can see that the advantages of considering usability in

language processors tools have the potential to increase the quality of software [13].

There is some agreement that these six attributes comprise the idea of usability:

• Utility

The first mission of a system is to be useful for some purpose. The utility of O2C2

is similar to that of older tools but if previously, these tools were more compiler-

oriented, nowadays the scope of language processors is much broader. O2C2

generates frameworks for object-oriented language processors in Java. This makes it

very well suited for new tasks like XML parsers, editors with syntax highlighting, or

syntax checking in word processors. Also, it has shown to be particularly well suited

when working in large and complex software systems.

• Learnability

For tools to be used, they have to be easy to learn. For compiler tools to be easy to

learn they must be based on a small set of concepts. All language processors

generators expect their users to have a minimum knowledge of compiler theory.

Nonetheless there are some differences between O2C2 and other tools. The

specification files in other tools are so complex that it is difficult for a user without

previous experience to begin using the program. On the other hand, O2C2’s

specification file is simple because it contains only the grammar in EBNF notation.

Page 95: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

88 M. C. Luengo, D. Basanta, J. E. Labra, N. Gar a, J. M. CuevaFurthermore, the O2C2 system includes a graphical user interface that makes it easy

for new users to begin use it.

• Efficiency

If we want users to use one application, that application should be efficient;

otherwise they will resort to traditional methods. The importance of this attribute is

easy to see in the case of web sites. Regardless of the usefulness of the site, if it’s too

slow to load on the user’s browser it will never be used. This will mean that tools

should be efficient but also the analyzers generated by them should be efficient in

both, resource consumption and speed.

Nonetheless, efficiency in these tools can be seen from various points of view. If

we are mainly interested in speed of execution or resource consumption then, older

tools can be considered more efficient than O2C2. Anyway , we believe that an

efficient tool is the one that makes the user more efficient. O2C2 separates the

grammar from the action code, so it is not necessary to use the tool constantly.

Instead, the tool will be used only when there is a change in the grammar, something

that seldom happens. We think that by shortening the development cycle, O2C2 is a

more efficient tool.

• Retainability

When an application forces the user to deal with lots of data simultaneously and it

is easy to get lost under the sheer number of details, then that application cannot be

called usable. In the case of language processors generator tools this means complex

specifications for the grammar or lots of different concepts needed to understand the

analyzer.

In traditional tools, this problem has special relevance because the specification file

includes both the grammar and the action code. This means that even for simple

languages, specifications easily become huge and complex so the user can get lost

between so many details.

As we have said, O2C2 separates the grammar specification and the user-provided

action code. The tool tries to be simple and this simplicity means that with little

interaction with the user, O2C2 can generate a working analyzer.

Also affecting the retainability of a tool is the number of concepts that must be

understood by a potential user before using it. The less the number of concepts

involved, the better. The number of concepts needed to begin using O2C2 is minimal

and chances are that the user already knows them, like the listener pattern.

• Errors

Applications should be ready to work under unexpected conditions and in the case

of compiler generators, this means providing help to the user when there is something

wrong in his grammatical specification but also generating analyzers that are able to

work when they find some problems.

Error management has not received a lot of attention by the designers of traditional

compiler tools, or at least that is what is seems. This is very unfortunate because

language designers and implementers are as prone to commit errors as any other kind

of user.

Page 96: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Applying Frameworks and Obje t-Oriented Te hniques ... 89As we have seen in other attributes, there are two users we have to take in mind

when designing compiler generators. On one side we have the users of the tools.

These users have to deal with complex grammatical specifications, which means that

errors will happen. A compiler construction tool should not only detect errors in the

specification but also provide some guidance to the user, helping him to locate and

correct the error. Many compiler tools detect errors in the specification but the only

give obscure error messages.

The other user of a compiler generator is the user of the language processors

generated by it. We will call him end-user. If the tool creates analyzers in which it is

difficult to incorporate code for error management, this code will probably be missing

in the application. So far, compiler tools only provide the means to catch errors in

end-user input to the analyzer, but it is not easy to treat those error where they have

taken place. This makes it very difficult for an analyzer to recover from a end-user

error and continue working.

The error handling and recovery in O2C2 uses the same listener pattern already

described for the action code. By default, when an O2C2-generated parser finds an

error, it displays a meaningful error message and exits, but it is very easy to add extra

code that will make the parser fault-tolerant.

For the first kind of users, O2C2 detects errors at their inputs and explains where

they have taken place and some times how to solve it. This is not as hard as it seems

because most of user’s errors are always the same and happen for the same reasons.

Also, O2C2 take advantage of Java’s implementation of exception management to

allow users treat errors committed by end-users when feeding an input to an analyzer

generated by O2C2.

• Satisfaction

An application with an intuitive and reliable behavior is likely to be satisfactory for

most users. What is more important in compiler tools is not to cause frustration to the

user. Most of the frustration that these tools can cause in the user is due to

unnecessary complexity, unexpected behavior, lack of documentation and examples,

or lack of power.

YACC antiquity and popularity means that there are lots of examples and

documentation. As for power, YACC’s table-based analyzers are very powerful. On

the other hand, the complexity of its specifications and of the analyzers it generates is

undoubtedly a source of frustration for the user.

O2C2’s documentation tries to be comprehensive and pedagogic. The specification

of a grammar couldn’t be simpler, the analyzers it generates are predictive and it is

behavior easier to understand.

6 Related works

Recently, there have been some attempts to introduce object-oriented techniques in

the field of compiler construction. One of the most interesting examples of this is

SableCC [14]. O2C2 and SableCC have some things in common, but there are also

some important differences.

Page 97: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

90 M. C. Luengo, D. Basanta, J. E. Labra, N. Gar a, J. M. CuevaO2C2 has a core framework that acts as a run-time and that is present across all

parsers. SableCC’s grammatical specification is bigger because it includes lexical and

the syntactical specifications whereas O2C2 specifications contain only in the

syntactical specification. The reason behind this decision is that we wanted to make

O2C2 more modular. SableCC generates a framework that represents an AST and the

user has to build a tree-walker class for it. On the other hand, the framework

generated by O2C2 parses a source-text and when it finds something of interest it

calls the class or classes generated by the user that have shown interest in that kind of

event. We feel that O2C2’s approach is more modular, dynamic and flexible.

The event delegation mechanism of O2C2 is present in the JFC [10] and SaX API

[15]. This means that those people, who already know how to use a SaX parser, also

know the basic principles that rule the behaviour of an O2C2- generated parser and

therefore should be able to develop their own custom-made parsers in almost no time.

7 Future Work

O2C2 is an unfinished work and while we are getting near a stable release some areas

of improvement can still be identified:

• Make O2C2’ architecture flexible and language-independent. Right now,

the O2C2 run-time uses Java and the code it generates is in Java too. We plan

to make a flexible integration.

• To incorporate an editor that understood both rules and translation, and can be

programmed to edit both using different conventions.

There has been an increasing interest in modular development of programming

languages with the aim of rapidly prototyping domain specific languages. This

modularity can be achieved separating the language semantic through the notion of

monads [16]. The connection between our framework and those works seems a

promising area for future research.

8 Conclusions

Language processors generators are prone to be counter-intuitive, difficult to learn

and complex to operate. The fact is that designing compiler construction tools for

usability has benefits not only for the users of these tools but also for the users of the

language processors generated by them.

Traditional compiler tools have brought lots of advantages for programmers and

language designers as they shortened the development time and lowered the barrier

needed to build a language processor, but they felt short in other areas like usability.

On the other hand, compiler construction tools have in most cases failed to take

advantage of object oriented technologies. The use of such techniques to develop

compilers has the potential to ease the modularity and to improve code reusability. It

could also reduce the length of the code written by the programmer, shorten the

development time and make the code easier to read and maintain.

Page 98: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Applying Frameworks and Obje t-Oriented Te hniques ... 91The introduction of frameworks in the field of language processors construction,

while not an obvious task, will undoubtedly foster the use of object oriented

techniques in the same way that frameworks fostered the use of object oriented

techniques in the field of graphical user interfaces.

We feel that O2C2 has the potential to increase the productivity of programmers

and the quality of their products as compared with traditional compiler generators

because it was designed with usability in mind and object-oriented techniques. We

think it is easy to learn and the concepts it uses are known for most programmers. For

all those reasons, we believe that O2C2 could be successfully used with new projects

either large or small. We have developed a prototype implementation in Java. It is

available in http://www.di.uniovi.es/~candi/o2c2/o2c2.htm

References

1. Lesk, M. E.: Lex – a lexical analyzer generator. Technical Report Computing Science

Technical Report 39, AT&T Bell Laboratories. Murray Hill, N.J.,1975

2. Johnson, S.C.: YACC – yet another compiler compiler. Technical Report Computing

Science Technical Report 32, AT&T Bell Laboratories. Murray Hill, N.J.,1975

3. Berk, E.: Jlex: A Lexical analyser generator for Java. World-Wide Web page URL:

http://www.cs.princeton.edu/~appel/modern/java/JLex/

4. Hudson, S.E.: CUP parser generator for Java™. World-Wide Web page URL:

http://www.cs.princeton.edu/~appel/modern/java/CUP/

5. JavaCC™. URL: http://www.inf.ufrgs.br/tools/java/JavaCC/

6. Megelang Institute. ANTLR 2.7.0. World-Wide Web page URL: http://www.antlr.org/

7. Basanta, D., Luengo, M.C., Izquierdo, R., Labra, J. E., Cueva, J. M.: Constructing Language

Processors using Object-Oriented Techniques. 6th International Conference on Object

Oriented Information Systems (OOIS 2000). ISBN 1-85233-420-7, Springer-Verlag, 2000

8. Basanta, D., Luengo, M.C., Izquierdo, R., Labra, J. E., Cueva, J. M.: Improving the quality

of compiler construction with object-oriented techniques. ACM SIGPLAN. Volume 35,

Number 12. Pages 41-51. December 2000

9. Roberts, D., Johnson R. R.: Evolving Frameworks: A pattern language for developing object

oriented frameworks. University of Illinois, 1997

10. Amy Fowler.: A Swing architecture overview. The inside story on JFC Component Design.

URL: http://java.sun.com/products/jfc/tsc/articles/architecture/index.html.

Sun Microsystems. Jun 2000

11. Klein, G.: JFlex user’s manual. URL: http://www.jflex.de. July 1999

12. Goodwin, N. C.. Functionality and usability. Communications of the ACM.Pages 229-233.

March 1987

13. Gould, J. D., Lewis, C.: Designing for usability: Key principles and what designers think.

Communications of the ACM. Pages 300-311.March 1985

14. Gagnon, E., Hendren, L.: SableCC, an Object-Oriented Compiler Framework. McGill

University, Quebec, Canada. June 1998

15. Megginson, D. SAX 2.0: The Simple API for XML.: May 2000. URL:

http://www.megginson.com/SAX/index.html

16. Labra, J. E., Cueva J. M., Luengo, M. C., Cernuda, A.: LPS: A language prototyping

system using modular monadic semantics. In M. van den Brand and D. Parigot, editors, First

Workshop on Language Descriptions, Tools and Applications, volume 44, Genova, Italy,

April 2001. Electronic Notes in Theoretical Computer Science – Elsevier

Page 99: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 100: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 101: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

94 M. Clavel, F. Durn, S. Eker, P. Lin oln, N. Mart-Oliet, J. Meseguer

Page 102: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Language Prototyping in the Maude Metalanguage 95

Page 103: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

96 M. Clavel, F. Durn, S. Eker, P. Lin oln, N. Mart-Oliet, J. Meseguer

Page 104: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Language Prototyping in the Maude Metalanguage 97

Page 105: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

98 M. Clavel, F. Durn, S. Eker, P. Lin oln, N. Mart-Oliet, J. Meseguer

Page 106: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Language Prototyping in the Maude Metalanguage 99

Page 107: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

100 M. Clavel, F. Durn, S. Eker, P. Lin oln, N. Mart-Oliet, J. Meseguer

Page 108: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Language Prototyping in the Maude Metalanguage 101

Page 109: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

102 M. Clavel, F. Durn, S. Eker, P. Lin oln, N. Mart-Oliet, J. Meseguer

Page 110: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Language Prototyping in the Maude Metalanguage 103

Page 111: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

104 M. Clavel, F. Durn, S. Eker, P. Lin oln, N. Mart-Oliet, J. Meseguer

Page 112: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Language Prototyping in the Maude Metalanguage 105

Page 113: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

106 M. Clavel, F. Durn, S. Eker, P. Lin oln, N. Mart-Oliet, J. Meseguer

Page 114: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Language Prototyping in the Maude Metalanguage 107

Page 115: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

108 M. Clavel, F. Durn, S. Eker, P. Lin oln, N. Mart-Oliet, J. Meseguer

Page 116: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Language Prototyping in the Maude Metalanguage 109

Page 117: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

110 M. Clavel, F. Durn, S. Eker, P. Lin oln, N. Mart-Oliet, J. Meseguer

Page 118: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Panta Rei (Everything Flows): A Calculus of Channels

Farhad Arbab

Department of Software Engineering, CWI, Kruislaan 413, 1090 GB Amsterdam, Holland.

In this talk, we present a calculus of channels that we call Rew. The purposeof Rew is to allow compositional development of the “glue code” for connectingthe components that comprise a dynamically evolving software system.

Rew provides a paradigm for composition of software components basedon the notion of mobile channels. Both components and channels are mobile inRew, in the sense that (1) components can move at any time fromone location toanother, retaining their existing channel links, and (2) the same channels can bedisconnected and reconnected to other components, thus, dynamically changingthe topology of inter-component communication.

The component composition paradigm of Rew is in the style of the IWIMcoordination model, and is an extension of our earlier work on a formal-logic-based component interface description language to convey the observable se-mantics of components. The main focus of attention in Rew is the channels andoperations on them, not the processes that operate on them orthe componentsthat they are connected to. The composition operations in Rew combine variouschannel types to produce complex dynamic topologies of “connectors” to whichprocesses or components can be attached.

Page 119: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 120: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

INDALOG: A De larativeDedu tive Database LanguageJesus M. Almendros-Jimenez? and Antonio Be erra-TeronDpto. de Lenguajes y Computa ion. Universidad de Almera.email: fjalmen,abe erragual.esAbstra t. In this paper we present the main features of a dedu tivedatabase language named INDALOG based on the integration of fun -tional and logi paradigms. As most dedu tive database systems, INDA-LOG allows the handling of negation, higher-order fun tions, groupingoperators, support for aggregation, handling of non-ground fa ts, and sup-port for indexing stru tures on both extensional and intensional relationsof a database. Moreover, we present the semanti foundations of this lan-guage.1 Introdu tionDedu tive database systems [16 are database management systems whose querylanguage and storage stru ture are designed around a logi data model. Dedu tivedatabase systems oer a ri h query language whi h extends the relational modelin many dire tions (for instan e, support for non-rst normal form and re ursiverelations) and they are suited for appli ation in whi h a large number of data mustbe a essed and omplex queries must be supported (see [16 for appli ations ofdedu tive systems). With respe t to the information management, the dedu tivedatabase systems split their information into two ategories: Fa ts represented by literals onsisting of a predi ate applied to terms, whi hare onstants, variables, or fun tors applied to terms. For instan e, the fa tparent(mary,peter) sets that Peter is parent of Mary. This predi ate is rep-resented extensionally, that is, all tuples for this predi ate are stored in adatabase relation. Rules whi h are written in Prolog-style notation as follows p : q1; :::; qn:where p (the head) and qi's (the subgoals) are literals.The rules are refereed as the intensional database (IDB) and the fa ts as exten-sional database (EDB). The intensional database plays a role similar to views in onventional database systems, although there will be large numbers of intensionalpredi ates w.r.t. the numbers of views dened in typi al database appli ations. Atypi al example about the expressivity power of dedu tive databases is as follows:Extensional Databaseparent(john; mary): parent(john; frank):parent(mary; thomas): parent(frank; mi hael):Intensional Databasean (X; Y) : parent(X; Y): an (X; Y) : parent(X; Z); an (Z; Y):Query: an (john; Y):? The author has been partially supported by the Spanish CICYT (proje t TIC 98-0445-C03-02 TREND)

Page 121: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

114 J. M. Almendros, A. Be erraHere, there exist two relations, one extensional relation dened by four rules and alled parent, and other intensional one, named an and dened by a re ursiverule. The proposed query will ompute all john's an estors, that is Y = mary,Y = frank, Y = thomas, and Y = mi hael.The relations of a dedu tive database an in lude fun tors to store the so- alled omplex terms. In a logi programming ontext, the omplex terms are alledfun tions be ause of their synta ti apparen y, onsisting of a fun tion name(named the fun tor) followed by a list of arguments. In a dedu tive language,these omplex terms are not used to represent fun tions; rather, they are usedas variable-length subre ords. For instan e, suppose the following omplex termaddress(Name,City)whi h an be used in the base relation person(DNI,address(Name, City),Job) in order to stru ture the stored information.Most dedu tive database systems (for instan e, DATALOG [20, CORAL [14,ADITI [21, LOLA [23) allow to handle negative literals, in reasing their expres-sive power as query languages. The introdu tion of negation in logi programming(see [4 for a survey), and thus the study of semanti models for logi programshave been widely studied in the past being most relevant one the well-founded se-manti s [22. Some dedu tive database systems have adopted su h semanti s andoperational models [17, 9 based on this semanti s. For instan e, in the dedu tivesystem DATALOG, we an write the following database:Extensional Databasestudent(peter; senior): took(jim; s2; 3:3):student(jim; junior): took(jim; s3; 3:0):student(mary; junior): took(mary; s1; 2:0):took(peter; s1; 3:0): took(mary; s2; 3:0):Intensional Databasehastaken(Name; Course) : took(Name; Course; Grade):la ks s3(Name) : student(Name; junior);:hastaken(Name; s3):Query: la ks s3(N):Here, the extensional relations student and took set the name and year of astudent, as well as the ourses taken by the student with the orresponding grade.The intensional rules are meant to ompute junior students who did not take ourse s3. The omputed answer will be N = mary.In addition, most dedu tive database systems allow grouping and aggregationoperators to be used with groups of tuples. The idea of grouping operators is to olle t the set (multiset) of values for a given attribute and, in the ase of ag-gregation operators, to manage the olle ted values. For instan e, the dedu tivedatabase system CORAL [14, 13 allows to olle t values in the form of sets andmultisets by means of set (fg) and multiset (<>) grouping onstru tors. The fol-lowing rule illustrates the use of the multiset onstru t:set of grades(Class; < Grade >) : student(Name; Class);took(Name; Course; Grade):wherein for ea h Class value, a multiset ontaining all orresponding values forGrade is reated. Similarly with the set-grouping onstru t. The use of thesegrouping primitives an be ombined with aggregation operators like ount, min,max, sum, produ t, average, any and so on. In CORAL we an write the followingrule for omputing the average grade:max grade(Class; average(< Grade >)) : student(Name; Class);took(Name; Course; Grade):

Page 122: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

INDALOG: A De larative Dedu tive Database Language 115Some of the dedu tive database systems (for instan e, XSB [18) enri h theirexpressivity power by adding higher-order features. The dedu tive database sys-tem XSB adopts HiLog [6, a foundation for higher order logi programming, byproviding an elegant way to onstru t and manipulate sets. For instan e, the fol-lowing XSB database:ExtensionalDatabasepa kage1(health ins; required): pa kage2(long va ations; optional):pa kage1(life ins; optional): benefits(john; pa kage1):pa kage2(health ins; required): benefits(bob; pa kage2):pa kage2(free ar; optional):Query: benefits(john; P); P(X; Y):denes the extensional relations pa kage1 and pa kage2 used to denote the setof john's and bob's benets, respe tively. Benets are a set of fa ts indi ating thetype of benet and whether it is optional or required. The query binds P to thename of the set of john's benets (P = pa kage1), and then retrieves the fa tsthat des ribe his benets expli itly, that is X = health ins Y = required andX = life ins Y = optional. Also, this representation an be extended to in ludeset operations. For instan e, the following rule omputes the interse tion of twosets and the query allows to obtain both john's and bob's benets.Intensional Databaseinterse t(S1; S2)(X; Y) : S1(X; Y); S2(X; Y):Query: benefits(john; P1); benefits(bob; P2); interse t(P1; P2)(X; Y):Following with the features of dedu tive database systems, there exist systemswhi h allow to use non-ground fa ts. The use of non-ground fa ts (i.e. fa ts ontaining universally quantied variables) is useful in the dedu tive database ontext. The dedu tive system CORAL [19 supports eÆ iently the handling ofnon-ground fa ts. For instan e, suppose a database about employee salary:Extensional Databasebase salary(john; 1500): base salary(mar ; 2500):base salary(peter; 3500): omplement salary(X; 1000):wherein there exists one non-ground fa t, omplement salary(X; 1000), express-ing that all employees will have a salary omplement (1000 euros), and thus avoid-ing the spe i ation of one fa t for ea h employee. Now, we an ompute the totalsalary by means of the following rule:Intensional Databasetotal salary(X; Y) : base salary(X; T); omplement salary(X; Z); Y = T + Z:With respe t to the implementation, the dedu tive database systems provide arepresentation of indi es. Most dedu tive database systems use the typi al index-ing stru tures used in database appli ations, like hash and B-trees indi es on theextensional and intensional database relations. By means of adding indi es, somedatabase operations, like join, an be eÆ iently made for disk-resident data. Forinstan e, XSB [18 supports dierent kinds of indexing. The default is hashing onthe rst argument of a relation. However, de larations an be used to indi ate thedesired options. Indi es an be onstru ted on any attribute or set of attributes(multi-attribute indexing). For example, a predi ate p with arity 5 ould have thefollowing index de laration:: index(p=5; [1; 2; 3 + 5):whi h will ause indi es on p=5 in su h a way that a retrieval will use the index

Page 123: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

116 J. M. Almendros, A. Be erraon the rst argument, if ground, otherwise on the se ond, if ground, and otherwiseon the third and fth ombined.Other example of indexing is the dedu tive language CORAL [15 whi h sup-ports hash-based indi es for memory relations and B-trees indi es for disk rela-tions. It allows two types of hash-based indi es, (1) argument indi es with thetraditional multi-attribute hash index and (2) pattern indi es whi h is an indexstru ture more ompli ated sin e that su h indi es are used with omplex termsand non-ground fa ts. For instan e, given a relation employee with two argu-ments, Name and a omplex term address(Street; City) in CORAL, then thefollowing de laration reates a pattern index to retrieve employees without know-ing their street.make indexemployee(Name; address(Street; City))(Name; City):Here, we are interested in the study of a dedu tive database system based onthe integration of the fun tional and logi paradigms. The integration of fun -tional and logi programming has been widely investigated during the last years.It has led to the design of modern programming languages su h as CURRY [8and TOY [10. The aim of su h integration is to in lude features from fun tional( fr. determinism, higher order fun tions, partial, non-stri t and lazy fun tions,possibly innite data stru tures) and logi ( fr. logi variables, fun tion inversion,non-determinism, built-in sear h) languages.Our idea is to develop a dedu tive database query language, named INDA-LOG, whi h in ludes these advantages and also allows the eÆ ient managementof data like in dedu tive databases based on logi programming.The main dieren e with respe t to a \pure" fun tional-logi language, su has CURRY or TOY , is that INDALOG is thought for working with a largevolume of data whi h usually will be stored in se ondary memory. Like Prolog,fun tional-logi languages work eÆ iently with main-memory resident data, butineÆ iently with respe t to the disk a esses when data are stored in se ondarymemory. The main reason for this drawba k is that the operational me hanism ofsu h languages works with a tuple (fa t) at time, whereas the dedu tive databasesystems allow a set of tuples at time.The basi idea of the operational me hanism of dedu tive database languagesis to use a bottom-up evaluation for query solving. This bottom-up me hanismis based on the appli ation of the immediate onsequen e operator dened forlogi programs whi h allows to ompute the Herbrand model of a logi program.The use of this operator for query solving is very ineÆ ient and thus a programtransformation te hniques, alled Magi Sets-based transformations [5, 12, havebeen studied. The aim of this pro ess is to transform the original program w.r.t.the proposed query in su h a way that the appli ation of the immediate onse-quen e operator on the transformed program and query is goal-oriented and an beused for query solving. Moreover, this evaluation me hanism is more set-of-tuples-oriented than top-down evaluation me hanism supported by logi languages andtherefore adequate for indexing of tuples. In our ase, we have proposed a bottom-up evaluation me hanism for fun tional-logi programming in [1, whi h has beenextended in [2 for the handling of negation in the line of [11, to be onsideredas the omputational model for INDALOG .The aim of this paper is to present the main features already developed and tobe developed in our dedu tive database language INDALOG . As most dedu tivedatabase systems, this language will allow the handling of negation, higher-order

Page 124: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

INDALOG: A De larative Dedu tive Database Language 117fun tions, grouping operators, support for aggregation, handling of non-groundfa ts, and support for indexing stru tures on both extensional and intensionalrelations of a database. Moreover, we will present the semanti foundations ofINDALOG .2 INDALOG FeaturesIn this se tion, we present the main features in our dedu tive language. AnINDALOG dedu tive database DB will be onstituted by the following set ofmodules. type denition whi h in ludes the denition of type symbols. base relations whi h in ludes the denition of ea h extensional relation of thedatabase. Also alled base fa ts, typi ally they will be indexed and stored inse ondary memory (see subse tion 2.4 for more details). derived relations whi h in ludes the denition of ea h intensional relation ofthe database. Fa ts obtained from derived relations will be also indexed andstored at run-time in se ondary memory. fun tion denition whi h is a set of manipulating fun tions to be used inan INDALOG database whi h they are neither base nor derived relations.Typi ally, they represent the fun tional part of the language whi h managesdata types su h as list, trees, et . It is assumed that indi es are not used forthe fun tional part. query denition whi h is a set of onditions to be solved.DB := Types; Rules; Query:Types := type Type definition1 : : : Type definitionn endtype:Type definition := Data de laration j ExtRelation de laration j IntRelation de laration jFun tion de laration:Data de laration := Type onstrID Type varID1 : : : Type varIDn= Constr de laration1 0j0 : : : 0j0 Constr de larationm:Constr de laration = Data onstrID Simple type expr1 : : : Simple type exprn:Simple type expr := Type varID j Simple type appl:Simple type appl := Type onstrID Simple type expr1 : : : Simple type exprn:ExtRelation de laration := Ext relationID :: Type expr:IntRelation de laration := Int relationID :: Type expr:Fun tion de laration := Fun tionID :: Type expr:Type expr := Type varID j Type appl:Type appl := Type onstrID Type expr1 : : : Type exprn j (Type expr! Type expr) j(Type expr) Type expr):In the previous table, we have shown the type syntax whi h is similar to otherlanguages, su h as CURRY and TOY. In the type de laration, two dierent no-tations are used for fun tional types: a ! b and a ) b. The rst ase is theusual fun tional type, and the se ond one is a spe ial fun tional type denotingthat this argument is exible, whi h means that the a tual parameters an beonly rigid expressions (i.e. left-most symbol annot be a variable). Our idea isto avoid the extensively sear h of fun tional values allowed in some higher orderlanguages, and thus the programmer an note his wishes about the using modeof this fun tions.The syntax of the rest of modules is shown in the following table. The base andderived relations an use omplex terms in its denition in the form of patterns.A pattern is an expression without total appli ations of extensional, intensionaland fun tional symbols. Type onstrID, Type varID, Data onstrID, Data varID,Ext relationID, Int relationID and Fun tionID are identiers (starting with upperletters in the ase of variables), and the symbols in bold-font onstitute the set ofthe keywords.

Page 125: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

118 J. M. Almendros, A. Be erraRules := Base relations [Derived relations [Fun tions:Base relations := base relations Base fa t1 : : : Base fa tn end base relations:Base fa t := Ext relationID Expression1 : : : Expressionn 0 :=0 Expression:Derived relations := derived relations Derived fa t1 : : : Derived fa tnend derived relations:Derived fa t := Int relationID Expression1 : : : Expressionn 0 :=0 Expression [( Conditions:Expression := Data varID j Data onstrID Expression1 : : : Expressionn jFun tionID Expression1 : : : Expressionn jExt relationID Expression1 : : : Expressionn jInt relationID Expression1 : : : Expressionn:Conditions := Condition1 : : : Conditionn:Condition := Expression ./ Expression j Expression 6./ Expression j Expression <> Expression jExpression <=> Expression:Fun tions := fun tions Fun tion def1 : : : Fun tion defn end fun tions:Fun tion def := Fun tionID Expression1 : : : Expressionn 0 :=0 Expression [( Conditions:Query := query Conditions end query:Next, we show the typi al example of the \an estor" and, as you an see,INDALOG has a fun tional syntax and thus base and derived relations an berepresented by means of fun tions. This fun tions an have onditions in the formof joinability equalities [7 whose semanti s is to represent the same onstru torterm. Moreover, the joinability equality an be also used in the queries like in thisexample.type person = frank j john j mary j mi hael j thomasparent :: person! person:an :: person! person:endtype:base relations parent john := mary: parent john := frank:parent mary := thomas: parent frank := mi hael:end base relation:derived relations an X := parent X: an X := an (parent X):end derived relations:query an john ./ X:end query:In the rest of se tions, we will explain more in detail the INDALOG features,but now we want to explain brie y why three kind of de larations are onsidered:base, derived relations and fun tions. It is assumed that for a given query, thelanguage will generate, at ompile-time and automati ally, indi es in order toobtain a more eÆ ient evaluation. These indi es will be only generated for thebase and derived relations. The base relations will be stored at ompile-timeand the derived relations at run-time, both in se ondary memory. The indexing riteria will be based on the query and the form of the rules to be used in thequery solving. In the previous example, we requested the john's an estors, andthus the relation an will be indexed by its unique argument in order to improvethe retrieval of su h values. Moreover, the fun tion an uses the fun tion parentin its denition and thus parent will be also indexed by its (only) argument.Intuitively, for ea h all to the fun tion an , then the orresponding value forparent and the an estors of the value obtained from parent must be a essed.2.1 Handling of Negation in INDALOGThe in orporation of negation supposes to study its semanti s foundations. In[11, a framework alled Constru tor Based ReWriting Logi with Failure (CR-WLF) has been presented, extending the CRWL semanti s [7, and allowing tohandle negative information in fun tional-logi programming. In this framework,the negation is intended as 'nite failure' of redu tion. CRWLF provides four kindsof operators: (a) ./ (joinability onstraint) and (a') 6./ (its logi al negation), and(b) <> (divergen e onstraint) and (b') <=> (its logi al negation). As semanti s,

Page 126: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

INDALOG: A De larative Dedu tive Database Language 119we adopt CRWLF and thus these onstraints an be in luded in any database. Anoperational semanti s based on bottom-up evaluation extended for the handlingof negation has been studied in [2, a ording to [11.Next, we show an example of database whi h in ludes resear hing heads, boss,and departments, dept, as extensional database, and a re ursive rule superboss asintensional one whi h allows to ompute ea h hierar hy line for a given resear her.type person = john j mary j peter j thomas:depart = s j ele t:boss :: person! person:dept :: person! depart:superboss :: person! person:endtype:base relations boss john := mary: boss john := thomas:boss mary := peter:dept john := s: dept mary := ele t:dept peter := s: dept thomas := s:end base relation:derived relations superboss P := boss P :superboss P := superboss boss P:end derived relations:query superboss X 6./ john; dept X 6./ s:end query:In the query, the obtained values for superboss are ompared with john andone value X=mary (not belonging to the department s) satisfying the query isfound.2.2 Higher OrderOther feature of the language INDALOG is the use of higher-order. Higher orderprogramming has been widely studied in the fun tional logi paradigm oering ari h expressivity power by allowing, among others, more abstra tion and reuse inthe ode. The higher-order example for XSB presented in the introdu tion an bealso written in our language, given that we an use higher-order patterns in thehead and body of both intensional and extensional part:type benefit name = free ar j health inst j life ins j long va ations:benefit type = optional j required:person = bob j john:pa kage1 :: benefit name! benefit type:pa kage2 :: benefit name! benefit type:benefits :: person! (benefit name! benefit type):end type:base relations pa kage1 health ins := required: pa kage1 life ins := optional:pa kage2 health ins := required: pa kage2 free ar := optional:pa kage2 long va ations := optional:benefits john := pa kage1: benefits bob := pa kage2:end base relations:query benefits john ./ F; F X ./ Y:end query:The query will obtain the following answers F = pa kage1; X = health ins; Y =required and F = pa kage1; X = life ins; Y = optional.2.3 Grouping PrimitivesOur idea is to in lude primitives in INDALOG for olle ting answers for a givenquery whi h an be either a set or a multiset. For this reason we onsider twokinds of primitives: one onsidering the answers as a set and the other one asa multiset. The set primitives are set and set at least? and the syntax is asfollows: set n var query set at least? n var querywherein n is a natural number, var is a variable, and query is a set of onditions.The primitive set is a fun tion whi h obtains the n-th answer (as set) for the

Page 127: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

120 J. M. Almendros, A. Be erravariable var of query. There is a restri tion: the variable spe ied by the argu-ment var an only appear in query. Otherwise a renaming of variables will bea omplished. Moreover, this argument annot be instantiated, only indi ates thevariable for whi h values must be omputed. This primitive is similar to mostProlog system's primitive setof(var,goal,list), but with a relevant dieren e.In order to leave to the programmer the de ision about what kind of data stru -ture is used to store the answers of the query (list, tree, et ), the INDALOGprimitive set returns the solutions on e at time. By iterating the ounter n oftype nat, we an obtain the (partial or omplete) set of solutions for the query tobe stored in the wished stru ture. This stru ture an represent a possibly innitedata in the ase of innite solutions, whi h an ni ely be managed in fun tionallogi programming.For instan e, w.r.t. the an estor database, the following primitive all set 2 X(an john ./ X) will ompute the se ond answer for the variable X in the queryan john ./ X. In this ase, the answer will be thomas or mi hael depending onthe order whi h the answer is omputed in. In addition, we will need other setprimitive, named set at least?, whi h is a boolean fun tion and returns truewhenever there exist at least n solutions for var in the query. For instan e, theprimitive all set at least? 2 X (an john ./ X) will ompute true.From a theoreti al point of view (implementation details apart), set at least?will return true whether there exists the n-th answer, or fail, whenever there notexist more than n answers, and set will return the n-th answer or will be un-dened, respe tively. In order to know if a query has no more than n answers,we have to pro eed as follows: we have to nd all the solutions of the query(whi h must be less than n) and to refute the query for the rest of values. Aquery is refuted whether the omplementary of any onstraint an be proved.For instan e, set 4 (an john ./ X) fails be ause an john ./ mary; an john ./peter; an john ./ thomas; an john 6./ john. In some ases, there an be neitherproved nor refuted the satisability of the query for some value, and thus set andset at least? an remain undened. In the ase of removing an X := parent Xof the an estor example, neither an john ./ mary nor an john 6./ mary an beproved and the same for the rest of values, due to an is undened, and thusset 1 (an john ./ X); set at least? 1 (an john ./ X) are also undened.As a ni e example of its use, in the above an estor database is the denitionof the fun tion an estors whi h allows to olle t all an estors of a person in apossibly innite list:type list(A) = [ j [Ajlist(A): olle t list an :: person! nat! list(person):an estors :: person! list(person):end type:derived relations olle t list an Y N := [set N X (an Y ./ X) j olle t list an Y (N+ 1)( set at least? N X (an Y ./ X) ./ true: olle t list an Y N := [( set at least? N X (an Y ./ X) 6./ true:an estors X := olle t list an X 1:end derived relations:query an estors john ./ L:end query:The ontrol established by the primitive set at least? in the denition rule of olle t list an Y N will allow us to ontrol the number of solutions of the queryand therefore the end of the list to be build. In su h a way that all omputed an-swers are olle ted in the list and the query will obtain all john's an estors, that isL = [mary; frank; thomas; mi hael (or even L = [frank; mary; mi hael; thomas).

Page 128: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

INDALOG: A De larative Dedu tive Database Language 121With respe t to the multiset primitives, we will in lude two primitives, alledbag and bag at least?, with the syntax: bag n var query and bag at least?n var query wherein n is natural number, var is a variable, and query is a set of onditions. The meaning of these primitives is similar to the primitives set andset at least? but onsidering the solutions as a multiset.Finally, we will show the use of these four primitives together with the higher-order features to generate aggregation operations. For instan e, suppose the fol-lowing INDALOG database:type person = frank j john j mary j mi hael j thomas:list(A) = [ j [Ajlist(A):parent :: person! person:salary :: person! nat:an :: person! person: olle t salary list :: person! nat! list(nat):salary sum :: person! nat:fold :: (A! B! A)! A! list(B)! A:sum list :: list(nat)! nat:endtype:base relations parent john := mary: parent mary := thomas:parent john := frank: parent frank := mi hael:salary john := 2500: salary mary := 3000:salary thomas := 1200: salary frank := 2500:salary mi hael := 1200:end base relation:derived relations an X := parent X: an X := an (parent X): olle t salary list X N :=[bag N Y (salary (an X) ./ Y) j olle t salary list X (N+ 1)( bag at least? N Y (salary (an X) ./ Y) ./ true: olle t salary list X N := [( bag at least? N Y (salary (an X) ./ Y) 6./ true:salary sum Y := sum list ( olle t salary list Y 1):end derived relations:fun tions fold F Z [ := Z: fold F Z [XjL := fold F (F Z X) L:sum list L := fold + 0 L:end fun tions:query salary sum john ./ Y:end query:This example allows us to ompute the sum of all salaries of john's an estors.Firstly, we dene, in a re ursive way, a olle tor, named olle t salary list Z N,whi h olle ts all salaries in a list. Se ondly, we use a manipulating fun tion,named sum list, dened by using the higher-order fun tion fold. Finally, inorder to obtain the a umulated sum, we dene the fun tion salary sum Y byapplying sum list to the list obtained from olle t salary list Y 1. The pro-posed query salary sum john ./ Y will obtain as answer Y = 7900 euros.2.4 IndexingWith respe t to the indexing pro ess, our idea is, given an INDALOG database,to generate automati ally the set of indi es ne essary for the query solving. Theseindi es will be reated on base and derived relations of the database taking intoa ount the query. With this aim, the indexing pro ess will dete t the set of 'join'operations ne essary for the query solving. Next, onsider a database as follows:type person = john j peter j rose:job name = omputer j tea her:age :: nat! person! nat:job :: nat! job name:eq 23 :: nat! person! job name:end type:base relations age 10 john := 23: age 11 peter := 24:age 20 john := 23: age 21 rose := 21:age 22 peter := 25: job 10 := omputer:job 11 := tea her: job 20 := tea her:job 21 := omputer: job 22 := tea her:end base relations:

Page 129: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

122 J. M. Almendros, A. Be erraderived relations eq 23 ID Name := Job( age ID Name ./ 23; job ID ./ Job:end derived relations:query eq 23 X Y ./ Z:end query:Taking into a ount this query, the indexing pro ess will start analyzing thedenition rules for the fun tion eq 23, and it will dete t a 'join' operation inthe onditions due to the variable ID shared by the fun tions age and job.Therefore, the indexing pro ess will generate the following ompilation dire tivesindex age(ID; Name;Result)(ID) and index job(ID;Result)(ID) where Re-sult denotes the result of the relation. Here, two indi es have been reated, onefor the fun tion age indexing by the argument ID and other one for the fun tionjob with the argument ID.Now, suppose the query eq 23 X john ./ Z wherein the se ond argument of thefun tion eq 23 is instantiated by the value john. In this ase, the indexing pro esswill generate the ompilation dire tives index age(ID; Name;Result)(Name; ID)and index job(ID;Result)(ID). A multi-attribute (i.e. Name and ID) index isgenerated for the fun tion age due to the instantiated variable in the query, andtherefore also instantiated in the fun tion age, as well as the 'join' operationo urring in the onditions of the rule for the fun tion eq 23. The index for thefun tion job is the same than the previous one.By onsidering the query eq 23 X Y ./ tea her, the instantiated value is re-ferred to the result from the fun tion eq 23. Then, there exist two 'join' operations:(1) variable Job shared by the fun tions eq 23 and job and (2) variable ID sharedby the fun tion age and job. Therefore, two indi es will be generated by meansof the dire tives index age(ID; Name;Result)(ID) and index job(ID;Result)(Result; ID). Here a multi-attribute index (primary key isResult and se ondaryone is ID) will be generated for the fun tion job in order to retrieve ea h ID forevery tea her.Finally and with respe t to the omplex terms, the indexing pro ess will allowto generate indi es on the arguments of a omplex term but never on non basi types. For instan e, given the omplex term address in the following fun tionperson(ID; address(Name; City); Age), then the indexing pro ess ould generate ompilation dire tives for indi es on Name or City, or reate a multi-attributeindex on both Name and City.To put an end, remark that in order to implement the indexing pro ess, wewill use the typi al indexing stru tures implemented in the database ontext,that is hash index for main memory relations and B-trees for relations stored inse ondary memory.3 Foundations of INDALOGIn this se tion we will present the semanti foundations of our language. We haveadopted the Constru tor based Rewriting Logi with Failure (CRWLF) presentedin [11 as semanti framework of INDALOG given that the ited semanti s allowsto provide meaning to fun tional logi programming with negative onstraints.CRWLF extends the Constru tor Based Rewriting Logi presented in [7, whereinthe negation is intended as 'nite failure' of redu tion. The onditions that areprovable in CRWL an also be proved in CRWLF but, in addition, CRWLF pro-vides 'proofs of unprovability' within CRWL. In general, the unprovability is not omputable whi h means that CRWLF an only give an approximation to failurein CRWL that orresponds to the ases in whi h unprovability refers to 'nite

Page 130: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

INDALOG: A De larative Dedu tive Database Language 123failure' of redu tion. Here, we are interested in the presentation of an alternative hara terization of the CRWLF semanti s (and therefore equivalent) by using CR-WLF Herbrand algebras and models. From now on we restri t our presentationto the rst-order fragment of the language.3.1 BasisWe assume a signature = DC [DS where DC = Sn2INDCn is a set of on-stru tor symbols ; d; : : : and DS = Sn2INDSn is a set of dened symbols f; g; : : :,all of them with asso iated arity and su h that DC \ DS = ;. Dened symbols onsist of three sets ES of extensional symbols, IS of intensional symbols and FSof fun tion symbols: DS = ES [ IS [ FS. We also assume a ountable set V ofvariable symbols X;Y; : : :. We write Term for the set of (total) terms e; e0 (also alled expressions) built up with and V in the usual way, and we distinguishthe subset CTerm of (total) onstru tor terms or (total) -terms t; s; : : :, builtup only with symbols of DC and V . Terms intend to represent possibly redu ibleexpressions, whereas -terms represent data values, not further redu ible. Terms orrespond with rst-order expressions and CTerms with rst-order patterns inthe rst-order fragment of the language. We extend the signature by addingtwo new onstants: the onstant ? that plays the role of undened value and thenew onstant symbol F that will be used as an expli it representation of failure ofredu tion. The set Term? of partial terms and the set CTerm? of partial -termsare dened in a natural way. Partial -terms represent the result of partially evalu-ated expressions, and thus they an be onsidered as approximations to the valueof expressions. Moreover, we will onsider the orresponding sets Term?;F andCTerm?;F. A natural approximation ordering over CTerm?;F an be dened asthe least partial ordering satisfying: ? t, X X and h(t1; :::; tn) h(t01; :::; t0n),if ti t0i for all i 2 f1; :::; ng, h 2 DC [ DS. The intended meaning of t t0 isthat t is less dened or has less information than t0. Note that the only relationssatised by F are ? F and F F. In parti ular, F is maximal. This is reason-able, sin e F represents `failure of redu tion' and this gives a no further renableinformation about the result of the evaluation of an expression.3.2 INDALOG Semanti sA onditional rewrite rule for a dened symbol f 2 DSn is of the form:f(t1; :::; tn)| z head := r|zbody ( C|z onditionwhere (t1; :::; tn) is a linear tuple (ea h variable in it o urs only on e) witht1; :::; tn 2 CTerm; C is a set of onstraints of the form e0 ./ e00 (joinability),e0 <> e00 (divergen e), e0 6./ e00 (failure of joinability) or e0 <=> e00 (failure ofdivergen e); r; e and e0 belong to the set T whi h onsists of terms built from, V , set(n;X;C), set at least?(n;X;C), bag(n;X;C) and bag at least?(n;X;C)where n = 0; su k(0), k > 0, X 2 V and C is a ondition. We impli itly supposethat 0; su ; true 2 DC. Extra variables are not allowed, i.e. var(r) [ var(C) var(t). The reading of the rule is: f(t1; :::; tn) redu es to r if the ondition C issatised.The meaning of the onditions is as follows: e ./ e0 (joinability): e and e0 an beboth redu ed to some t 2 CTerm;e <> e0 (divergen e): e and e0 an be redu edto some (possibly partial) -terms t and t0 having a DC- lash; e 6./ e0: failure ofe ./ e0 and e <=> e0: failure of e <> e0, where given set of onstru tor symbols S,

Page 131: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

124 J. M. Almendros, A. Be errawe say that the -terms t and t0 have a S- lash if they have dierent onstru torsymbols of S at the same position.We will use the symbol to refer to any of the onstraints ./;<>; 6./;<=>. The onstraints 6./ and ./ are alled the omplementary of ea h other; the same holdsfor <=> and <>, and we write e for the omplementary of . The meaning of the onstraint ee0 depends on ertain synta ti (hen e de idable) relations betweenthe orresponding approximations for e and e0 and is dened as follows.Denition 1 (Relations over CTerm?;F [11). t # t0 ,def t = t0; t 2 CTerm t " t0 ,def t and t0 have a DC- lash t 6# t0 ,def t or t0 ontain F as subterm, or they have a DC- lash 6" is dened as the least symmetri relation over CTerm?;F satisfying:i) X 6" X, for all X 2 Vii) F 6" t, for all t 2 CTerm?;Fiii) if t1 6" t01; :::; tn 6" t0n then (t1; :::; tn) 6" (t01; :::; t0n), for 2 DCnWhen using rules to derive statements, we will need to use what are alled -instan es of su h rules. The set of -instan es of a rule R is dened as [R?;F =fR j 2 CSubst?;Fg, where we use substitutions CSubst?;F = f : V !CTerm?;Fg.Now, we present CRWLF-Herbrand algebras and models. We assume thereader has familiarity with basi on epts of model theory on logi programmingand fun tional-logi programming (see [3, 7 for more details). Now, we point upsome of the notions used in this paper.Given S, a partially ordered set (in short, poset) with bottom ? (equipped witha partial order and a least element ?), the set of all totally dened elements ofS will be noted Def(S). We write C(S ), I(S ) for the sets of ones and ideals of S,respe tively. The set S =def I(S ) denotes the ideal ompletion of S, whi h is also aposet under the set-in lusion ordering , and there is a natural mapping for ea hx 2 S into the prin ipal ideal generated by x, < x >=def fy 2 S : y xg 2 S .Furthermore, S is a po (i.e. every dire ted set D S has a least upper bound)whose nite elements are pre isely the prin ipal ideals < x >; x 2 S .Denition 2 (Herbrand Algebras). For any given signature , a Herbrandalgebra H is an algebrai stru ture of the form H = (CTerm?;F; ffHgff2DSg)where CTerm?;F is a poset with the approximation ordering and fH 2 [CTerml?;F!n CTerm?;F for f 2 DS l , where [D !n E =def ff : D ! C(E )j 8 u; u 0 2D : (u u 0 ) f (u) f (u 0))g. From the set ffHgff2DSg, we an distinguish thedeterministi fun tions f 2 DSn, holding that fH 2 [CTermn?;F !d CTerm?;Fwhere [D !d E =def ff 2 [D !n E j 8 u 2 D : f (u) 2 I(E )g. The elements ofDef(H) are the elements of CTermF.Given a Herbrand algebra H, a valuation over H is any mapping : V !CTerm?;F, and we say that is totally dened i (X ) 2 Def (H) for all X 2 V .We denote by Val(H) the set of all valuations, and by DefVal(H) the set of alltotally dened valuations.Denition 3 (Satisfa tibility). Let H be a Herbrand algebra, we say that:1. H satises a joinability e ./ e 0 under a valuation (in symbols, (H; ) j= e ./e 0) i there exist t 2 [jejH\CTerm?;F and t0 2 [je 0jH\CTerm?;F su h thatt # t0.

Page 132: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

INDALOG: A De larative Dedu tive Database Language 1252. H satises a divergen e e <> e 0 under a valuation (in symbols, (H; ) j=e <> e 0) i there exist t 2 [jejH \ CTerm?;F and t0 2 [je 0jH \ CTerm?;Fsu h that t " t0.3. H satises a failure of joinability e 6./ e 0 under a valuation (in symbols,(H; ) j= e 6./ e 0) i for every t 2 [jejH \ CTerm?;F and t0 2 [je 0jH \CTerm?;F, then t 6# t0 holds..4. H satises a failure of divergen e e <=> e 0 under a valuation (in symbols,(H; ) j= e <=> e 0) i for every t 2 [jejH \ CTerm?;F and t0 2 [je 0jH \CTerm?;F, then t 6" t0 holds..5. H satises a ondition C under a valuation (in symbols, (H; ) j= C) if(H; ) j= ee0 for every ee0 2 C.6. H satises the failure of a ondition C under a valuation (in symbols,(H; ) j= :C) if (H; ) j= e~e0 for any ee0 2 C.Satisfa tibility of onstraints ( ases from (1) to (4)) is expressed by meansof the relations over terms dened in denition 1. Cases (5) and (6) expresssatisfa tibility of a ondition C and the failure of a ondition C, respe tively,whi h take into a ount that :C e1ee01 _ : : : _ en ee0n, whenever C e1e01 ^: : : ^ ene0n.Denition 4 (Herbrand Denotation). The evaluation of an e 2 T?;F in Hunder yields [jejH 2 C(CTerm?;F) whi h is dened re ursively as follows:1. [j?jH =def< ? >, [jFjH =def< F > and [jX jH =def< (X ) >, for X 2 V.2. [j (e1 ; : : : ; en)jH =def< ([je1 jH; : : : ; [jen jH) > for all 2 DC n .3. [jf (e1 ; : : : ; en)jH =def f H([je1 jH; : : : ; [jen jH), for all f 2 DSn .4. [jset(n;X;C)jH =def< n(X) > if ard(Ans) [n, otherwise[jset(n;X;C)jH =def< ? >, where Ans = fi(X) j (H; i) j= Cg.5. [jbag(n;X;C)jH =def< n(X) > if ard(Ans) [n, otherwise[jbag(n;X;C)jH =def< ? >, where Ans = ffi(X) j (H; i) j= Cgg.6. [jset at least?(n;X;C)jH =def< true > whenever ard(Ans) [n; and[jset at least?(n;X;C)jH =def< F > whenever ard(Ans) < [n and forevery valuation either holds (H; ) j= C or (H; ) j= :C, otherwise[jset at least?(n;X;C)jH =def< ? > where Ans = fi(X)j(H; i) j= Cg7. [jbag at least?(n;X;C)jH =def< true > whenever ard(Ans) [n; and[jbag at least?(n;X;C)jH =def< F > whenever ard(Ans) < [n and forevery valuation either holds (H; ) j= C or (H; ) j= :C, otherwise[jbag at least?(n;X;C)jH =def< ? > where Ans = ffi(X)j(H; i) j=Cggwhere ff gg denotes a multiset of elements, ard the ardinal of a set (multiset),[n the value of n as natural number.Due to non-determinism the evaluation of an expression yields a one ratherthan an element. It an be proved that given a Herbrand algebra H, for anye 2 Term?;F and 2 Val(H), then [jejH 2 I(CTerm?;F) if f H is deterministi for every dened fun tion symbol f o urring in e, and [jejH 2 I(CTermF) ife 2 TermF and 2 DefVal(H).Set and bag primitives denote the n-th answer of the ondition C if there exists,otherwise are undened. Set at least? and bag at least? denote true whenever thereare at least n answers of the ondition C, and failure whether there are less thann answers whi h an only be ensured ( ases (6) and (7)) whenever every valuationeither satises the ondition or the failure of the ondition.

Page 133: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

126 J. M. Almendros, A. Be erraDenition 5 (Poset of Herbrand Algebras). We an dene a poset withbottom over the Herbrand algebras as follows: given A and B, A B i fA(t1;: : : ; tn) fB(t1; : : : ; tn) for every f 2 DSn and ti 2 CTerm?;F; 1 i n.It an be proved that the ideal ompletion of this poset is a po, alled HALG,and [j j is ontinuous w.r.t. HALG.Denition 6 (Herbrand Models). Let H be a Herbrand algebra: H satises a rule f (t) := r ( C i1. every valuation su h that (H; ) j= C veries [jf (t)jH [jr jH2. every valuation su h that, for some i 2 f1; : : : ; ng, li and ti have aDC [ fFg- lash, where li 2 [jsi jH, veries F 2 [jf (s)jH3. every valuation su h that (H; ) j= :C veries F 2 [jf (t)jH H is a model of a set of rules R1; : : : ; Rn (in symbols, H j= R1; : : : ; Rn) i Hsatises every Ri.Rules an either provide approximations to the value of a fun tion ( ase (1))or fail values ( ases (2) and (3)). A rule provides fail values whenever either auni ation ( ase (2)) or a ondition ( ase (3)) failure o urs.Denition 7 (Fix Point Operator). Given a Herbrand algebra A, and f 2DS, we dene the x point operator as:TP(A; f)(s1; : : : ; sn) =def f [jrjA j if there exist f(t) := r ( C; and 2 V al(A)su h that si 2 [jtijA and (A; ) j= Cg[ f F j if there exists f(t) := r ( C;su h that for some i 2 f1; : : : ; ng ;si and ti have a DC [ fFg lashg[ f F j if there exist f(t) := r ( C; and 2 V al(A)su h that si 2 [jtijA and (A; ) j= :Cg[ f ? j otherwisegIn ea h step of the x point operator appli ation a set of approximation values(due to the non-determinism) is omputed: in luding ? when the rule annot beused and F when uni ation or ondition failures o ur.Given A 2 HALG, there exists a unique B 2 HALG denoted by TP(A)su h that fB(t1; : : : ; tn) = TP (A; f)(t1; : : : ; tn) for every f 2 DSn and ti 2CTerm?;F; 1 i n. With these denitions, we an ensure the following re-sult whi h hara terizes the least Herbrand model of a set of rules.Theorem 1. The x point operator TP is ontinuous and satises:1. For every A 2 HALG: A j= R1; : : : ; Rn i TP(A) A.2. TP has a least x point M = H! where H0 is the bottom in HALG andHk+1 = TP(Hk)3. M is the least Herbrand model of R1; : : : ; Rn.4 Con lusions and Future WorkIn this paper we have presented the main features of a de larative dedu tivedatabase language based on the integration of fun tional and logi paradigms.This language in ludes most relevant features onsidered in dedu tive logi lan-guages. In addition, we have shown that this language extends this lass of lan-guages by adding the typi al advantages of fun tional logi languages like lazinessand possibly innite data. Finally, we have shown how to use primitives in thislanguage for olle ting answers and how indexing is used for the management oflarge volume of data. As future work, on one hand, we will go towards the imple-mentation of the language, and on the other hand, to the study of an extension ofthe relational algebra for expressing the semanti s of this language as a databasequery language.

Page 134: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

INDALOG: A De larative Dedu tive Database Language 127Referen es1. J. M. Almendros-Jimenez and A. Be erra-Teron. A Framework for Goal-Dire tedBottom-Up Evaluation of Fun tional Logi Programs. In Pro . of FLOPS, LNCS2024, pages 153169. Springer, 2001.2. J. M. Almendros-Jimenez, A. Be erra-Teron, and J. San hez-Hernandez. A Com-putational Model for Funtional Logi Dedu tive Databases. In Pro . of ICLP. Toappear, LNCS. Springer, 2001.3. K. R. Apt. Logi programming. In Handbook of Theoreti al Computer S ien e,volume B: Formal Models and Semanti s, hapter 10, pages 493574. MIT Press,1990.4. K. R. Apt and R. N. Bol. Logi Programming and Negation: A Survey. JLP,19,20:971, 1994.5. C. Beeri and R. Ramakrishnan. On the Power of Magi . JLP, 10(3,4):255299,1991.6. W. Chen, M. Kifer, and D. S. Warren. HiLog: A Foundation for Higher-Order Logi Programming. JLP, 15:187230, 1993.7. J.C. Gonzalez-Moreno, M.T.R. Hortala-Gonzalez, F. Lopez-Fraguas, andM. Rodrguez-Artalejo. An Approa h to De larative Programming Based ona Rewriting Logi . JLP, 1(40):4787, 1999.8. M. Hanus. Curry, An Integrated Fun tional Logi Language, Version 0.7. Te hni alreport, University of Kiel, Germany, 2000.9. D. Kemp, D. Srivastava, and P. Stu key. Bottom-up Evaluation and Query Opti-mization of Well-Founded Models. TCS, 146:145184, 1995.10. F. J. Lopez-Fraguas and J. San hez-Hernandez. T OY: A Multiparadigm De larativeSystem. In Pro s. of RTA, LNCS 1631, pages 244247. Springer, 1999.11. F. J. Lopez-Fraguas and J. San hez-Hernandez. Proving Failure in Fun tional Logi Programs. In Pro . of the CL, LNCS 1861, pages 179193. Springer, 2000.12. R. Ramakrishnan. Magi Templates: A Spellbinding Approa h to Logi Programs.JLP, 11(1,2):189216, 1991.13. R. Ramakrishnan, D. Srivastava, and S. Sudarshan. CORAL - Control, Relationsand Logi . In Pro . of VLDB, pages 238250. Morgan Kaufmann, 1992.14. R. Ramakrishnan, D. Srivastava, S. Sudarshan, and P. Seshadir. The CORAL De-du tive Database System. VLDB, 3(2):161210, 1994.15. R. Ramakrishnan, D. Srivastava, S. Sudarshan, and P. Seshadri. Implementation ofthe CORAL Dedu tive Database System. In Pro . of the ACM SIGMOD Interna-tional Conferen e on Management of Data, pages 167176. ACM Press, 1993.16. R. Ramakrishnan and J. Ullman. A Survey of Dedu tive Database Systems. JLP,23:126149, 1995.17. K. Ross. Modular Strati ation and Magi Sets for Datalog Programs with Negation.ACM, 41(6):12161266, 1994.18. K. F. Sagonas, T. Swift, and D. S. Warren. XSB as an EÆ ient Dedu tive DatabaseEngine. In Pro . of ACM SIGMOD International Conferen e on Management ofData, pages 442453. ACM Press, 1994.19. S. Sudarshan and R. Ramakrishnan. Optimizations of Bottom-up Evaluation withNon-Ground Terms. In Pro . of ILPS, pages 557574. MIT Press, 1993.20. J. D. Ullman. Bottom-up Beats Top-down for Datalog. In Pro . of PODS, pages140149. ACM Press, 1989.21. J. Vaghani, K. Ramamohanarao, D. B. Kemp, Z. Somogyi, P. J. Stu key, T. S. Leask,and J. Harland. The Aditi Dedu tive Database System. VLDB, 3(2):245288, 1994.22. A. van Gelder, K. Ross, and J. S hlipf. The Well-Founded Semanti s for GeneralLogi Programs. ACM, 38(3):620650, 1991.23. U. Zukowski and B. Freitag. The Dedu tive Database System LOLA. In Pro . ofLPNMR, LNAI 1265, pages 375386. Springer, 1997.

Page 135: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 136: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A De larative Debugger of Wrong Answers forLazy Fun tional Logi ProgramsRafael Caballero and Mario Rodrguez-Artalejo ?E-mail: frafa,mariogsip.u m.esDepartamento de Sistemas Informati os y Programa ion,Universidad Complutense de MadridAbstra t. We present a de larative debugger for lazy fun tional logi programs with polymorphi type dis ipline. Debugging is performed bysear hing in a omputation tree whi h is a logi al representation of the omputation. Following a known te hnique, our tool is based on a pro-gram transformation: transformed programs return omputation treesalong with the results expe ted by sour e programs. Our translation isprovably orre t w.r.t. well-typing and program semanti s. As additionalimprovements w.r.t. related approa hes, we solve a previously open prob-lem on erning the use of urried fun tions, and we provide a orre tmethod for avoiding redundant questions to the user during debugging.A prototype implementation of the debugger is available. Case studiesand extensions are planned as future work.1 Introdu tionThe impa t of de larative languages on pra ti al appli ations is inhibited bymany known fa tors, in luding la k of debugging tools, whose onstru tion isre ognized as diÆ ult for lazy fun tional languages. As argued in [20, su hdebuggers are needed, and mu h of interest an be still learned from their on-stru tion and use. Debugging tools for lazy fun tional logi languages [6 areeven harder to onstru t.A promising approa h is de larative debugging, whi h starts from a omputation onsidered in orre t by the user (error symptom) and lo ates a program fragmentresponsible for the error. In the ase of ( onstraint) logi programs, error symp-toms an be either wrong or missing omputed answers [18, 8, 4, 10, 19. De lar-ative debugging has been also adapted to lazy fun tional programming [1416,11, 13, 17 and ombined fun tional logi programming [12. All these approa hesuse a omputation tree (CT) [12 as logi al representation of the omputation.Ea h node in a CT represents the result of a omputation step, whi h mustfollow from the results of its hildren nodes by some logi al inferen e. Diagnosispro eeds by traversing the CT, asking questions to an external ora le (generallythe user) until a so- alled buggy node [12 is found, whose result is erroneous, butwhose hildren have all orre t results. The user does not need to understandthe omputation operationally. Any buggy node represents an erroneous ompu-tation step, an the debugger an display the program fragment responsible forit. From an explanatory point of view, de larative debugging an be des ribedas onsisting of two stages, namely CT generation and CT navigation [15.? Work partially supported by the Spanish CICYT (proje t CICYT-TIC98-0445-C03-02/97 "TREND")

Page 137: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

130 R. Caballero, M. Rodrguez ArtalejoWe present a de larative debugger of wrong answers in lazy fun tional logi pro-grams with polymorphi type dis ipline. Following a known idea [15, 13, 17, weuse a program transformation for CT generation. We give a areful spe i a-tion of the transformation, we show its advantages w.r.t. previous related ones,and we des ribe some new te hniques whi h allow to avoid redundant questionsto the ora le during the navigation phase.The debugger has been implementedas part of the T OY system [9; a prototype version an be downloaded fromhttp://titan.sip.u m.es/toy/debug.tar.gz. Case studies and extensions of thedebugger are planned as future work.A known extension of de larative debugging is abstra t diagnosis [3, 1, leadingto equivalent bottom-up and top-down diagnosis methods whi h do not requireerror symptoms to be given in advan e. In order to be ee tively implemented,abstra t diagnosis uses abstra t interpretation te hniques to build a nite ab-stra tion of the intended program semanti s. These methods are outside thes ope of this paper.The rest of the paper is organized as follows: Se t. 2 olle ts some preliminaries,and Se t. 3 summarizes the ontributions of our work w.r.t. previous relatedpapers. Our approa hes to CT generation and navigation, with detailed expla-nations of the new ontributions, are presented in Se t. 4 and 5, respe tively.Con lusions and plans for future work are summarized in Se t. 6. Due to la k ofspa e, proofs have been limited to brief sket hes. Detailed proofs will be givenin a full version of the paper.2 PreliminariesFun tional Logi Programming (FLP for short) aims at the integration of thebest features of urrent fun tional and logi languages; see [6 for a survey. Thispaper deals with de larative debugging for lazy FLP languages su h as Curry orT OY [7, 9, whi h in ludes pure LP and lazy FP programs as parti ular ases. Inthis se tion we re all the basi fa ts about syntax, type dis ipline and de larativesemanti s for lazy FLP programs. We follow the formalization given in [5, butwe use the on rete syntax of T OY for program examples.2.1 Types, Expressions and SubstitutionsWe assume a ountable set TV ar of type variables ; ; : : : and a ountableranked alphabet TC = Sn2N TCn of type onstru tors C. The set Type of validtypes 2 Type is built as ::= ( 2 TV ar) j (C 1 : : : n) (C 2 TCn) j( ! 0). By onvention, C n abbreviates (C 1 : : : n), \!" asso iates tothe right, n ! abbreviates 1 ! ! n ! , and the set of type variableso urring in is written tvar(). A type is alled monomorphi i tvar() = ;,and polymorphi otherwise. A type without any o urren e of \!" is alled adatatype.A polymorphi signature over TC is a triple = hTC;DC; FSi, where DC =Sn2NDCn and FS = Sn2N FSn are ranked sets of data onstru tors resp.dened fun tion symbols. Ea h n-ary 2 DCn omes with a prin ipal type de -laration :: n ! C k, where n; k 0; 1; : : : ; k are pairwise dierent, i are

Page 138: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A de larative debugger of wrong answers for lazy fun tional logi programs 131datatypes, and tvar(i) f1,. . . , kg for all 1 i n (so- alled transparen yproperty). Also, every n-ary f 2 FSn omes with a prin ipal type de larationf :: n ! , where i, are arbitrary types. In pra ti e, ea h FLP program Phas a signature whi h orresponds to the type de larations o urring in P . Inthe rest of this se tion we assume some xed signature , not made expli it inthe notation.Assuming a ountable set V ar of variables, disjoint from , partial expressionse 2 Exp? have the syntax e ::=? j X j h j(e e0) where X 2 V ar; h 2 DC [FS. Expressions of the form (e e0) stand for the appli ation of e (a ting as afun tion) to e0 (a ting as an argument). As usual, we assume that appli ationasso iates to the left and thus (e0 e1 : : : en) abbreviates ((: : : (e0 e1) : : :) en). Thespe ial symbol ? (read bottom) represents an undened value. The set of datavariables o urring in e is written var(e). An expression e is alled losed ivar(e) = ;, and open otherwise. Moreover, e is alled linear i every X 2 var(e)has one single o urren e in e. Partial patterns t 2 Pat? Exp? are builtas t ::=? j X j t1 : : : tmj f t1 : : : tm where 2 DCn; 0 m n andf 2 FSn; 0 m < n. and Expressions and patterns without any o urren eof ? are alled total. We write Exp and Pat for the sets of total expressions andpatterns, respe tively. A tually, the symbol ? never o urs in a program's text;but it may o ur during debugging, as we will see.An expression e 2 Exp? is alled well-typed i there exist some type environmentT (a set of type assumptions X :: for the variables o urring in e) and sometype , su h that the type judgement T `WT e :: an be derived by means of thetype inferen e rules from Milner's type system. A well-typed expression alwaysadmits a so- alled prin ipal type (PT) that is more general than any other. Apattern whose PT determines the PTs of its subpatterns is alled transparent.See [5 for more details.Total substitutions are mappings : V ar ! Pat with a unique extension :Exp! Exp, whi h will be noted also as . The set of all substitutions is denotedas Subst. The set Subst? of all the partial substitutions : V ! Pat? is denedanalogously. We write e for the result of applying the substitution to theexpression e. As usual, = fX1 7! t1; : : : ; Xn 7! tng stands for the substitutionthat satises Xi ti, with 1 i n and Y Y for all Y 2 VnfX1; : : : ; Xng.Type substitutions, mapping type variables to types, an be dened similarly.2.2 Programs and GoalsA well-typed program P is a set of dening rules for the fun tion symbols in itssignature. Dening rules for f 2 FSn have the form(R) f t1 : : : tn| z left-hand side ! r|zright-hand side ( C|z onditionwhere LD|zlo al denitionssatisfying the following requirements:(i) t1 : : : tn is a linear sequen e of transparent patterns and r any expression.(ii) C is a sequen e of onditions e1 == e01; : : : ek == e0k, where ei, e0i areexpressions.

Page 139: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

132 R. Caballero, M. Rodrguez Artalejo from :: nat -> [natdata nat = z j su nat from N = N:from (su N)head :: [A -> A twi e :: (A -> A) -> A -> Ahead (X:Xs) = X twi e F X = F (F X)tail :: [A -> [A drop4 :: [A -> [Atail (X:Xs) = Xs drop4 = twi e twi e tailplus :: nat -> nat -> nat map :: (A -> B) -> [A -> [Bplus z Y = Y map F [ = [ plus (su X) Y = su (plus X Y) map F (X:Xs) = (F X : map F Xs)times :: nat -> nat -> nattimes z Y = ztimes (su X) Y = plus X (times X Y) % Should be plus Y (times X Y)Figure 2.2: An erroneous T OY program(iii) LD is a sequen e of statements s1 d1; : : : ; sm dm, where di are ex-pressions and si are transparent linear patterns. This is intended as a lo al, non-re ursive denition of values for new variables o urring in sm. Therefore, we re-quire that any variable in si must not o ur in t1; : : : tn, s1; : : : sj1, sj+1; : : : sm,and an o ur in dj only if j > i.(iv) There is some type environment T whi h well-types the left-hand and right-hand sides of the rule a ording to the prin ipal type of f . Moreover, T mustwell-type ea h statement o urring in C or LD, by deriving a ommon type forits two sides.Informally, the intended meaning of a rule like (R) is that a all to fun tion f an be redu ed to r whenever the a tual parameters mat h the patterns ti, andthe onditions and lo al denitions are satised. A ondition e == e0 is satisedby evaluating e and e0 to some ommon total pattern. A lo al denition s dis satised by evaluating d to some possibly partial pattern whi h mat hes s.In the on rete syntax of T OY , the symbol \=" is used in pla e of \!00 and\ 00 within dening rules. Fig. 2.2 shows a small T OY program. In addition toz and su , the signature in ludes also the predened list onstru tors [ and (:)(used in inx notation). The dening rules, having neither onditions nor lo aldenitions, are hopefully self-explanatory. The arity of ea h fun tion equals thenumber of formal parameters in its rules. In parti ular, drop4 (a fun tion whi heliminates the rst four elements of a given list) has arity 0, in spite of its type.The se ond rule for times is in orre t w.r.t. the intended meaning of times asthe multipli ation operation.Formally, the semanti s of any program an be spe ied by means of the rewrit-ing al ulus GORC from [5. There, onditions e == e0 are written as e ./ e0and alled joinability statements, while lo al denitions s d are written asd ! s and alled approximation statements. In our previous paper [2 we havepresented a simple variant of GORC (the semanti al ulus SC) whi h an be

Page 140: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A de larative debugger of wrong answers for lazy fun tional logi programs 133used to prove statements by building Abbreviated Proof Trees (APTs). 1 Resultsin [2 ensure the orre tness of de larative debugging using APTs as CTs. Nodesin APTs in lude basi fa ts of the form f tn ! t (with f 2 FSn, ti, t patterns),whi h be ome the questions asked to the ora le during the navigation phaseof debugging. In this ontext, f tn ! t is not interpreted as a lo al denition.Rather, it laims that t approximates the result returned by the fun tion allf tn. In the sequel, we write P ` ' to indi ate that the statement ' an beproved from program P in the semanti al ulus SC. As in [2, we also assumean intended model I whi h represents the intended program semanti s, given asthe set of all the basi fa ts whi h are viewed as valid by the ora le.We onsider initial goals of the form G = e1 == e01; : : : ; ek == e0k. As in logi programming, goals an in lude logi variables that may be ome bound to pat-terns when the goal is solved. A solution for G is any total substitution su hthat P ` G. A solution is valid i G is valid in the intended model, anderroneous otherwise; see [2 for a formal denition. Considering the programin Fig. 2.2, the goal head (tail (map (times N) (from X))) == Y asks for these ond element of the innite list that ontains the produ t of N by the onse -utive natural numbers starting at X. The rst two solutions omputed by theT OY system are = fN 7! z, Y 7! zg (valid) and 0 = fN 7! su z, Y 7! zg(erroneous). The valid solution fN 7! su z, Y 7! su Xg expe ted by the useris in fa t a missing answer. Diagnosing missing answers is beyond the s ope ofthis paper.3 Problems and ContributionsIn this se tion we summarize the main ontributions of this paper to the twostages of de larative debugging, namely CT generation and CT navigation.3.1 CT GenerationIn the ontext of lazy FP and FLP, two main ways of onstru ting CT's havebeen proposed. The program transformation approa h [15, 13, 17 gives rise totransformed programs whose fun tions return CTs along with the originallyexpe ted results. The abstra t ma hine approa h [1416 requires low level mod-i ations of the language implementation. Although the se ond approa h anresult in a better performan e, we have adopted the rst one be ause we nd itmore portable and better suited to a formal orre tness analysis. With respe tto other papers based in the transformational approa h, we present two main ontributions, des ribed below.Curried Fun tions: Roughly, all transformational approa hes transform thefun tions dened in the sour e program to return pairs of type (; T ree), be-ing the type of the originally expe ted result and Tree a datatype for represent-ing CTs. Moreover, the types of fun tions a ting as parameters of higher-order(shortly, HO) fun tions must be transformed a ordingly. From the viewpoint oftypes, a n-ary urried fun tion f is transformed into f 0 as follows:1 In [2 joinability statements were not onsidered for the sake of simpli ity, and ap-proximation statements were not used to represent lo al denitions in dening rules.

Page 141: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

134 R. Caballero, M. Rodrguez Artalejof :: 1 ! ! n ! ) f 0 :: 01 ! ! 0n ! ( 0; T ree)As explained in Se t. 2, n orresponds to the number of parameters expe tedby the rewrite rules in f 's denition, but an be also a HO type or a variable.For instan e, the types of the fun tions plus, drop4 and map from Fig. 2.2 (withrespe tive arities 2, 0 and 2) are translated as follows:plus::nat ! nat ! nat ) plus'::nat ! nat ! (nat, Tree)drop4::[A ! [A ) drop4'::([A ! ([A, Tree), Tree)map::(A ! B) ! [A ! [B ) map'::(A ! (B, Tree)) ! [A ! ([B, Tree)As pointed out in [13, 17, the previous approa h an lead to type errors when urried fun tions are used to ompute results whi h are taken as parameters byother fun tions. For instan e, (map drop4) is well-typed, but the nave translation(map' drop4') is ill-typed, be ause the type of drop4' does not mat h the typeexpe ted by map' for its rst parameter. More generally, the type of the resultreturned by f 0 when applied to m arguments depends on the relation betweenm and f 's arity n. For example, (map (plus z)) and (map plus) are both well-typed; when translating navely, (map' (plus' z)) remains well-typed, but (map'plus') be omes ill-typed.As a possible solution to this problem, the authors of [13 suggest to modify thetranslation in su h a way that a urried fun tion of arity n > 0 always returnsa result of type (; T ree) when applied to its rst parameter. A ording to thisidea, plus would be ome plus' :: nat ! (nat ! (nat, Tree), Tree).However, as noted in [13, su h a transformation would ause transformed pro-grams to ompute ineÆ iently, produ ing CTs with many useless nodes. There-fore, the authors of [13 wrote: "An intermediate transformation whi h only han-dles urrying when ne essary is desirable. Whatever this an be done withoutdetailed analysis of the program is under investigation". Our program transfor-mation solves this problem by translating a urried fun tion f of arity n, inton urried fun tions f 00; : : : ; f 0n2; f 0 with respe tive arities 1, 2, . . .n 1, n, andproper types. Fun tion f 0m (0 m n 2) is used to translate o urren es of fapplied to m parameters, while f 0 translates o urren es of f applied to n1 ormore parameters. For instan e, (map plus) translates into (map' plus00), usingthe auxiliary fun tion plus0 0 :: nat ! (nat ! (nat, Tree), Tree).We provide a similar solution to deal with partial appli ation of urried data onstru tors, whi h an also ause type errors in the nave approa h (think of(twi e' su ), as an example). As far as we know, the diÆ ulties with urried on-stru tors have not been addressed previously. Our approa h ertainly in reasesthe number of fun tions in transformed programs, but the extra fun tions areused only when needed, and ineÆ ient CTs with useless nodes an be avoided.A detailed spe i ation of the translation is presented in Se t. 4.Corre tness:Our program transformation is provably orre t: it preserves poly-morphi well-typing (modulo a type transformation) and program semanti s (asformalized in [5, 2). As we will see in Se t. 4, this orre tness result holds inde-pendently of the narrowing strategy hosen as goal solving me hanism. To thebest of our knowledge, previous related papers [15, 13, 17 give no orre tness

Page 142: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A de larative debugger of wrong answers for lazy fun tional logi programs 135proof for the program transformation. The author of [17, who is aware of theproblem, just relies on intuition for the semanti orre tness. He mentions theneed of a formalized semanti s for a rigorous proof. As for type orre tness, itis losely related to the treatment of urried fun tions, whi h was de ient inprevious approa hes.CT Navigation: In order to be a really pra ti al tool, a de larative debuggershould keep the number of questions asked to the ora le as small as possible. Ourdebugger uses a de idable and semanti ally orre t entailment between basi fa ts to maintain a onsistent and non-redundant store of fa ts known frompreviously answered questions. Redundant questions whose answer is entailedby stored fa ts are avoided. Details are explained in Se t. 5.4 Generation of CTs by Program TransformationIn this se tion we present the program transformation used by our debuggerand we dis uss its orre tness. Roughly, a program P is onverted into a newprogram P 0, where fun tion alls return the same results P would return, butpaired with CTs. Formally, P 0 is obtained by transforming the signature of Pinto a new signature 0, introdu ing denitions for ertain auxiliary fun tions,and transforming the fun tion denitions in luded in P . Let us onsider theseissues one by one.4.1 Representing Computation TreesA transformed program always in ludes the onstru tors of the datatype Tree,used to represent CTs and dened as follows:data Tree = void | Node funId [arg res rule [ Treetype arg, res = pValtype funId, pVal, rule = stringA CT of the form ( Node f ts t rl ts) orresponds to a all to the fun tionf with arguments ts and result t, where rl indi ates the fun tion rule used toevaluate the all, and the list ts onsists of the hildren CTs orresponding toall the fun tion alls (in the lo al denitions, right-hand side and onditions ofrl) whose a tivation was needed in order to obtain t. Due to lazy evaluation,the main omputation may demand only partial approximations of the results ofintermediate omputations. Therefore, ts and t stand for possibly partial values,represented as partial patterns; and (f ts ! t) represents the basi fa t whosevalidity will be asked to the ora le during debugging, as explained in Se t. 2.As for void, it represents an empty CT, returned by alls to fun tions whi h aretrusted to be orre t (in parti ular, data onstru tors and the auxiliary fun tionsintrodu ed by the translation). Finally, the denition of arg, res, funId, pVal andrule as synonyms of the type of hara ter strings is just a simple representation;other hoi es are possible. 22 A tually, our prototype debugger uses a more stru tured representation for arg andres, whi h is helpful to implement the entailment relation des ribed in Se t. 5.

Page 143: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

136 R. Caballero, M. Rodrguez Artalejo4.2 Transforming Program SignaturesFor every n-ary fun tion f :: 1 ! : : : ! n ! o urring in P , P 0 mustin lude an (m+ 1)-ary auxiliary fun tion f 0m for ea h 0 m < n 1, as well asan n-ary fun tion f 0, with prin ipal types:f 0m :: 01 ! : : :! 0m+1 ! ((m+2 ! : : :! n ! )0; T ree) for 0 m < n 1f 0 :: 01 ! : : :! 0n ! ( 0; T ree)Similarly, for ea h n-ary onstru tor :: 1 ! : : :! n ! o urring in P , P 0must keep with the same prin ipal type, and in lude new (m+1)-ary auxiliaryfun tions 0m (0 m < n), with prin ipal types: 0m :: 01 ! : : :! 0m+1 ! ((m+2 ! : : :! n ! )0; T ree) for 0 m < nThe type de larations above depend on a type transformation whi h onverts anytype in P 's signature into a transformed type 0. This is dened re ursively:0 = ( 2 TV ar) (C n)0 = C 0n (C 2 TCn) (! )0 = 0 ! (0; T ree)Finally, P 0 always in ludes the auxiliary fun tions dVal and lean, whose typesand denitions will be des ribed below.4.3 Dening Auxiliary Fun tionsEa h auxiliary fun tion f 0m expe ts m + 1 arguments and returns a partial ap-pli ation of f 0m+1 paired with a trivial CT. Ex eptionally, f 0n2 returns a partialappli ation of f 0. The auxiliary fun tions 0m are dened similarly, ex ept that 0n1 returns a value built with the data onstru tor .f 00X1 = (f 01X1; void) f 01X1X2 = (f 02X1X2; void) . . . f 0n2Xn1 = (f 0 Xn1; void) 00X1 = ( 01X1; void) 01X1X2 = ( 02X1X2; void) . . . 0n1Xn1 = ( Xn1; void)4.4 Transforming Fun tion DenitionsEa h dening rule f t1 : : : tn ! r ( C whereLD o urring in P is transformedinto a orresponding dening rule for f 0 in P 0. Assuming that LD onsists oflo al denitions sj dj and C onsists of onditions li == ri, the transformeddening rule is onstru ted asf 0 t01 : : : t0n ! (R; T )( : : : CLi == CRi : : :wheref : : :s0j d0j ;: : :CLi l0i;CRi r0i;: : :R r0;T Node "f" [dV al t01; : : : dV al t0n (dV al R) "f:j" ( lean [ )g #Some additional explanations are needed at this point:- t0k, s0j , d0j , l0i, r0i and r0 refer to an expression transformation (dened below)whi h onverts any e :: of signature into e0 :: 0 of signature 0.- R, T , CLi, CRi are new fresh variables, and j is the number of the rule.-The notation f: : :g # refers to a transformation of the lo al denitions explained

Page 144: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A de larative debugger of wrong answers for lazy fun tional logi programs 137below.-dVal :: A ! pVal is an auxiliary impure fun tion without de larative meaning,very similar to dirt in [13, 17. Any all (dVal a) (read: \demanded value of a")returns a representation of the partial approximation of a's value whi h wasneeded to omplete the top level omputation. The debugger's implementation an ompute this from the internal stru ture representing a at the end of themain omputation, repla ing all o urren es of suspended fun tion alls by "_",whi h represents the undened value ?. 3 Moreover, dVal also renames all theidentiers of auxiliary fun tions f 0m resp. 0m into f resp. . In this way, theresults omputed by the transformed program are translated ba k to the originalsignature.The expression transformation e 7! e0 is dened by re ursion on e's synta ti stru ture. The idea is to transform the (possibly partial) appli ations of fun tionsand onstru tors within e, using fun tions from the transformed signature. Inorder to ensure e0 :: 0 whenever e :: , we use two auxiliary appli ationoperators:0 :: (, Tree) ! 0 F ! R where f(R,T) Fg () :: ( ! (, Tree)) ! ! F X ! R where f(R,T) F XgThese are used within e0 at those points where the appli ation of a fun tionfrom the translated signature is expe ted to return a value paired with a CT.Appli ations of higher-order variables are treated in a similar way. Formally:(X a1 : : : ak)0 = (: : : (X a01) : : : )a0k (X 2 V ar; k 0)( e1 : : : em)0 = m e01 : : : e0m ( 2 DCn; m < n; n > 0)( e1 : : : en)0 = e01 : : : e0n ( 2 DCn; n 0)(f a1 : : : ak)0 = (: : : ((0 f) a01) : : : )a0k (f 2 FS0; k 0)(f e1 : : : em)0 = fm e01 : : : e0m (f 2 FSn; n > 0; m < n 1)(f e1 : : : en1 a1 : : : ak)0 = (: : : ((f e01 : : : e0n1) a01) : : :)a0k(f 2 FSn; n > 0; k 0)Looking ba k to the onstru tion of translated dening rules, we see that thetranslated expressions t0k, s0j , d0j , l0i, r0i and r0 are intended to ensure well-typing,but ignore CTs. In parti ular, the lo al denition of T renders a CT whose roothas the proper form, but whose hildren are not yet dened. In order to ompletethe translation, the translated lo al denitions f: : :g are transformed into f: : :g #,whi h means the normal form obtained by applying the transformation rules AP0and AP1 dened below, with a leftmost-innermost strategy. AP0:f: : : ; t e[0 g; : : : T Node : : : ( lean lp)g !f: : : ; (R0; T 0) g; t e[R0; : : : T Node : : : ( lean (lp++[(dVal R0; T 0)))g AP1:f: : : ; t e[a s; : : : T Node : : : ( lean lp)g !f: : : ; (R0; T 0) a s; t e[R0; : : : T Node : : : ( lean (lp++[(dVal R0; T 0)))g3 Be ause of this repla ement of ? in pla e of unknown values, the basi fa ts o urringin proof trees must be understood as approximation statements rather than equalities.

Page 145: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

138 R. Caballero, M. Rodrguez ArtalejoIn both transformations, ``++'' stands for the list on atenation fun tion. R0 andT 0 must be hosen as new fresh variables, and t is the pattern in the lefthandside of a lo al denition whose righthand side in ludes a leftmost-innermosto urren e of an appli ation operator (0 g) or (a s) in some ontext. Be auseof the innermost strategy, we an laim: AP0 always nds a nullary fun tion symbol in pla e of g. AP1 always nds a pattern in pla e of s, and either a variable or a patternof the form g t1 : : : tn1 (with g 2 FS0n, n > 0) in pla e of a.Ea h appli ation of the AP transformations eliminates the urrently leftmost-innermost o urren e of an appli ation operator, while introdu ing a new lo aldenition for the result R0 and CT T 0 oming from that appli ation, and addingthe pair (dVal R0; T 0) to the list of hildren of T . The innermost strategy en-sures that no appli ation operators o ur in the new lo al denition. Sin e theinitial number of appli ation operators is nite, the pro ess is terminating andthe normal form always exists. When the AP transformations terminate, no ap-pli ation operators remain. Therefore, 0 and do not o ur in transformedprograms. All the o urren es of ``++'' within the righthand side of T 's lo aldenition an be removed, a ording to the usual denition of list on atenation.This leads to a list lp :: [(pVal, Tree) in luding as many CTs as appli ationoperators did o ur in the lo al denitions, ea h of them paired with a partialresult. Finally, ( lean lp) builds the ultimate list of hildren CTs, by ignoringthose pairs (pv, t) in lp su h that t is void or pv represents ?, thus remov-ing all the useless nodes from the CT. The ode orresponding to the auxiliaryfun tion lean :: [(pVal, Tree) ! Tree (whose simple denition is omittedhere) must be in luded in any transformed program.4.5 An ExampleBelow we show part of the fun tions produ ed by transforming the T OY programfrom Fig. 2.2. The on rete syntax of T OY is used here.twi e' :: (A -> (A, Tree)) -> A -> (A, Tree)twi e' F X = (R,T)where (R1,T1) = F X;(R2,T2) = F R1;R = R2;T = Node "twi e" [dVal F, dVal X (dVal R) "twi e.1"( lean [(dVal R1,T1), (dVal R2,T2)) drop4' :: ([nat -> ([nat, Tree), Tree)drop4' = (R,T)where (R1,T1) = twi e' twi e_0' tail';R = R1;T = Node "drop4" [ (dVal R) "drop4.1"( lean [(dVal R1,T1))4.6 Transforming GoalsThe debugging pro ess an be started whenever some answer answer omputedfor the goalG is onsidered erroneous by the user. In order to build a suitable CT

Page 146: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A de larative debugger of wrong answers for lazy fun tional logi programs 139for the navigation phase, an auxiliary fun tion denition solution Xn = true( G is onsidered, whose translation is automati ally added to the transformedprogram. Here, Xn are the variables o urring in G. Sin e is a solution for G,the goal solution Xn == (true, Tree) an be solved by the translated program,without instantiating any free variable in Xn, and instantiating Tree to a CTwith erroneous root. The navigation phase of the debugger pro eeds with thisCT.4.7 Corre tness ResultsWe an prove three main results about the orre tness of our program transfor-mation. The rst result on erns the type dis ipline. Thanks to it, the debuggerdoes not need to perform any type he king/inferen e before entering the CTgeneration phase.Theorem 1 The translation P 0 of a well-typed program P is always well-typed.Proof Idea. Assuming an expression e in P 's signature and a type environmentT su h that T `WT e :: , one an prove T 0 `WT e0 :: 0 for T 0 =deffXi :: 0i j (Xi :: i) 2 Tg. Using this result, and reasoning by indu tion onthe number of AP steps involved in the transformation of dening rules, it anbe proved that any well-typed dening rule for a fun tion f in P is transformedinto a well-typed dening rule for f 0 in P 0. On the other hand, the dening rulesfor auxiliary fun tions o urring in P 0 are obviously well-typed. 2The se ond result says that the translation preserves the semanti s of sour eprograms, enhan ed by the additional omputation of CTs. Re all the notationP ` f tn ! t explained in Se t. 2, whi h an be used also for transformedprograms. Intuitively, a basi fa t f tn ! t asserts that the fun tion all f tn an return a partial result t a ording to the semanti s of program P . Note alsothat the translation of a pattern t, following the denition from Subse tion 4.4,is always a pattern t0 from whi h t an be univo ally re overed.Theorem 2 For any n-ary fun tion f and arbitrary partial patterns tn, t in thesignature of a program P , it holds:1. If P 0 ` f 0 t0n ! (t0; t) then P ` f tn ! t.2. If P ` f tn ! t then there is some pattern t in P 0's signature, whi hrepresents an abbreviated proof tree proving P ` f tn ! t in the sense of[2, and su h that P 0 ` f 0 t0n ! (t0; t).Proof Idea. Abbreviated Proof Trees (APTs) were introdu ed in [2 to formalizeproofs of basi fa ts in a semanti al ulus SC. Due to the form of the inferen erules of SC, it an be he ked that an APT T whi h proves P ` f tn ! tmust be built by using some parti ular instan e of dening rule for f of the formf tn ! r ( C where LD. Moreover, the root of T must ontain f tn ! t, andthe hildren must be a list of APTs orresponding to SC proofs whi h justify thelo al denitions in LD, the onditions in C and the statement r ! t. Moreover,a areful analysis of SC's inferen e rules shows that these hildren CTs must orrespond to fun tion appli ations whi h return a partial result dierent from?, taken in leftmost-innermost order. The denition of transformed deningrules in P 0 has been designed to build pre isely su h CTs. 2

Page 147: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

140 R. Caballero, M. Rodrguez ArtalejoFinally, as a onsequen e of the previous result, the generated CT provides a orre t basis for the navigation phase:Theorem 3 Assume a program P , a wrong answer for a goal G, and a CTT obtained by running a transformed program, as explained in Se t. 4.6. ThenT has at least one buggy node, whi h in ludes an indi ation of a semanti allyin orre t instan e of a dening rule from P .Proof. Be ause of Theorem 2, T is an APT. The Corre tness Theorem from [2ensures the following: any APT whose root is erroneous always in ludes somebuggy node whose asso iated program rule instan e is not valid in the intendedmodel. 2We would like to stress the fa t that Theorem 3 holds independently of thenarrowing strategy implemented by the system used to run the transformedprogram. Although a parti ular narrowing al ulus was proposed in [2 to for-malize the onstru tion of APTs, all APTs (in parti ular, those omputed bytransformed programs) are orre t CTs for debugging. Of ourse, the narrowingstrategy ae ts the order in whi h eventual wrong answers are omputed.5 Navigating the CTs by Ora le QueryingOn e the CT asso iated to a wrong answer has been built (as des ribed inSubse tion 4.6), navigation performs a top-down traversal, asking the ora leabout the validity of the basi fa ts asso iated to the visited nodes (ex ept theroot, whi h is known to be erroneous in advan e). For the sake of pra ti alusefulness, it is important to ensure that questions asked to the ora le are asfew and as simple as possible. The se ond ondition - simpli ity - omes alongwith our hoi e of APTs as CTs, sin e basi fa ts are the minimal pie es ofinformation needed to hara terize the intended model of a program (see [2).To redu e the number of questions, the only possibility onsidered in relatedpapers is to avoid asking repeated questions. As an improvement, we presentan entailment relation between basi fa ts, and we show that it an be used toavoid redundant questions whi h an be dedu ed from previous answers.Our notion of entailment is based on the approximation ordering v, dened asthe least partial order over the set Pat? of partial patterns whi h satises:- ?v t, for any partial pattern t.- X v X, for any variable X.- h tn v h sn, if t1 v s1 : : : tn v sn, with h 2 DCm, n m or h 2 FSm, n < m.This ordering has a natural semanti interpretation: t v t0 means that t0 has atleast so mu h information as t. For instan e: (z : ?) v (z : su z : ?). Usingv, we dene: A basi fa t f tn ! t entails another basi fa t f sn ! s (writtenas f tn ! t f sn ! s) i there is some total substitution 2 Subst su hthat t1 v s1; : : : ; tn v sn; s v t.The following result justies the interest of entailment, sin e the answers givenby any ora le in de larative debugging are assumed to be valid in the intendedmodel of the program.

Page 148: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A de larative debugger of wrong answers for lazy fun tional logi programs 141Theorem 4 Entailment between basi fa ts is a de idable preorder (i.e, re ex-ive and transitive relation). Moreover, for any set I of basi statements whi hrepresents an intended model: if f tn ! t f sn ! s and f tn ! t 2 I thenf sn ! s 2 I.Proof Idea To prove de idability of entailment, we have dened a system oftransformations, somewhat similar to those used in Martelli and Montanari'suni ation algorithm. These transformations ompute the needed substitution whenever entailment holds, and they nitely fail otherwise. The fa t thatentailment is a preorder is easy to he k. The last laim of the Theorem is truebe ause the formal denitions given in [2 ensure that intended models are losedunder entailment. 2Thanks to Theorem 4, a question Q entailed by a fa t already known to bevalid be ause of some previous answer, must be valid. For instan e, if we alreadyknow that from X ! X:(su X):[ is valid then other basi fa ts entailed bythis one, su h as from z ! z:? and from (su Y) ! (su Y):(su (su Y)):[,must also be valid. Dually, a question Q whi h entails a fa t known to be invalidbe ause of some previous answer, must be invalid. For instan e, if we know froma previous answer that from z ! (su z):? is not valid, then other basi fa tsthat entail this one, su h as from X ! (su X):(su (su X)):[ must be alsoinvalid. In both ases, a question to the ora le an be avoided.Our debugger has been implemented as part of the T OY system. A prototypeversion an be downloaded from http://titan.sip.u m.es/toy/debug.tar.gz.Here we show a debugging session for our example program of Fig. 2.2. Theuser a tivates the debugger be ause the in orre t answer fN 7! su z, Y7! zghas been omputed for the goal head (tail ( map (times N) (from X))) == Y:Consider the following fa ts:1: from X ! (X:(su X):?)2: map (times (su z)) (X:(su X):?) ! (?:z:?)3: tail (?:z:?) ! (z:?)4: head (z:?) ! zAre all of them valid? ([yes / [no) / [abort) nEnter the number of a non-valid fa t followed by a fullstop: 2.Consider the following fa ts:1: map (times (su z)) ((su X):?) ! (z:?)Are all of them valid? ([yes / [no) / [abort) nConsider the following fa ts:1: times (su z) (su X) ! zAre all of them valid? ([yes / [no) / [abort) nConsider the following fa ts:1: times z (su X) ! z2: plus z z ! zAre all of them valid? ([yes / [no) / [abort) yRule number 2 of the fun tion times is wrong.Wrong instan e: times (su z) (su X) ! (plus z (times z (su X)))

Page 149: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

142 R. Caballero, M. Rodrguez ArtalejoAs shown by this example, our urrent prototype debugger sear hes the CTtop-down, using a strategy whose aim is to avoid redundant questions and togive freedom to the ora le. At any point during the sear h, the urrent node ontains an invalid statement (initially, this is true be ause the root of the CT orressponds to an error symptom dete ted by the user). The debugger buildsthe list L of the basi fa ts atta hed to the hildren of the urrent node. Ifsome member of L entails a fa t known to be invalid from some previous ora leanswer, the debugger moves to the orresponding hild and ontinues with thesame strategy. Otherwise, the debugger displays the list L for the ora le's on-sideration. If the ora le regards all the fa ts in L as valid, then the urrent nodeis buggy, and the debugger shows its asso iated program rule instan e (whi h an be omputed from the CT) as responsible for the bug. Otherwise, the ora lemust hoose some erroneous fa t in the list. The debugger adds this fa t to itsstore of invalid fa ts, moves to the orresponding hild node, and ontinues withthe same strategy.In the simple example shown above, the entailment relation is not helpful, butin more involved ases it an redu e the number of questions asked to the ora le.Note that the parti ular sear h strategy we have des ribed is su h that all theanswers provided by the ora le are negative, ex ept for the last question. Thismight not be the ase in other alternative strategies, whi h we have not yetinvestigated. Our implementation also avoids to ask questions about predenedfun tions (e.g. arithmeti operations), sin e they are trusted to be orre t. Al-lowing the user to annotate ertain fun tions to be trusted as orre t is a simplealbeit useful extension, not yet implemented.6 Con lusions and Future WorkProgram transformation is a known approa h to the implementation of de lar-ative debugging of wrong answers in lazy FLP languages [15, 13, 17. We havegiven a new, more formal spe i ation of this te hnique, whi h avoids type errorsrelated to the use of urried fun tions and preserves both well-typing and pro-gram semanti s (as formalized in [5, 2), independently of the narrowing strategy hosen as goal solving me hanism. A prototype implementation of our debuggerfor the fun tional logi language T OY [9 is available. Our implementation usesa semanti ally orre t algorithm to dete t and avoid redundant questions to theora le, thus redu ing the omplexity of debugging.In order to improve the pra ti al usefulness of our results, we have started a o-operation with Herbert Ku hen and Wolfgang Lux, to in lude a similar debuggeras a tool within the Curry [7 implementation developed at Munster University.Hopefully, this will eventually allow to evaluate the debugger on pra ti al ap-pli ations. We also plan to implement and evaluate alternative sear h strategiesfor the navigation phase. As more substantial resear h work, we plan to inves-tigate and implement extensions of the debugger, to support onstraint-based omputations as well as the diagnosis of missing answers.A knowledgementsWe are grateful to Herbert Ku hen, Pa o Lopez and Wolf-gang Lux, who have followed our work with interest and provided useful advi e.

Page 150: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A de larative debugger of wrong answers for lazy fun tional logi programs 143We are also very indebted to Mer edes Abengozar for her great help with im-plementation work.Referen es1. M. Alpuente, .J. Correa and M. Falas hi. A Debugging S heme for Fun tional Logi Programs. To appear in Pro . WFLP'2001, Kiel, Germany, September 1315, 2001.2. R. Caballero, F.J. Lopez-Fraguas and M. Rodrguez-Artalejo. Theoreti al Founda-tions for the De larative Debugging of Lazy Fun tional Logi Programs. In Pro .FLOPS'2001, Springer LNCS 2024, 170184, 2001.3. M. Comini, G. Levi, M.C. Meo and G. Vitello. Abstra t Diagnosis. J. of Logi Programming 39, 4393, 1999.4. G. Ferrand. Error Diagnosis in Logi Programming, an Adaptation of E.Y.Shapiro's Method. The Journal of Logi Programming 4(3), 177-198, 1987.5. J.C. Gonzalez-Moreno, M.T. Hortala-Gonzalez and M. Rodrguez-Artalejo.Polymorphi Types in Fun tional Logi Programming. FLOPS'1999 spe ialissue of the Journal of Fun tional and Logi Programming, 2001. Seehttp://danae.uni-muenster.de/lehre/ku hen/JFLP6. M. Hanus. The Integration of Fun tions into Logi Programming: A Survey. J.of Logi Programming 19-20. Spe ial issue \Ten Years of Logi Programming",583628, 1994.7. M. Hanus (ed.), Curry: An Integrated Fun tional Logi Language, Version 0.7,February 2, 2000. Available at http://www.informatik.uni-kiel.de/~ urry/.8. J.W. Lloyd. De larative Error Diagnosis. New Generation Computing 5(2), 133154, 1987.9. F.J. Lopez-Fraguas, J. San hez-Hernandez. T OY: A Multiparadigm De larativeSystem. In Pro . RTA'99, Springer LNCS 1631, pp 244247, 1999. Available athttp://mozart.sip.u m.es/toy.10. L. Naish. De larative Diagnossing of Missing Answers. New Generation Comput-ing, 10, 255385, 1991.11. L. Naish. De larative debugging of lazy fun tional programs. Australian ComputerS ien e Communi ations, 15(1):287294, 1993.12. L. Naish. A De larative Debugging S heme. Journal of Fun tional and Logi Pro-gramming, 1997-3.13. L. Naish, and T. Barbour. Towards a Portable Lazy Fun tional De larative Debug-ger. Australian Computer S ien e Communi ations, 18(1):401408, 1996.14. H. Nilsson, P. Fritzson. Algorithmi Debugging of Lazy Fun ional Languages. TheJournal of Fun tional Programming, 4(3):337-370, 1994.15. H. Nilsson and J. Sparud. The Evaluation Dependen e Tree as a basis for LazyFun tional Debugging. Automated Software Engineering, 4(2):121150, 1997.16. H. Nilsson. De larative Debugging for Lazy Fun tional Languages. Ph.D. Thesis.Dissertation No. 530. Univ. Linkoping, Sweden. 1998.17. B. Pope. Buddha. A De larative Debugger for Haskell. Honours Thesis, Departmentof Computer S ien e, University of Melbourne, Australia, June 1998.18. E.Y. Shapiro. Algorithmi Program Debugging. The MIT Press, Cambridge, Mass.,1982.19. A. Tessier and G. Ferrand. De larative Diagnosis in the CLP S heme. In P. De-ransart, M. Hermenegildo and J. Ma luszynski (Eds.), Analysis and VisualizationTools for Constraint Programming, Chapter 5, pp. 151174. Springer LNCS 1870,2000.20. P. Wadler. Why no one uses fun tional languages. SIGPLAN Noti es 33(8), 2327,1998.

Page 151: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 152: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Transforming Layered Specifications into

Operational Specifications

F. J. Galan and J. M. Canete

Dept.of Languages and Computer Systems. Faculty of Computer Science of Seville,

Av. Reina Mercedes 41012, Seville, Spain. E-mail: [email protected]

Abstract. A specification can describe a set of programs which are dif-

ficult to discover. The systematic construction of programs from specifi-

cations is known as program synthesis. The use of two different languages

(i.e. specification and programming languages) adds new difficulties in

order to decide about correctness criteria. A classification of the specifi-

cations based on the existence (operational specification) or not (descrip-

tive specification) of a clear trace between specifications and programs

is proposed. In this way, a synthesis process may be reconsidered as a

sequential composition of two activities: to transform specifications into

operational specifications and then to adapt operational specifications to

implementation resources. In our work, we treat only the first activity.

The language of the layered contexts is proposed to describe functional

properties of the software and establish a method which transforms de-

scriptive specifications into operational ones automatically.

1 Introduction

Abstraction and expressiveness are two key properties associated to specifica-tion languages. The following (first-order logic) specification Dnocc defines therelation symbol nocc:

Dnocc : nocc(e, empty, z) ⇔ z = 0nocc(e, conc(x, Y ), s(z)) ⇔ x = e ∧ nocc(e, Y, z)nocc(e, conc(x, Y ), z) ⇔ ¬x = e ∧ nocc(e, Y, z)

From a programming point of view, Dnocc is an abstract description of a setof (possible) programs which compute occurrences of natural elements in a se-quence. Its form is closed to the structure of a program and then we considerDnocc as an operational specification. For example, a Modula-2 programmerwould be able to propose the following (correct) implementation for Dnocc:

PROCEDURE Nocc(e:CARDINAL,s:SeqNat,VAR z: CARDINAL);

VAR w:CARDINAL;

BEGIN

IF (s=NIL) THEN z:=0

ELSIF s^.info = e THEN Nocc(e,s^.next,w); z:=w+1

ELSE Nocc(e,s^.next,z);

Page 153: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

146 F. J. Galan, J. M. Ca~neteEND

END Nocc;

On the other hand, specification languages are usually considered as expressivelanguages because they have description resources which are natural to humanthinking. The following specification defines the symbol perm in a natural way.

Dperm : perm(L, S) ⇔ (nocc(a, L, z) ⇔ nocc(a, S, z))

From a programming point of view, Dperm represents not only an abstract butan expressive description of a set of programs which compute sequence permu-tations. However, the form of Dperm is not closed to the structure of a program(i.e. there is not explicit recursion) and then we tend to consider Dperm as adescriptive specification.

Searching for new programming languages encounters an important obstacleif we are interested in abstract and expressive proposals. Program synthesisrefers to the elaboration of a program in some systematic manner starting froma specification [WBK92], [Fle95], [BiD96], [AFM99]. Among several approaches[DeK94], the deductive approach applies transformation rules directly to thespecification until a program is obtained [Par90], [SaT84]. However, the use oftwo different languages (i.e. specification and programming languages) adds newdifficulties in order to decide about correctness criteria. In this way, a synthesisprocess can be redefined as a sequential composition of two activities: to redefinespecifications into operational terms and then to adapt operational specificationsto implementation resources. We think that the synthesis core resides in the firstactivity, therefore, in this work, we are interested in transforming specificationswhich admit equivalent operational redefinitions.

Layered contexts constitute reasonable starting points to describe functionalproperties of software in an abstract and expressive way and develop automatictransformations preserving correctness. Basically, a layered context is a first-order theory divided into three parts or layers: the data layer (or layer 0) whichcontains information for data, the operational layer (or layer 1) which containsa set of operational specifications and the descriptive layer (or layer 2) whichcontains a set of descriptive specifications. Each element in a layer is definedfrom elements in the same or lower layers. In example 1, we show the layeredcontext S. Its data layer defines Nat (natural numbers) and Seq(Nat) (sequencesof natural elements) as sorts and relations which decide identities between Nat-terms (DNat,=) and Seq(Nat)-terms (DSeq(Nat),=) respectively. The operationallayer defines nocc symbol (Dnocc). The descriptive layer defines the relationsperm (Dperm) and eq (Deq) as a relation which decides a permutation-basedsequence equality.

Following, previous works [LaO94], [LaO95], [GaT98], [GaC01] we proposed amethod based on a transformation calculus which includes specialized forms forfold, unfold and substitution rules. The constructive definition of the calculus,the automatic generation of transformation plans, and the finite transformationswithin layered contexts represent key properties in order to consider our methodamenable to be compiled and to be executed in practice.

Page 154: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Transforming Layered Spe i ations into Operational Spe i ations 147Example 1.

Context SData layer

sort Nat generated by 0, s; sort Seq(Nat) generated by empty, conc;D= : 0 = 0 ⇔ true D= : empty = empty ⇔ true

s(x) = 0 ⇔ false conc(x, X) = empty ⇔ false

s(x) = s(y) ⇔ x = y conc(x, X) = conc(y, Y ) ⇔ x = y ∧ X = Y

Operational layerDnocc : nocc(e, empty, z) ⇔ z = 0

nocc(e, conc(x, Y ), s(z)) ⇔ x = e ∧ nocc(e, Y, z)nocc(e, conc(x, Y ), 0) ⇔ ¬x = e ∧ nocc(e, Y, 0)nocc(e, conc(x, Y ), s(k)) ⇔ ¬x = e ∧ nocc(e, Y, s(k))

Descriptive layerDperm : perm(L, S) ⇔ (nocc(a, L, z) ⇔ nocc(a, S, z))Deq : eq(empty, empty) ⇔ true

eq(conc(x, X), conc(y, Y )) ⇔ ∃Z((perm(nL,Z) ∧ nL = conc(x, X))⇔

(perm(Z, nS) ∧ nS = conc(y, Y )))

Our work is explained in the following manner. Section 2 establishes preliminarydefinitions. Section 3 defines layered contexts as an interesting class of formaltheories in order to apply automatic transformations. Section 4 describes themethod which transforms descriptive specifications into operational ones andsection 5 establishes conclusions.

2 Preliminary Definitions

In this section, we introduce the language for writing contexts. Basically, a con-text is a theory which defines the specification and transformation frameworks.Then, a classification of the specifications is introduced in order to characterizecontexts. We borrow from [BMM83], [LaO94] a class of models, called isoinitialmodels, as interpretation model for our contexts. The reader is assumed to befamiliar with the basic notations of the first-order theory as presented in [Llo87]and of the many-sorted logic as presented in [HL94].

Definition 1 (Syntax of a Formula). A many-sorted (typed) first-order lan-guage is assumed to write our formulas. A formula Qτ1

x1...QτnxnF where Qτi

xi

is a universal or existential quantifier defined on a type τi, xi is different from xj

for i 6= j, and F contains no quantifier, is said to be in prenex normal form. Weconsider that, when possible, all quantifiers in a formula are ordered following alexicographic order defined on the names of their respective types.

Example 2. ∀Nata∀Natz∀Seq(Nat)L∀Seq(Nat)S(nocc(a, L, z) ⇔ nocc(a, S, z)). Inthe following, we assume that all our formulas are in prenex normal form. Forlegibility reasons, we omit type subscripts when the type can be induced clearlyand expressions such as Qτx...QτzF can be collapsed to Qτx, ..., zF . In addition,when possible, universal quantifiers are omitted in the front of a formula.

Page 155: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

148 F. J. Galan, J. M. Ca~neteDefinition 2 (Substitution). A (ground) variable substitution is the pair (v, t)where v is a variable and t is a (ground) term. A substitution σ is a set ofvariable substitutions. Let X = x1, ..., xn and Y = y1, ..., yn be two sets ofvariables where xi is different from xj and yi is different from yj for i 6= j.Let QX = Qτx1

, ...,Qτxn and QY = Qτy1

, ..., Qτyn be two sets of quantifiers

for variables in X and Y respectively. We say that σ = (x1, y1), ..., (xn, yn) isa renaming substitution which agrees w.r.t. quantifications iff X ∩ Y = ∅ andQτxi

= Qτyiwith i = 1..n.

Definition 3 (Iff-axioms). An iff-axiom is a formula of the form r(X) ⇔R(Y ) where R(Y ) is any formula in the language of C and X and Y are twosets of terms. r is called the defined symbols. r(X) is called the left-hand sideof the axiom (lhs) and R(Y ) is called the right-hand side of the axiom (rhs). Arecursive iff-axiom for a relation r is an iff-axiom where some literals in R(Y )are defined on the symbol r (e.g. axioms for nocc in S). An explicit iff-axiom isa non-recursive iff-axiom (e.g. axioms for perm in S). A descriptive iff-axiomis an iff-axiom where there exists some unbounded variable v such that v ∈ Y

and v 6∈ X (e.g. axioms for perm in S). An operational iff-axiom is an iff-axiomwhere Y ⊆ X (e.g. axioms for nocc in S).

Definition 4 (Specifications and Contexts). A context C is a first-ordertheory including a set of type and relation specifications. Types are constructedfrom function symbols appearing in C. A specification Dr is the set of all axiomsin C with the same defined symbol r. In the following, we use Dr,n to identify thenth axiom in Dr. If each axiom in Dr is operational then Dr is called operationalspecification. If some axiom in Dr is descriptive then Dr is called descriptivespecification. We assume that every recursive specification is well founded. If eachaxiom in Dr is an explicit axiom then Dr is called explicit specification. If someinstances of r are not defined in Dr then Dr is called partial specification (e.g.Deq in S) else Dr is called total specification (e.g. DNat,=, DSeq(Nat),=, Dnocc

and Dperm in S). A context C is called operational iff each specification in C isoperational. C is called descriptive iff there exists some descriptive specificationin C (e.g. S). C is atomically complete if, for every ground atom r(t1, ..., tn),either C ⊢ r(t1, ..., tn) or C ⊢ ¬r(t1, ..., tn). C has isoinitial model M iff for everyground literal l, M |= l iff C ⊢ l. Therefore, the meaning of a relation r in C isthe set of all ground literals l defined on r such that C ⊢ l.

Some authors have studied the problem of the existence of isoinitial models fortheories in general [BMM83] and some effective criteria have been proposed toconstruct consistent theories. Following [LaO94], a specification context C admitsan isoinitial model if and only if it is atomically complete. By hypothesis, weassume that our contexts are consistent in this way.

3 Layered Specifications

Some preliminary definitions about term patterns and literal patterns are neededto introduce layered contexts.

Page 156: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Transforming Layered Spe i ations into Operational Spe i ations 149Definition 5 (Term Pattern). A term pattern P (t) for a term t in the lan-guage of a context C is defined inductively as follows: P (v), for a variable v, isthe set of all possible ground variable substitutions for v. P (c), for a constant c,is the set c. P (f(t1, ..., tn)), for a term f(t1, ..., tn), is the set of ground termsf(m1, ...,mn) with mi ∈ P (ti) (i = 1..n).

Example 3. P (s(x)) for s(x) in the language of S describes the set of groundterms s(0),s(s(0)), s(s(s(0)))....

Definition 6 (Relating Term Patterns). Let t and s be two terms in thelanguage of C. We say that P (t) and P (s) are variant term patterns, denoted byP (t) ∼ P (s), if there exist substitutions θ and σ such that t = sθ and s = tσ.We say P (t) is more general than P (s), denoted by P (t) > P (s), if there existsa substitution σ such that P (tσ) ∼ P (s) and there is not any substitution θ suchthat P (sθ) ∼ P (t). From a syntactical point of view, P (t) > P (s) if either s isa non-variable term and t is a variable not included in s or t = f(t1, ..., tn) ands = f(s1, ..., sn) and there exists a set of argument positions in t whose termpatterns are more general than the respective term patterns for arguments in s

and the rest of arguments represent similar term patterns.

Example 4. P (conc(x, X)) > P (conc(y, conc(v, V ))) because t1 = x, s1 = y (i.e.P (t1) ∼ P (s1)) and t2 = X, s2 = conc(v, V ) (i.e. P (t2) > P (s2)).

Definition 7 (Literal Pattern). A literal pattern P (l) for a literal l in thelanguage of C is defined as the set of all ground literals lσ where σ is a groundsubstitution.

Example 5. P (nocc(x, empty, 0)) for the literal nocc(x, empty, 0) in the languageof S describes the set of ground literals nocc(0, empty, 0), nocc(s(0), empty, 0),nocc(s(s(0)), empty, 0) ...

Definition 8 (Relating Literal Patterns). Let l and k be two literals in C.We say P (l) and P (k) are variant literal patterns, denoted by P (l) ∼ P (k), ifthere exist substitutions θ and σ such that l = kθ and k = lσ. We say thatP (l) is a literal pattern more general than P (k), denoted by P (l) > P (k), ifl = r(t1, ..., tn) and k = r(s1, ..., sn) and there exists a set of argument positionsin l whose term patterns are more general than the respective term patterns forarguments in k and the rest of arguments represent similar term patterns. We sayP (l) is a literal pattern more general than P (k) with respect to Pos argumentpositions, denoted by P (l) >Pos P (k), if and only if P (ti) > P (si) for eachi ∈ Pos.

Example 6. P (nocc(x, empty, 0)) ∼ P (nocc(y, empty, 0)) because lθ = k, kσ = l

with θ = (x, y) and σ = (y, x). P (nocc(x, L, 0)) > P (nocc(y, empty, 0))because P (x) ∼ P (y), P (0) ∼ P (0) and P (L) > P (empty). P (nocc(0, L, 0)) >2

P (nocc(y, empty, 0)) because P (L) > P (empty).

Definition 9 (Layered Contexts). Let Rel = ri (i = 1..n) be the set ofall relation symbols declared in a context C. Let Dri

= ri(Xj) ⇔ Ri,j(Yj)(j = 1..d) be the specification of any ri ∈ Rel. We say that C is layered iff

Page 157: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

150 F. J. Galan, J. M. Ca~nete1. C consists of three parts or layers. The data layer which contains sort de-

clarations and function symbols. The operational layer which contains a setof relations defined by operational specifications. The descriptive layer whichcontains a set of relations defined by descriptive and explicit specifications.

2. For each pair of axioms in a specification, their lhs’s must be either variantor disjoint literal patterns. Each atom defined on recursive symbol r andlocated in the rhs of an axiom not in Dr must be a variant literal pattern ofsome recursive atom in the rhs of some axiom in Dr. Each atom, defined ondescriptive symbol r and located in the rhs of an axiom not in Dr must be avariant literal pattern of some atom in the lhs of some axiom in Dr.

3. There exists a mapping h from Rel to the set of natural numbers such thatfor each ri ∈ Rel, h(ri) ≥ h(si,j), for every relation symbol si,j in Ri,j(Yj)

A graphical interpretation of the mapping h is done by means of a depen-dency graph D(C). We say r1 depends upon r2 if and only if a literal definedon r2 symbol appears in the rhs of some axiom in Dr1

. A dependency graphfor a relation r, denoted by D(C, r) is a subgraph of D(C) which describes onlydependencies for r. In figure 1, we show the dependency graph for S and thedependency graph for nocc relation symbol in S.

perm

nocc

=

nocc

=

eq

Fig. 1. Dependency graphs D(S) and D(S, nocc).

4 Transformation Method

This section describes a method which constructs operational contexts Co fromlayered and descriptive contexts C preserving correctness. Sorts in Co coincidewith sorts in C and for each explicit and descriptive specification Dr an ope-rational specification Do

r is obtained such that Co |= Dr ⇔ Dor . A totalization

process decides interpretations for partial relations. The operational context Co

is obtained by a succession of steps C0 = C, ..., Ck = Co. Each step replaces

Page 158: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Transforming Layered Spe i ations into Operational Spe i ations 151an explicit and descriptive Dr by an operational Do

r . Each Dor is obtained in

an iterative and incremental way where the transformation is represented by asuccession of steps (called transformation steps) D0 = Dr, ..., Dn = Do

r . Eachstep is a composition of a preprocessing step which constructs a transformationplan from the information in Ci and a processing step which develops this planapplying basic transformation rules. At each step, probably, new relations areadded.

4.1 Totalizing Partial Specifications

Technically, a partial specification Dr does not define the semantics for someinstances of r. Our method handles only total specifications, therefore, the spe-cifier must decide an interpretation for ambiguous literals. Let Mod be the set ofall (isoinitial) models for C (i.e. the set of all models which decide interpretations

for ambiguous instances of r). Let C |D

rT

Drbe the context obtained from C repla-

cing Dr by DrT where DrT is a new specification which decides the semantics for

undefined instances of r. Let MT be a model for C |D

rT

Dr. We say DrT is a valid

totalization for Dr in C iff MT ∈ Mod. Probably, a closed world assumptioncould be a reasonable (a priori) completion for partial relations but, technically,there exist many other ways to complete partial relations [LaO96]. We left openthe mechanisms to do it.

Example 7. Deq is a partial specification in S. A (valid) totalization for Deq:

DeqT = Deq ∪ eq(empty, conc(y, Y )) ⇔ false,

eq(conc(x, X), empty) ⇔ false

4.2 Basic Transformation Rules

The transformation of a descriptive specification into an operational specifica-tions is obtained by the application of a set of basic transformation rules. Theserules are defined in a constructive way. A detailed description, including a proofof the validity of the rules, can be found in [GaC01].

Definition 10 (Unfolding Rule). Let S be a formula in the language of C.Let a be an atom in S defined on symbol r and let r(Xj) ⇔ Rj(Yj) (j = 1..h)be a (sub)set of axioms in Dr such that the variables appearing only in Rj(Yj)but not in r(Xj) do not appear in S and there exists a σj with r(xj)σj = a. Wesay that Sj is obtained from S unfolding a with respect to r(Xj) ⇔ Rj(Yj) ifand only if Sj = S |a

Rj(Yj)σjwhere S |a

Rj(Yj)σjrepresents the textual replacement

of a by Rj(Yj)σj in S.

Example 8. Let S = nocc(a, conc(v, V ), s(k)) ⇔ nocc(a, conc(w, W ), s(k)) be aformula in the language of S. Let nocc(a, conc(v, V ), s(k)) be an atom in S. Weconsider the subset of axioms for nocc Dnocc,2, Dnocc,3 with lhs(Dnocc,2)σ1 =

Page 159: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

152 F. J. Galan, J. M. Ca~nete

Page 160: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Transforming Layered Spe i ations into Operational Spe i ations 153

Page 161: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

154 F. J. Galan, J. M. Ca~nete

Page 162: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Transforming Layered Spe i ations into Operational Spe i ations 155

Page 163: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

156 F. J. Galan, J. M. Ca~nete

Page 164: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Transforming Layered Spe i ations into Operational Spe i ations 157

Page 165: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

158 F. J. Galan, J. M. Ca~nete

Page 166: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Transforming Layered Spe i ations into Operational Spe i ations 159

Page 167: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

160 F. J. Galan, J. M. Ca~nete

Page 168: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Transforming Layered Spe i ations into Operational Spe i ations 161

Page 169: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 170: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Abstra t Satisability of Linear Temporal Logi Mara del Mar Gallardo, Pedro Merino, Ernesto PimentelDpto. de Lenguajes y Cien ias de la Computa ionUniversity of Malaga, 29071 Malaga, Spainfgallardo,pedro,ernestogl .uma.esAbstra t. Model Che king has be ome one of the most powerful meth-ods for automati veri ation of software systems. But this te hniqueis only dire tly appli able to small or medium size systems. For largesystems, it suers from the state explosion problem. One of the mostpromising ways to solve this problem is the use of Abstra t Interpre-tation to onstru t simpler models of the system, where the interest-ing properties an be analyzed. In this paper, we present a theoreti allanguage-independent framework to assist in the denition of orre t ab-stra tions for the veri ation of temporal properties expressed with ltl.The results an be adapted to a number of real modeling languages. Inthe paper, we present the appli ation of the results to the very popularveri ation system spin, whi h uses promela as the modeling language.Several ompleteness and onsisten y onditions are studied to preservethe (abstra t) satisability of properties.1 Introdu tionModel Che king [4, 1 represents one of the most useful results of almost twentyyears of resear h in formal methods to in rease the quality of software and otherrelated systems. A model he ker works with a high level des ription of a system,a model, and it an automati ally inspe t the rea hable states of the system to he k if a given property an be satised. Typi ally, properties are expressedwith some variant of temporal logi , Linear time Temporal Logi (ltl) beingone of the most employed [15.Despite the variety of model he kers and formalisms for representing modelsand properties, existing tools suer from the state explosion problem when deal-ing with realisti systems. Among other approa hes, the onstru tion of moreredu ed (abstra t) models using the ideas of Abstra t Interpretation [2 is be- oming a promising way of obtaining information about the satisfa tion of for-mulas without having to inspe t the whole state spa e [6, 14, 7, 8, 14, 3. In fa t,some works have already been oriented to dealing with this problem in sev-eral ontexts. This is the ase of [17, where authors provide a methodology inwhi h abstra t interpretation and model he king are ombined to arry out owanalysis of programs. A similar obje tive is onsidered in [3, where abstra t in-terpretation of temporal al uli and logi s is studied. Our approa h diers fromthese other works in several aspe ts. From a theoreti al point of view, we study

Page 171: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

164 M. del Mar Gallardo, P. Merino, E. Pimentelthe relation between satisability of a ltl formula on a model and on its abstra -tion, giving onditions to ensure the satisability preservation. This is made byintrodu ing a notion of non-standard satisability, whi h has not been studiedpreviously. On the other hand, and from a more pra ti al point of view, the waywe relate the standard semanti s of a model and its abstra tion allows us a nat-ural implementation of abstra tion by sour e-to-sour e transformation, whi havoids using dierent veri ation tools to analyze a model and its abstra tion.In order to apply abstra t interpretation to a on urrent system, we assumeit is modeled by a transition system, whi h is abstra ted by obtaining a sim-pler (and easier to be analyzed) transition system. Of ourse, to maintain the\relevant" features of the original transition system, the abstra ted one has tosimulate it in some way, preserving the observable behavior. After the abstra tionof a on urrent model, another problem is the relationship between propertiesin both models (the on rete and the abstra t ones). In fa t, most of the ef-forts of this paper are dire ted to give onditions under whi h the analysis ofproperties in a system may be delegated to the analysis of the orresponding\abstra ted" properties. An exhaustive study of these onditions is presented,motivating them with several examples, in the ontext of ltl.We onsider a referen e interpretation of the original model, and a non-standard interpretation is obtained from an abstra t interpretation. Applyingthe same te hnique, we employ two dierent notions of temporal formula sat-isfa tion: the standard one, determined by the referen e interpretation of thepropositions, and the non-standard obtained by abstra ting the meaning of thelogi propositions. Non-standard satisfa tion relies on weak Kripke stru tures,whi h relax the prin iple of non- ontradi tion, thus allowing an (abstra t) stateto satisfy both a proposition p and its negation :p. These weak Kripke stru turesmove us into the eld of para onsistent logi s [16, whi h are an alternative to lassi al logi , that allows some ontradi tions to be true without in urring onthe trivialization of lassi al logi . There are already some works where model he king is applied to these kinds of logi s [5.The problems indu ed by ontradi tions are limited by adding onsisten yand ompleteness onditions when dening the orresponding abstra t notionof satisability. In doing so, some pra ti al results about the behaviour of theinitial ( on rete) systems are obtained. A major ontribution of our approa h isits ability to be easily instantiated for parti ular modeling languages. For thispurpose, we have to use the labeled transition system semanti s of the language,whi h is usually available in the do umentation of model he kers. For example,instan es of the orre tness onditions and pra ti al results an be found forpromela/spin [9, and for sdl/ ms [10.The paper is organized as follows. First, we outline a brief introdu tion toabstra t interpretation. Se tion 3 is devoted to showing how abstra t interpre-tation an be made on generi transition systems, and Se tion 4 presents severalresults on erning the relation between the satisfa tion of temporal logi formu-las in a model and its abstra tion. Se tion 5 shows an example of the appli ationof the overall theoreti al framework to environment promela/spin[12.

Page 172: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Abstra t Satisability of Linear Temporal Logi 1652 Abstra t InterpretationAbstra t interpretation [2 is a stati analysis te hnique that denes a relationbetween two semanti levels: the on rete and the abstra t one. Let StdL be asemanti s of a programming language L whi h asso iates the standard interpre-tation StdL(P ) 2 D to ea h program P of L, whereD denotes the set of on retedenotations. The obje tive of abstra t interpretation is to automati ally realizea nite approximation of StdL, StdL : L ! D, su h that StdL(P ) is om-putable and gives us some information about whether some property is fullledby the exe ution of P . StdL(P ) is generally obtained by an abstra t exe utionof P that uses data representations (abstra tions) instead of the original data.Abstra tion always implies some loss of information but instead, applying it, wea hieve omputability of the analyzed properties.Abstra tion is a hieved by means of a pair of fun tions : D ! D and : D ! D between the posets (D;v) and (D;v) whi h onstitute a Galois onne tion, that is: 8d 2 D; d 2 D : (d) v d , d v (d).Fun tions and are alled abstra tion and on retization fun tions, re-spe tively. Usually, the values of the abstra t domain D only apture the infor-mation needed for the orresponding analysis. Abstra tion fun tion proje tsstandard data on these values, thus redu ing the size of the semanti domain.The partial order v represents the pre ision degree dened by the abstra t se-manti s: d1 v d2 indi ates that the abstra t property d1 is more pre ise thand2 , or from the dual point of view, that d2 approximates d1 . Thus, the relation(d) v d means that d is an abstra tion and an approximation of d. Withthis notation, the obje tive of abstra t interpretation is to nd an approximationStdL of StdL su h that for ea h program P of L, (StdL(P )) v StdL(P ).3 Abstra ting Con urrent SystemsIn this se tion we apply abstra t interpretation to transition systems, in a generalway, proving an important result on behavior preservation between a model andits abstra t version.3.1 Modeling Con urrent SystemsExe ution of on urrent programs1 may be dened by means of labeled transitionsystems su h as M = (A;; !; s0), where A is the set of observable atomi a tions. is the set of states. ! A is a labeled transition relation. We write s a! s0 for(s; a; s0) 2 !. s0 2 is the initial state.1 We will use the terms programs, systems and models indierently.

Page 173: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

166 M. del Mar Gallardo, P. Merino, E. PimentelM denes an interpretation of a tions over the set of states : ea h transitions a! s0 means that the exe ution of the atomi a tion a would transform thesystem from state s to state s0 in a single step. A tra e x of M is a sequen ex = t0 a0! t1 a1! t2 a2! : : : of states. Tra e x represents a possible omputation fromthe state t0 and a0a1 : : : 2 A is the sequen e of atomi a tions exe uted. Given atra e x = t0 a0! t1 a1! : : :, by xj we will denote the suÆx tra e tj aj! tj+1 aj+1! : : :.A tra e x = s0 a0! : : : starting at initial state s0 is alled full-tra e i either x isa non terminating tra e or it ends at a state from whi h no transitions evolve.Operational semanti s of programming languages are dened by means oflabeled transition systems where the initial state is not xed. The semanti s ofa parti ular program is obtained from an initial state with information about its ode. Thus, a transition system with a xed initial state denes the behaviour ofa given program. The set O(M) = fx : x = s0 a0! : : : is a full tra eg denesthe tra e semanti s determined by the transition system M .Let M1 = (A;1; !1; s10) and M2 = (A;2; !2; s20) be transition systemsgiving two dierent interpretations to the set of a tions A. Given 12 arelation from 1 to 2, we say that M2 is a simulation of M1 i (1) (s10; s20)and (2) if s1 a!1 s01 and (s1; s2) then there exists some s02 2 2 su h thats2 a!2 s02 and (s01; s02).3.2 Abstra t Interpretation of Transition SystemsLet Std = (A;; !; s0) and Std = (A;; !; s0 ) be two labeled transitionssystem. Let I = (; (;); ; ) be an abstra t interpretation of the set ofstates , where is a partial order, : ! is the abstra tion fun tionand : ! 2, dened by (s) = fs 2 : (s) sg, is the on retizationfun tion. From now on, we assume that Std gives the referen e meaning, alledstandard, to the set of a tions A. In ontrast, the interpretation of a tions givenby Std is intended to represent some abstra tion of Std. Thus, we will applythe terms standard/abstra t when we refer to the elements of Std/Std.Denition 1 (Corre tness). Given I = (; (;); ; ) an abstra t in-terpretation, we say that Std is orre t under the interpretation I with respe tto Std i Std is a simulation of Std, being the binary relation dened as(s; s) , (s) s. That is, Std is orre t under I with respe t to Stdi (1) (s0) s0 and (2) if s a! s0 and (s) s then there exists somes0 2 su h that s a! s0 and (s0) s0.Given two innite tra es x = t0 a0! t1 a1! : : : and x = t0 a0! t1 a1! : : :, wewrite (x) x when 8i 0:(ti) ti .Theorem 1. Given Std = (A;; !; s0), Std = (A;; !; s0 ) and the ab-stra t interpretation I, if Std is orre t under I wrt Std then for everyinnite full-tra e x 2 O(Std) there exists x 2 O(Std) su h that (x) x:Proof. It learly follows from the denition of orre tness.

Page 174: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Abstra t Satisability of Linear Temporal Logi 167Note that Theorem 1 only assures the simulation of innite tra es. In orderto simulate ending (deadlo ked/nished) tra es, we must impose the followingadditional ondition in the denition of orre tness: (3) if s a6! and (s) sthen s a6!. This suÆ ient ondition be omes also ne essary when s representsonly rea hable states in full-tra es.Example 1. Let Std = (A;; !; s0) be a labeled transition system that denesthe behaviour of a non-deterministi program P , with one variable y rangingover Int, the set of the integer numbers, as follows: A = fy = y + 2; skipg. = Intfstart; endg. A standard state s = (sy; sl) 2 denes the urrentvalue sy stored in y and the program ounter sl. ! is dened as: (sy; start) y=y+2! (sy + 2; start), (sy; start) skip! (sy; end). s0 = (0; start).Elements in O(Std) are nite tra es like (0; start) y=y+2! (2; start) y=y+2! : : : skip!(2n; end) and the non-terminating tra e (0; start) y=y+2! (2; start) y=y+2! : : :.Let (Inty ;y ) be dened by Inty = feven; oddg and the partial orderingy over this domain being the relation \=". The lassi even-odd abstra tiony : Int! Inty , dened as y(2n) = even and y(2n+ 1) = odd for all n 0,determines an abstra tion : ! (;) of standard states over the abstra tdomain = Inty fstart; endg as follows: (s) = (y(sy); sl). The partialordering over is dened as: (sy ; sl) (s0y ; s0l) i sl = s0l and sy y s0y .Then, the labeled transition system Std = (A;; !; s0 ) denes a non-standard interpretation of P where ! is dened as: (sy ; start) y=y+2! (sy ; start)and (sy ; start) skip! (sy ; end) and s0 = (even; start). The set O(Std) ontainsnite tra es like x = (even; start) y=y+2! (even; start) y=y+2! : : : skip! (even; end)and the non-terminating tra e x = (even; start) y=y+2! (even; start) y=y+2! : : :.Under these denitions, it is lear that (Std;) is orre t under the or-responding interpretation wrt Std. Therefore, Theorem 1 holds. 2In the sequel, we always assume that Std is orre t under the interpretationI wrt Std.4 Abstra ting Temporal Logi In this se tion, we dene a weak Kripke stru ture from a labeled transition sys-tem and a fun tion to evaluate logi propositions. We will see how to abstra t thestandard notion of satisfa tion of temporal formulas and the onditions underwhi h the model abstra tion pro ess preserves the abstra t/standard satisfa -tion of temporal formulas. To do this, we will onsider Kripke stru tures wherenegation is not dealt with as a onne tive, but as a way of onstru ting atomi propositions. This is done to get a homogeneous treatment of both standard andabstra t satisfa tion.

Page 175: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

168 M. del Mar Gallardo, P. Merino, E. Pimentel4.1 Our Temporal Logi Given a set of propositions Prop, we onstru t the set P = Prop [ :Prop,where :Prop = f:p : p 2 Propg. Let F be the set of ltl temporal formulasbuilt indu tively using the elements of P , the standard Boolean operators, andthe temporal operators: next \ ", always \2", eventually \3" and until \U". Theset F in ludes all temporal formulas in negation normal form, that is, negationsonly appear in atomi propositions, sin e negated propositions are expli itlyin luded in P . Let FS F be the subset of temporal formulas without temporaloperators. We will all the elements of FS state formulas.A labeled transition system M = (A;; !; s0) may be extended to a weakKripke stru ture K = hM; i where : ! 2P is a fun tion that assigns truthvalues to the propositions of P in ea h state in su h a way that the Prin iple ofEx luded Middle holds, i. e.p 2 (s) _ :p 2 (s);8s 2 ;8p 2 Prop: (PEM)Besides, K = hM; i is a Kripke stru ture when the Prin iple of Non-Contradi tion holds, i. e.p 62 (s) _ :p 62 (s);8s 2 ;8p 2 Prop: (PNC)Note that K denes an interpretation of both a tions and atomi propositions. Inthe sequel, p 2 P will denote both non-negated and negated atomi propositions.The following denition gives the satisfa tion of a temporal formula withrespe t to the given model interpretation M and the formula interpretation .Denition 2. Let K = hM; i be a weak Kripke/Kripke stru ture. Given astate s 2 , and a tra e x = t0 a0! t1 : : :, we dene indu tively the relation j=as follows:1. s j= p i p 2 P and p 2 (s).2. s j= f _ g i f; g 2 FS ; s j= f or s j= g.3. s j= f ^ g i f; g 2 FS ; s j= f and s j= g.4. x j= f i f 2 FS and t0 j= f .5. x j= f _ g i f; g 2 F ; x j= f or x j= g.6. x j= f ^ g i f; g 2 F ; x j= f and x j= g.7. x j= f i f 2 F and x1 j= f .8. x j= 2f i f 2 F , t0 j= f and x1 j= 2f .9. x j= 3f i f 2 F and 9k 0:(xk j= f).10. x j= f Ug i f; g 2 F and 9k 0:(xk j= g and 8j < k:[xj j= f ).We say that K = hM; i veries a universal temporal formula f 2 F , andwrite O(M) j= f , i 8x 2 O(M):(x j= f).

Page 176: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Abstra t Satisability of Linear Temporal Logi 1694.2 Abstra ting Weak Kripke Stru turesLet K = hStd; i and K = hStd; i be two weak Kripke stru tures. We saythat is (weakly) onsistent wrt and I when the following ondition holds:(s) s ) (s) (s): (LC)We denote onsisten y property with LC be ause it orresponds to the lo al onsisten y ondition that usually appears in abstra t interpretation. We saythat K is orre t under I wrt K i is onsistent wrt and I. -2P? Fig. 1. A ommutative diagram relating abstra tion and satisabilityCondition LC establishes the ommutativity of the diagram depi ted in Fig-ure 1. It means that the abstra tion ! must be sound wrt I. Therefore,the set ((s)) may ontain more propositions than (s). In parti ular, even ifK is a Kripke stru ture, K may lose the PNC ondition due to the abstra tionpro ess as shown in the following example.Example 2. Consider the program and the abstra t interpretation in Example 1.Given P = fy == 1;:(y == 1)g, the usual interpretation of y == 1 and:(y == 1) over is y == 1 2 (s) , sy = 1 and :(y == 1) 2 (s) , sy 6= 1.Therefore, K = hStd; i is learly a Kripke stru ture. Consider K = hStd; isu h that is onsistent wrt and I. Let s1 = (1; sl); s2 = (3; sl) 2 . Then(s1) = (s2) = (odd; sl). Denote s = (odd; sl). It is lear that y == 1 2 (s1)and :(y == 1) 2 (s2) and, by LC, y == 1;:(y == 1) 2 (s). Therefore Kdoes not verify PNC, i. e., it is not a Kripke stru ture. 2In the rest of the paper, we assume that K = hStd; i is orre t under Iwrt K = hStd; i. In addition, a ording to Denition 2, j= and j= model thesatisfa tion of a formula under the interpretation given by K and K, respe -tively. In order to simplify notation, we will write j= and j= instead of j= andj= , respe tively. The next result relates the relationships j= and j=.Proposition 1. Let s 2 be a state and x = t0 a0! t1 a1! : : : be a tra e and theformulas fs 2 FS and f 2 F :1. s j= fs ) (s) j= fs.2. Given x = t0 a0! t1 a1! : : : su h that (x) x then x j= f ) x j= f .

Page 177: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

170 M. del Mar Gallardo, P. Merino, E. PimentelProof. Let us onsider fs 2 P . By denition, s j= fs means that fs 2 (s). Then,the onsisten y ondition LC implies that fs 2 ((s)), i.e., (s) j= fs. Other ases for fs and f are proved by indu tion on the stru ture of the formula.In Denition 3, we say when a standard state satises a proposition under anon-standard interpretation of the program.Denition 3 (Non-Standard Satisfa tion).We extend j= to standard statesas follows: A standard state s 2 satises the state formula fs 2 FS under a non-standard interpretation K (s j= fs) i (s) j= fs. A standard tra e x = t0 a0! t1 : : : satises the formula f 2 F under a non-standard interpretation (x j= f) i 9x = t0 a0! : : : su h that x j= fand (x) x. K satises the universal property f under a non-standard interpretation K(O(Std) j= f), i 8x 2 O(Std) : x j= f .To illustrate the previous denition, onsider the state s = (4; sl) in the ontext of Example 1. Note that s 6j= y == 2, but sin e (s) j= y == 2,we have s j= y == 2. Intuitively, we are laiming that although the standardinterpretation of the formula is not satised by s, its non-standard interpretation,i.e. \y is even", is satised by s.This extension of the abstra t satisability relation will allow us to relate thesatisfa tion of temporal formulas in the abstra t and standard models. Using thisnotion, we an rewrite Proposition 1 as follows.Corollary 1. Given s 2 , x = t0 a0! : : : a tra e, fs 2 FS and f 2 F , we have: s j= fs ) s j= fs. If there exists some abstra t tra e x su h that (x) x then x j= f )x j= f .Proof. It follows from Proposition 1, using Denition 3.Theorem 2. Let f 2 F be a universal property. If K is orre t under I wrtK, and O(Std) j= f , then O(Std) j= f .Proof. Given x = s0 a0! : : : 2 O(Std), sin e K is orre t with respe t to K, thereexists x = s0 a0! : : : 2 O(Std) su h that (x) x. As, by hypothesis,O(Std) j= f , we have x j= f , i.e., x j= f .This theorem proves that if an abstra t model veries the formula f , thenthe model itself veries f too under the abstra t interpretation given by . Theexample below shows how this result an be applied.Example 3. With the abstra tion fun tion dened in the Example 1, the ab-stra t satisfa tion of the formula f = 2(y == 2) ould be used to prove that yremains even during any model exe ution as follows.

Page 178: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Abstra t Satisability of Linear Temporal Logi 171Let s 2 and s 2 be the on rete and abstra t states dened bys = (2; sl) and s = (even; sl). To prove that y == 2 2 (s) , it suÆ es tonote that a) y == 2 2 (s) b) (s) s s and ) must verify the propertyof onsisten y given by LC. In addition, it is lear that if x = s0 a0! : : : 2O(Std), then 8j:sj = (even; slj ), that is, y == 2 2 (sj ). Using Denition 2,this means that 8j:sj j= (y == 2), i. e., x j= 2(y == 2). Sin e x is a generi element of O(Std), by Denition 2, we have that O(Std) j= 2(y == 2).Finally, applying Theorem 2, as K is orre t under I wrt K, we dedu e thatO(Std) j= 2(y == 2). 24.3 Adding Completeness ConditionIt is worth stressing the relevan e of Theorem 2. Indeed, if denes some usefulinformation for the user, this result may be a powerful tool for debugging amodel. However, ondition LC only for es (s) to ontain all atomi propo-sitions satised by the on retizations of s. Many denitions of verify LC.In parti ular, the most onservative one, (s) = P for all s 2 , does it.However, this is not useful, be ause it ould be used to prove any formulaover the (abstra t) program. For instan e, in the previous example, we ouldprove that O(Std) j= 2(y == 1). The next ondition restri ts the set (s).We say that is omplete wrt and I i the following ondition holds:Ifp 2 (s) then there exists s 2 su h that (s) s and p 2 (s): (C)Condition C represents the ompleteness of the abstra tion ! wrt I.Every proposition satised by s must also be satised by some on retizationof s. In other words, C states that fun tion does not arbitrarily add propo-sitions to (s). Clearly, the onservative dened above is not omplete: if(s) = (even; sl) then y == 1 62 (s).In what follows, we always assume that is both onsistent and ompletewrt and I. Under these onditions, we obtain the monotoni ity of .Proposition 2. is monotoni , that is, if s1 s2 then (s1 ) (s2 ).Proof. Let us assume that p 2 (s1 ), then, by ondition C, there exists s 2 su h that (s) s1 and p 2 (s). As s1 s2 , applying ondition LC, we on lude p 2 (s2 ).Proposition 3. Let fs 2 FS and f 2 F be a state formula and a temporalformula, respe tively.1.- Given s1 ; s2 2 su h that s1 s2 . Then s1 j= fs implies s2 j= fs.2.- Given x1 = t10 ! t11 ! : : : and x2 = t20 ! t21 ! : : : two sequen es ofstates su h that 8i:t1i s t2i. Then x1 j= f implies x2 j= f .Proof. Let us assume that fs 2 P . By denition, s1 j= fs implies fs 2 (s1 ).By the Proposition 2, sin e s1 s s2 , we also have fs 2 (s2 ) holds, i.e.,s2 j= fs. The rest of the ases for fs and f are proved by indu tion on thestru ture of the formula.

Page 179: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

172 M. del Mar Gallardo, P. Merino, E. PimentelThe next proposition proves that LC and C determine .Proposition 4. veries onditions LC and C i 8s:(s) = Ss2 (s) (s).Proof. Clearly, if 8s:(s) = Ss2 (s) (s), then veries LC and C. Con-versely, ondition LC implies Ss2 (s) (s) (s). In addition, if p 2 (s),by applying ondition C, there exists s 2 (s), su h that p 2 (s). Therefore,p 2 Ss2 (s) (s).Example 4. Given = Int and = fneg; zposg, we dene the abstra tionfun tion : ! as (n) = neg, if n < 0 and (n) = zpos, if n 0. LetP = fzero;:zerog be the set of atomi propositions. We assume that the orderrelation over is the = relation. Let be dened as:(n) =8<:f:zerog i n < 0fzerog i n = 0f:zerog i n > 0Using Proposition 4, we obtain that determines the following fun tion:(n) = f:zerog i n = negf:zero; zerog i n = zposObviously, in this simple ase, is only useful to he k the zero values. 24.4 Adding Strong Consisten y ConditionWe now present the most relevant result of the paper, that relates the satisfa tionof a formula in the abstra t model with its satisfa tion in the standard one.In Example 3, we did not prove that during a standard exe ution the variabley is always equal to the value 2 (this assertion is in fa t false). Instead, we provedthat y is always equal to the non-standard interpretation (given by the fun tion) of the value 2, that is, y is always even. In fa t, this is the best method forproving property "y remains even during exe ution" over the standard interpre-tation of program, whi h may be interesting in many appli ations.However, the user ould also be interested in proving that the standard in-terpretation of the property is also satised during the standard interpretationof the program. For instan e, we would be interested in proving that y is thevalue 2 during every standard exe ution of P . Next, we dis uss how to relate thestandard and non-standard interpretations of temporal formulas.Denition 4 (Abstra t Impli ation). Let K = hStd; i and K = hStd; ibe two weak Kripke stru tures su h that K is orre t under I wrt K.1. Given two state formulas fs1 ; fs2 2 FS then fs1 ) fs2 i 8s 2 : s j=fs1 ) s j= fs2 .2. Given two temporal formulas f1; f2 2 F then f1 ) f2 i 8x 2 O(Std) :x j= f1 ) x j= f2.In order to be able to make sound ba ktra king to the standard interpretationwhen proving temporal formulas we need to impose an additional ondition alled strong onsisten y ondition.

Page 180: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Abstra t Satisability of Linear Temporal Logi 173Denition 5 (Strong Consisten y Condition). is strongly onsistentwrt and I when it is weakly onsistent and the following ondition holds:If (s) (s) then (s) s: (SC)Note that LC and SC are re ipro al ea h other.Example 5. Consider the sets and (;), and the fun tion : ! dened in Example 4. Fun tion is not strongly onsistent wrt and Ibe ause for all n < 0; (n) (zpos) but (n) = neg 6 zpos. But, if P =fpositive;:positive; negative;:negativeg, may be redened as follows:(n) =8<:f:positive; negativeg i n < 0f:positive;:negativeg i n = 0fpositive;:negativeg i n > 0By Proposition 4, determines :(n) = f:positive; negativeg i n = negf:positive; positive;:negativeg i n = zposNow, is strongly onsistent wrt and I:1. if n < 0 then (n) (n) implies n = neg.2. (0) (zpos) and (0) zpos.3. if n > 0 then (n) (n) implies n = zpos. 2Proposition 5. Let K = hStd; i and K = hStd; i be two Kripke stru turessu h that K is orre t under I wrt K, being omplete and strongly onsistentwrt and I. Then, we have:(a) Given s 2 , there is a state formula f 0s 2 FS su h that s j= f 0s, and forevery fs 2 FS su h that s j= fs, f 0s ) fs.(b) Given x = s0 a0! : : : 2 O(Std), there exists a formula f 0 2 F su h thatx j= f 0 and for all f 2 F verifying x j= f , f 0 ) f .Proof. a) We have just to take f 0s = ^fq : q 2 (s)g, whi h is well denedsin e the set (s) is non empty be ause K is a weak Kripke stru ture and,therefore, PEM holds. By the onstru tion of f 0s, it is lear that s j= f 0s. Givenfs su h that s j= fs, let us see that f 0s ) fs. Let s0 2 be a state verifyingthat s0 j= f 0s. Using the denition of f 0s , s0 j= f 0s implies (s) ((s0)).Sin e, by hypothesis, is strongly onsistent wrt , this relation impliesthat (s) (s0). Finally, by using the monotoni ity (Proposition 3), andtaking into a ount that s j= fs, we infer s0 j= fs.b) By indu tion on the stru ture of the formula:i. For f 2 FS the result is obtained from a).ii. If f = 2fs with fs 2 FS . By denition, x j= 2fs implies that 8i 0:si j= fs. Applying a) to ea h si, we obtain a family of propositionsf 0si verifying that f 0si ) fs and si j= f 0si . Let f 0s = Wi0 f 0si and f 0 =2(Wi0 f 0si). Then f 0s ) fs, that is, f 0 ) f , what implies that x j= f 0.iii. Proofs for ases f = fsUgs and f = 3fs, f = fs , f = fs _ gs,f = fs ^ gs are similar to the previous ones.

Page 181: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

174 M. del Mar Gallardo, P. Merino, E. PimentelThe previous proposition allows us to dene the notion of abstra t extensionof a formula f . This operation represents the loss of pre ision about f due tothe abstra t interpretation.Denition 6 (Abstra t extension of a formula). Given f 2 F a tempo-ral formula, we dene the abstra t extension of f , and denote it with f, byWff 0 : f 0 ) fg.The loss of information above ommented may be written as f ) f, whi his easily dedu ed from the previous denition. In general, the opposite is nottrue and f and f do not oin ide; this means that the properties representedby f and the abstra t interpretation are orthogonal. For instan e, this o urs forthe formula 2y == 2 in Example 3. A more detailed study will be made below.Theorem 3. Under the same onditions in Proposition 5, if O(Std) j= fthen O(Std) j= f.Proof. It follows dire tly from Proposition 5 b).This theorem gives us the relationship between the formulas proved underthe abstra t interpretation and the formulas whi h hold under the standardinterpretation. This result is parti ularly useful when f = f, i.e. when theabstra tion pro ess preserves all the information represented by f . Under thishypothesis, whenever we have O(Std) j= f , Theorem 3 guarantees O(Std) j=f , as desired by the user.Corollary 2. Given a temporal formula f 2 F , if O(Std) j= f and f = f ,then O(Std) j= f .Thus, we need a pro edure to ompute f in order to he k whether f = f .Fortunately, preserves the temporal operators. That is, f , f, f _ g ,f _ g, f ^ g , f ^ g, 3f , 3f , 2f , 2f , f , f , andfUg , fUg.Corollary 2 gives the analyzer the possibility of dire tly using informationabout a given on rete property obtained from an abstra t model (easier tobe veried than the on rete one). Thus, it is important to provide onditions(automati ally de idable) whi h ensure the appli ability of the orollary. Thenext denition presents these onditions, as Proposition 6 will prove.Denition 7. We say that p 2 P is not abstra ted by I, i 8s:p 2 (s)):p 62 (s).Proposition 6. If p 2 P is not abstra ted by I then p, p.Proof. Let us see that p) p. By denition, s j= p means that p0 2 P exists su hthat s j= p0 and p0 ) p. Using LC, we have that (s) j= p0, that is, (s) j= p,or equivalently, p 2 ((s)). If :p 2 (s) then, by LC, :p 2 ((s)). But thisis not possible, sin e p is not abstra ted by I and we know that p 2 ((s)).Therefore, it stands that p 2 (s), i.e., s j= p.

Page 182: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Abstra t Satisability of Linear Temporal Logi 175The next orollary presents two pra ti al results of interest when we want toprove some very frequent temporal formulas by using abstra t interpretation.Corollary 3. Let us assume that p; q 2 P are not abstra ted by I. Then if fis any of the temporal formulas 2p, 3p, p, or p U q , and O(Std) j= f ,then O(Std) j= f .5 An Example in promelaIn se tion we illustrate the usefulness of our approa h by applying it to spin[12, 13, a widely used model he king tool that uses promela as the modelinglanguage. A promela model P = Pro 1jj : : : jjPro n onsists of a nite set of on urrent pro esses, global and lo al hannels, and global and lo al variables.Pro esses ommuni ate via message passing through hannels. Communi ationmay be asyn hronous using hannels as bounded buers, and syn hronous using hannels with size zero. Global hannels and variables determine the environmentin whi h pro esses run, while lo al hannels and variables establish the internallo al states of pro esses.The operational semanti s of a promela model O(Std) is dened in [11 bymeans of a transition relation. In that work, a generalized semanti s is proposedby onsidering a transition relation dened on a set of environments Env, andparameterized by two mappings, : Env ! 2BExp and ' : Basi Env ! Env.The rst one evaluates Boolean expressions (BExp) in a given environment,whereas the se ond mapping gives the ee t of exe uting a basi a tion (Basi )on an environment. As a promela model depends on these two parameters, wewill denote Std as M(; '). Note that dierent denitions of and ' yield todierent interpretations of the model. In parti ular, to give an abstra tion ofStd it is enough to give abstra tions for and '.We present an example illustrating the appli ability of the previous resultsto this popular modeling language.Example 6. Consider the model Collatz in Figure 2, where the pro ess p2 usesthe values generated by the Collatz fun tion to send messages to pro ess p1using a shared hannel. Let Env = fv; n; hg ! fa; b; ; :::; errorg [ Int bethe set of states. Ea h element e 2 Env asso iates the variables v, n and the hannel h with its a tual value. Assume that we want to prove the temporalformula F = 3(v == error). To do it, we onsider the set of abstra t statesEnv = fv; n; hg ! f0; 1g [ Int. Let us take (Env;), where is therelation \=". Let h : mtype ! f0; 1g be dened by h(error) = 0 and h(m) = 1;8m 6= error. Finally, let : Env ! Env be the abstra tion fun -tion given by (e)(n) = e(n); (e)(v) = h(e(v)) and (e)( h) = h(e( h)).Denote I = (Env; (Env;); ; ). Finally, let Std = M(; ') the ab-stra t interpretation of the program given by the fun tions and ' denedby v == error 2 (e) i e(v) = 0.

Page 183: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

176 M. del Mar Gallardo, P. Merino, E. Pimentel v == m 2 (e) i (e(v) = 1);8m 6= error. '(out ! m; e) = e[1=out;8m 6= error. '(out ! error; e) = e[0=out.It an be proved that Std is orre t under I wrt Std. In addition, isstrongly onsistent and omplete under I wrt .Furthermore, if v == error 2 (e) then, by denition, e(v) = 0. There-fore, :(v == error) 62 (e); and, by Denition 7, (v == error) is not ab-stra ted by I. Using Proposition 6, this means that v == error = v == error,that is, (Corollary 3) 3v == error = (3v == error).A simple analysis of the abstra t behaviour of the program shows thatO(Std) j= 3v == error. Sin e is strongly onsistent wrt we on ludethat O(Std) j= 3v == error, that is, O(Std) j= 3v == error. 2mtype = a,b, ,...,errormtype v; int n = ...; han h = [1 of mtype;a tive pro type p1() a tive pro type p2()do do:: h?v; ::n % 2 != 0 -> h!error;n = 3 * n + 1;if ::n % 2 ==0 ->:: v == error -> ... if :: true -> h!a:: v == a -> ... :: true -> h!b:: v == b -> ... :: true -> h! :: v == -> ... ...... fi;fi n = n/2;od od Fig. 2. Model Collatz6 Con lusionsWe have introdu ed a framework to apply abstra t interpretation to ltl, in the ontext of model he king. In parti ular, we have dened a set of (weak) on-sisten y onditions that guarantee that the abstra t interpretation of a modelpreserves the abstra t satisability relation. However, these onditions are sat-ised by trivial abstra tions, whi h learly are not useful in pra ti e. In order tosolve this problem, some ompleteness onditions are introdu ed. Finally, strong onsisten y provides a way to guarantee that the abstra t satisfa tion of a for-mula implies its standard satisfa tion. These results have been illustrated bymeans of an example.A relevant ontribution of this paper is that all results are independent ofthe a tual modeling language. It an be adapted to a wide range of pra ti almodeling languages with available model he king tools. We are urrently im-plementing an extension of spin that supports abstra tion. Current and futureversions of this tool an be found at http:\\www.l .uma.es\~gisum\fmse\tools.

Page 184: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Abstra t Satisability of Linear Temporal Logi 177A knowledgementsWe would like to thank David de Frutos for his omments to improve this paper.This resear h is partially supported by the CICYT proje ts TIC98-0445-C03-03and TIC99-1083-C02-01.Referen es1. E. Clarke, O. Grumberg, D. Peled,Model Che king (The MIT Press, 2000).2. P. Cousot, R. Cousot, Abstra t Interpretation: A Unied Latti e Model for Stati Analysis of Programs by Constru tion or Approximation of Fixpoints, in Conf.Re ord of the 4th ACM Symp. on Prin iples of Programming Languages,(1977)238252.3. P. Cousot, R. Cousot, Temporal Abstra t Interpretation, in Conf. Re ord of the27th ACM SIGACT-SIGMOD-SIGART Symposium on Prin iples of ProgrammingLanguages (2000) 1225.4. E.M. Clarke, E. A. Emerson, A.P. Sistla, Automati Veri ation of Finite-StateCon urrent Systems Using Temporal Logi Spe i ations, ACM Trans. on Pro-gramming Languages and Systems, 8(2) (1986) 244263.5. M. Che hik, S. Easterbrook, V. Petrovykh, Model-Che king over Multi-ValuedLogi s, in: Pro eedings of Formal Methods Europe (FME'01) LNCS-2021 (2001)404419.6. E.M. Clarke, O. Grumberg, D.E. Long, Model Che king and Abstra tion, ACMTransa tion on Languages and Systems, 16(5) (1994) 15121245.7. D. Dams, R. Gerth, O. Grumberg, Abstra t Interpretation of Rea tive Systems,ACM Transa tions on Programming Languages and Systems, 19(2) (1997) 253291.8. S. Graf , H. Saidi, Constru tion of Abstra t State Graphs with PVS, in: Grumberg,O., ed., Computer Aided Veri ation, LNCS-1254, Springer, (1997) 7283.9. Gallardo M.M., Merino P.: A Framework for Automati Constru tion of Abstra tPROMELA Models, in Theoreti al and Pra ti al Aspe ts of SPIN Model Che king,LNCS-1680, (1999), 184199.10. M.M. Gallardo, P. Merino, A Pra ti al Method to Integrate Abstra tions intoSDL and MSC based Tools, in: Pro . of the 5th International ERCIM Workshopon Formal Methods for Industrial Criti al Systems, GMD Report 91, (2000).11. M.M. Gallardo, P. Merino , E. Pimentel, An Operational Semanti s of Promela forSimulation, Veri ation and Abstra tion, Te hni al Report LCC ITI-01/9. Dpto.de Lenguajes y Cien ias de la Computa ion University of Malaga, (2001).12. G.J. Holzmann, Design and Validation of Computer Proto ols, Prenti e-Hall, 1991.13. G.J. Holzmann, The Model Che ker SPIN, IEEE Transa tions on Software Engi-neering 23(5) (1997) 279295.ing, 23(5), 1997.14. C. Loiseaux , S. Graf, J. Sifakis, A. Boujjani, S. Bensalem, Property PreservingAbstra tions for the Veri ation of Con urrent Systems. Formal Methods in SystemDesign 6 (1995) 135.15. Z. Manna , A. Pnueli, The Temporal Logi of Rea tive and Con urrent Systems -Spe i ation, Springer-Verlag, New York, (1992).16. G. Priest, K. Tanaka, Para onsistent Logi , in: The Standford En y lopedia ofPhilosofy, Stanford University, (1996).17. D. S hmidt, Data- ow analysis is model he king of abstra t interpretations, in:Pro . of 25th POLP(1998) 3848.

Page 185: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 186: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

De larative Re e tion and its Appli ation as aPattern LanguageJuan Jose Moreno-Navarro and Angel Herranz-NievaLSIIS - Fa ultad de Informati a, Universidad Polite ni a de Madridfjjmoreno,aherranzgfi.upm.esAbstra t. The paper presents the re e tion fa ilities of the spe i -ation language Slam-sl. Slam-sl is an obje t oriented spe i ation lan-guage where lass methods are spe ied by pre and post onditions. There e tion apabilities permit managing these pre and post onditions inspe i ations what means that semanti re e tion is possible. The rangeof interesting appli ations is very wide: formal spe i ation of interfa esand abstra t lasses, spe i ation of omponent based software, formal-ization of design pattern, using Slam-sl as a pattern language, et . Thepaper dis usses the last two advantages in some detail.1 MotivationWe have re ently presented the SLAM system [11, 16, whi h in ludes an obje toriented spe i ation language, Slam-sl, that is supported by a developmentenvironment that, among other features, is able to generate readable ode in ahigh level obje t oriented language. The Slam-sl language is a formal spe i ationlanguage that integrates algebrai spe i ations (like those proposed by the OBJlanguage family [9, 4 or Lar h-LSL [10), and model-based spe i ations(as Z[17, VDM [12, or Lar h interfa es languages [10). Spe i ation of lass methodsuses two predi ates (pre/post- onditions) that des ribe the relationship betweenthe input and the output by means of logi formulas.In this paper we present the re e tive features of the language whi h an beused for some interesting appli ations, like the formalization of design patterns interm of lass operators. An obje t-oriented re e tive system is one that is itselfbuilt out of programmable, rst- lass obje ts. In Slam-sl it is possible to dy-nami ally inspe t and manipulate lasses, obje ts, methods, and other languageelements.Re e tion apabilities an be used in many useful appli ations: ompon-ent based software, ompiler onstru tion, debugging, module operations, et .The re e tive features of a language an be ategorized as linguisti , stru tural,and behavioral. Linguisti and stru tural re e tion is basi ally synta ti al andis present in a number of programming languages either in the obje t-orientedimperative ommunity (Smalltalk [7, Java, C# [3) and in the de larative pro-gramming ommunity (Lisp, Prolog, Maude [4). However, behavioral re e tionallows managing the semanti s of the elements of the language (Maude).

Page 187: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

180 J. J. Moreno-Navarro, A. Herranz-NievaWe all de larative re e tion those behavioral re e tion hara teristi s thatrely on de larative models (logi s, fun tions, et .) De larative re e tion not onlyallows manipulating the semanti s of lasses and obje ts, but also to formallyreason about them. In the previous list, only the spe i ation language Maude,based on rewriting logi what in turns is a re e tive logi , an be onsidered tohave de larative re e tive features. However, they are fo used mainly on moduleoperations.Slam-sl is equipped with behavioral/de larative re e tion: It is possible to inspe t and manipulate obje t oriented elements: lasses,methods, et . It is possible to manage the de larative behaviour of su h elements, as lassinvariants, or methods pre and post onditions. De larative properties of those elements are in luded and formal reasoning isenfor ed. For instan e, inheritan e is only permitted under ertain onditionsand these onditions are preserved even in dynami ally generated lasses. It is possible to de laratively model some obje t oriented features, as inter-fa es or abstra t lasses.We are going to present in detail a pair of interesting appli ation: the formaliza-tion of design patterns as lass operators and, onsequently, the use of a formalmethod as a pattern language.The remainder of the paper is organized as follows: an introdu tion to Slam-slin se tion 2, re e tive properties of slam-sl in se tion 3, and omposite, state andbuilder design pattern spe i ation in se tion 4. We present some on lusions inse tion 5.2 Obje t oriented spe i ations. Slam-slThis se tion presents the main onstru tions of the language fo used on re e tivefeatures that will used in the following se tions.Slam-sl is part of the SLAM proje t, a software onstru tion developmentenvironment that is able to synthesize (reasonable) eÆ ient and readable ode indierent high level obje t oriented target languages like C++ or Java. Amongother features, the user an write spe i ations in a friendly way, tra k herhand- oded optimizations, or he k in debug mode those optimizations throughautomati ally synthesized assertions.In order to fa ilitate the understanding of Slam-sl we will show its elementswith a on rete syntax that does not ne essarily orrespond neither with aninternal representation nor the environment presentation1, so the reader shouldnot pay attention to the on rete syntax but to the abstra t one.A Slam-sl program is a olle tion of spe i ations that denes lasses and lass properties. The spe i ation of method behaviour is given through pre on-ditions and post onditions but with a fun tional avour as we will see.1 In fa t, Slam-sl programs are stored in XML format and its presentation in theenvironment an be ustomized.

Page 188: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

De larative Re e tion and its Appli ation as a Pattern Language 1812.1 Slam-sl toolkitAs many others spe i ation languages Slam-sl has a powerful toolkit with pre-dened types representing booleans, numbers, hara ters and strings, re ordsand tuples, olle tions (sequen es, sets, et .), di tionaries (maps, relations, et .).Slam-sl type syntax re e ts value syntax, for instan e, the type `sequen e of in-tegers' is written as [ Integer and its values are written as [1,2, a tuple type an be written as (Char, Integer ) and its values as ('a',32), et .Re ords and tuples Slam-sl hardly distinguish tuples from re ords. The type(x : Float , y : Float) denes the Cartesian produ t F loat F loat but, in or-der to avoid `boilerplate' in spe i ations, introdu es eld sele tors. Let p be(x > 0.1, y > 0.0), p represents the tuple (0:1; 0) and p.x is the proje tion ofthe rst omponent of the tuple. Some synta ti sugar for modifying a re ordhave been added to Slam-sl through the ex ept operator (n). For instan e, theformula q = p n y > 1.0 states that q represents (x > 0.1, y > 1.0).Sets and sequen es The type expression fStringg groups together values likef"Hello","world"g or fg. Usual mathemati al operations over sets are pre-dened (union +, interse tion , et .).Sequen es like ["Hello","world" or [ belongs to the type [ String . Se-quen es are indexed data olle tions. If s is a sequen e, then s( i ) with is the i-thelement, 1 is the rst index, of the sequen e (if exists), and t = s n 2 > "universe"establishes that t represents ["Hello","universe". Usual operations over se-quen es are predened (append +, insert, dom, rng, in, et ).Both sets and sequen es inherit the properties of Colle tion. Colle tion is a lass over whi h quantiers are allowed.Colle tions and `quantiers' Set and list omprehension, restri ted quanti-ers, and iteration follow a ommon abstra t s heme of `traversing' olle tionsand Slam-sl introdu es the following expressive syntax:Q x in d [where F (x) with E(x)The above Slam-sl expression is a quantied2 expression. Q is the quantiersymbol that indi ates the meaning of the quanti ation by a binary operationand a starting value. d is an obje t of the lass Colle tion. x is the variable thequantier ranges over. F is an optional boolean expression that lters elementsin the olle tion. And E represents the fun tion previously applied to elementsin the olle tion.Some predened quantiers appears in the following table with an informaldes ription:2 We have maintained the term `quantier' be ause it is a generalization of quanti -ation in logi

Page 189: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

182 J. J. Moreno-Navarro, A. Herranz-NievaSymbol Generalizesexists _ with trueexists1 as exists but limiting the ount to 1forall ^ with false.sum + with 0prod with 1 ount in with 0 ( ounting!)sele t sear hingmax maxmaxim maximizerslter ltersmap apply a fun tion to every element in a olle tionSome examples and its intended meaning will be useful in the remainder of thepaper: Example = Meaningforall x in f1,2,4,7,8g with x < 11 = true ount x in f1,2,4,7,8g with x. isPrime = 3sum x in [1..10 where x < 5 with x.pow(2) = 30map x in f1..10g with x / 2 = f0,1,2,3,4,5gmap x in [1..10 with x / 2 = [0,1,1,2,2,3,3,4,4,52.2 Classes and lass propertiesIn Slam-sl, a lass is dened by spe ifying its properties: name, relationshipswith other lasses, and method spe i ations. We will spe ify the lass Sta k forrepresenting sta ks of obje ts:1 lass Sta k23 Sta k inherits Colle tion45 Sta k state Empty6 Sta k state NomEmpty (top : Obje t, rest : Sta k)Line 1 de lares a new lass alled Sta k, line 3 establishes that lass Sta kinherits properties from Colle tion, and lines 5 and 6 dene attributes that arethe internal representation of the lass instan es. Slam-sl permits dening algeb-rai types to indi ate that a synta ti al onstru tion represents lass instan es,in our example, the values Empty and NonEmpty (5, Empty) represent the stateof an empty sta k and the state of a sta k with a unique obje t (the onstant 5)repe tively.Class relationships Slam-sl an be onsiderated as a programming language.As in any other (OO) programming languages, we annot distinguish every kind

Page 190: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

De larative Re e tion and its Appli ation as a Pattern Language 183of relationships between lasses as UML allows. For instan e, aggregation annotbe distinguished from omposition, and some asso iations are impli it throughthe semanti s of methods. Anyway, we an list the following relationships that an be aught stati aly:Aggregation: the state spe i ation of a lass denes an aggregation or om-position between lass instan es and instan es of other lasses.Inheritan e: lass properties an be dened from s rat h or by inheriting themfrom already dened lasses. Overriding of su h properties are onstrainedin Slam-sl, not only the signatures but also the meaning (see subse tion 2.2.Polymorphism: generi polymorphism is introdu ed by permitting introdu- ing arguments in types. Slam-sl allows deferring lasses in the style of Eielbut adding some features from theories (in OBJ terminology [9) as wellas type lasses (a la Haskell [13) playing a more powerful role than C++templates.Method spe i ations The standard methods in sta k obje ts permit re-ating an empty sta k, de ide if a sta k is empty, read the top of the sta k,and push and pop elements. Slam-sl helps the user to lassify dierent kinds ofmethods: onstru tors3, modiers and observers. Let us omplete the sta k lassspe i ation with the denition of its methods: onstru tor empty : Sta kpre : trueemptypost : result = Emptyobserver Sta k.isEmpty : Boolpre : trueisEmptypost : result = (self = Empty)observer Sta k.top : Obje tpre : not self . isEmptytoppost : result = self . top

modier Sta k.push(Obje t)pre: truepush(x)post : result = NonEmpty (rest > self,top > x)modier Sta k.poppre : not self . isEmptypoppost : result = self . restIn Slam-sl an operation is spe ied by a set of rules, every rule involves aguard or pre ondition that indi ates if the rule an be triggered, an operation all s heme, and a post ondition that relates input state and output state.The general form of a rule is the following:pre : P (x; self)op (x )post : Q(x;self; result)3 ` onstru tor' methods are not instan e members but lass members

Page 191: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

184 J. J. Moreno-Navarro, A. Herranz-Nievawhere P (x; self) is a Slam-sl formula involving variables in the argument (x)and the re ipient of the message ( self) in ase of the operation to be either anobserver or a modier. Q(x; self;result) is another formula involving variables inthe argument, the reserved symbol result that represents the omputed valueof the fun tion and self that represents the state of the re eipt of the messagebefore the method invo ation.Some `shorthands' help the user to write formulas on isely and readablely:self an be ommited for re ord elds, as in VDM, expli it fun tion denitionsare allowed and un onditionally true pre onditions an be skipped.Let us explain in detail how Slam-sl handles method overriding. Suppose youhave a lass C with a method m with pre ondition P and post ondition Q. Now,a sub lass C' of C is de lared supplying a new spe i ation for m: pre onditionP 0 and post ondition Q0. As Slam-sl is a formal spe i ation language, it is for esthat the following statement holds:Inheritan e Property : (P ! P 0) ^ (P ^Q0 ! Q)En apsulation En apsulation is an important distin tive in programming lan-guages whi h permits the user to ontrol oupling and maximize ohesion. Nev-ertheless, en apsulation is not en ourage in formal methods. In Slam-sl, as inother obje t oriented programming languages, the user an indi ate the visibilitys ope of ea h method: publi , prote ted or private. If an attribute is indi atedas publi the user get for free an observer, for instan e, in the sta k example thedenition of the observer top ould have been avoided in this way:Sta k state EmptySta k state NomEmpty (publi top : Obje t, rest : Sta k)The language introdu e a broad notion of inheritan e via aggregation. Letus see an example, the following Slam-sl spe denes a read only wrapper forsta ks: lass ROSta kROSta k state (target : Sta k a ept top, isEmpty) onstru tor wrap (Sta k) : ROSta kwrap (s) = ( target > s)Now, the user an return a wrapper instead of the sta k if she does not wantsta k instan es to be modier by lients. This is a pretty unexplored feature.Applying the `shorthands' introdu ed through the se tion, we ould redenethe sta k example in a more on ise way:

Page 192: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

De larative Re e tion and its Appli ation as a Pattern Language 185 lass Sta k(EltClass )Sta k inherits Colle tionSta k stateEmptySta k stateNomEmpty (publi top : EltClass,rest : Sta k) onstru tor empty : Sta kempty = Emptyobserver Sta k.isEmpty : BoolisEmpty = (self = Empty)modier Sta k.push(EltClass )push(x) = NonEmpty (rest > self,top > x)modier Sta k.poppre : not self . isEmptypop = self . restAbstra t lasses In Slam-sl it is quite easy to de lare interfa es, i.e. lasseswith no state and methods that must be redened in the sub lasses. The wayto de lare su h methods is to indi ate that the pre ondition is false. This meansthat this method is not appli able in any ase. Noti e that it is still possible tosupply an adequate post ondition. This post ondition must be preserved in allderived lasses. Those methods that have no denition are impli itly onsideredto have pre ondition false and post ondition true.3 Re e tive featuresIn this se tion we will present some Slam-sl re e tive onstru tions that we willuse in the next se tion.Informally, a re e tive language is a language in whi h interesting aspe tsof its model an be represented and manipulated in the language itself. Re e -tion makes possible advan ed meta-programming appli ations, like rei ationof Slam-sl or other languages, and development of interpreters and omponentbased systems.3.1 Classes and lass relationshipsLike many others obje t oriented languages, Slam-sl lasses are represented asinstan es of a (meta) lass alled Class. The de laration of a lass introdu es animmutable instan e of the lass Class. Let us start with the denition of Class: lass ClassClass state (name : String , st : State , inh : f Classg,inv : Formula, meths : fMethodg)Class invariant :forall m1, m2 in meths with m1.dier (m2)

Page 193: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

186 J. J. Moreno-Navarro, A. Herranz-NievaWe have made a natural reading of `what a lass is': a name, aggregationrelationships, inheritan e relationships, and methods. The lass name is a string,aggregation is represented by an instan e of State plus an instan e of Formularepresenting the invariant, inheritan e is a set of instan es of Class, and, nally,we have added a set of instan es of Method.The invariant in Class establishes that two methods of the lass must dierin the signature4. In other words, method overloading is allowed, but there mustbe an argument of dierent type. Noti e that thanks to this de larative spe i -ation Slam-sl is able to identify those properties that a lass must fulll what ismu h more powerful than the re e tive features of Java or C# that are merelysynta ti .Let us see the denition of State plus auxiliar lasses: lass De larationDe laration state (name : String , type : Class)De laration invariant : name. isIdentierpubli onstru tor makeDe (String, Class ) : De larationobserver De laration . isSub lassOf ( De laration ) : BoolisSub lassOf (d) = self . type = d.type orself . type in d.type. inh lass De Colle tionDe Colle tion state [ De laration publi onstru tor makeEmptyDe : De Colle tionpubli modier De Colle tion .add (De laration) lass StateState inheritan e De Colle tionAmong the interesting operations of lasses, let us show a ouple of them.First of all we will introdu e a onstru tor to reate a lass. Slam-sl automati allygenerates the eld observers5. When a lass is just an interfa e is dete ted by he king if the state is empty and if all the pre ondition of the methods are false.publi onstru tor makeClass(String , State , fClass g, Formula, fMethodsg) : Class4 In fa t, the invariant should in lude some other needed properties related to theinheritan e rules stated in se tion 2.2 set but me omit them for shake of simpli ity.5 only if the user states attributes are `publi ', but in the paper we have assumed it.

Page 194: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

De larative Re e tion and its Appli ation as a Pattern Language 187makeClass (name, st , inh , inv , meths) = (name, st, inh , inv , meths)publi observer Class . isInterfa e : BoolisInterfa e = st .isEmpty and forall m in meths with m.doNothing3.2 MethodsThe lass modelling methods ould be spe ify in the following way: lass MethodMethod state (kind : MethodKind, visibility : Visibility ,name : String , sig : ArgSig, return : Class ,pre : Formula, post : Formula)publi onstru tor makeMethod(MethodKind, Visibility , String , ArgSig, Class ,Formula, Formula) : MethodmakeMethod (k, v, n, sg , rt , pr , ps) = (k , v , n , sg , rt , pr , ps)publi observer Method.typeSig : [ Class typeSig = map d in sig with sig .typepubli observer Method. all : [ String all = map d in sig with sig .namewith the following previous denitions: lass ArgSigArgSig inherits De Colle tionWe have introdu ed a ouple of useful operations: onstru ting a method,abstra ting the type signature just using the argument types (the names are al-most irrelevant ex ept for the pre and post onditions), and omposing a method all with the argument names.On top of them, we an des ribe a number of interesting operations on meth-ods. The rst one (isCompatible) indi ates when two method are equivalent (samename, types and equivalent pre and post onditions). The se ond one ( anInherit)spe ies when a method an override another denition. They must have a o-herent denition (same name and arguments/return type) and the inheritan eproperty must hold.publi observer Method.isCompatible (Method) : BoolisCompatible (m) =kind = m.kind and name = m.name and typesig = m.typesig andreturn = m.return and(pre implies m.pre [m. all/ all ) and post (implies m.post [m. all/ all )publi observer Method. anInherit (Method) : Bool anInherit (m) =

Page 195: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

188 J. J. Moreno-Navarro, A. Herranz-Nievakind = m.kind and name = m.name and sig.length = m.sig.length and( forall i in sig .dom with sig(i ). isSub lassOf(m.sig ( i ))) andreturn = m.return and(m.pre implies pre [ all /m. all ) and (post implies m.post [m. all/ all )Finally, we spe ify operations to de ide when two methods are really dierent(up to argument names) and when a method implements an interfa e method(i.e. pre ondition false):publi observer Method.dier (Method) : Booldier (m) =name /= m.name or(name = m.name and( sig . length /= m.sig. length or(exists i in sig .dom with sig(i ). type /= m.sig(i ). type)))publi observer Method.doNothing : BooldoNothing = (pre = false and post = true)For shake of simpli ity, we assume that all re ord omponents of lassesMethod and Class are publi .3.3 FormulasPossibly, the most interesting Slam-sl re e tive properties are those related toformula management. Slam-sl runtime environment an manage formulas in thesame way the ompiler does, this means formulas an be reated and ompiledat runtime so the user an spe ify programs that manage lasses and lass be-haviors. The following spe i ation of formulas re e ts its abstra t syntax inSlam-sl: lass FormulaFormula state Constant (Bool)Formula state Variable ( String)Formula state And (Formula, Formula)Formula state Or (Formula, Formula)Formula state Implies (Formula, Formula)Formula state Equiv (Formula, Formula)Formula state Expression ( Expression)publi onstru tor makeTrue : FormulamakeTrue = Constant (true)publi onstru tor makeFalse : FormulamakeFalse = Constant (false)publi onstru tor makeVariable (String ) : FormulamakeVariable (s) = Variable ( s)

Page 196: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

De larative Re e tion and its Appli ation as a Pattern Language 189publi onstru tor makeVariable (String ) : FormulamakeVariable (s) = Variable ( s)publi onstru tor makeAnd (Formula, Formula) : FormulamakeAnd (f1,f2) = $f1 and f2$...publi modier substitute (String , Expression)substitute ( var ,expr) =result = ase selfConstant ( ) > selfj Variable (v) > if v = var then Expression ( expr ) else selfj And (f1,f2) > And (f1.substitute(var , expr ), f2 . substitute (var , expr))j Or (f1 , f2) > Or (f1. substitute (var , expr ), f2 . substitute (var , expr))j Implies ( f1 , f2) > Implies (f1 . substitute (var ,expr ),f2 . substitute (var ,expr))j Equiv ( f1 , f2) > Equiv (f1. substitute (var , expr ),f2 . substitute (var , expr))j Expression (e) > e[x/exprWriting formulas with the above interfa e would produ e unreadable spe i -ations so we write instan es of Formula using the Slam-sl own notation between$$ symbols and permitting the ompiler to parse the senten e and generate theexpression. See the denition of the onstru tor makeAnd.Sinta ti sugar for the substitution operation have been introdu ed: f [x/e isthe formula f repla ing all the referen es to the variables x by the expression e.See that we have used that syntax for expressions in the last line of the denitionof substitution operation.4 Appli ation. Design Patterns as Class OperatorsAs an appli ation of the re e tive feautures of Slam-sl let us show how designpatterns [8 an be formalized as lass operators. A given (preliminary) design isthe input of a design pattern. This design is modeled as a olle tion of lasses.The result of the operation is another design obtained by modifying the old lasses and/or reating new ones, taking into a ount the des ription of thedesign pattern.For instan e, onsider you have a olle tion of lasses leafs (e.g. Line, Cir le,Re tangle, ...) that share some operations (e.g. draw, rotate, resize, ...) and youwant to ompose all of them in a wider obje t that either has all of them asparti ular ases and also an olle t some of them inside (e.g. a Figure). TheComposite pattern onsidered as an operator a epts lasses (leafs) as inputand returns two new lasses Component (merely an interfa e) and Composite

Page 197: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

190 J. J. Moreno-Navarro, A. Herranz-Nieva(for the olle tion of omponents) with the ommon operations as methods, andmodifying lasses in leafs to inherit from Component.More spe i ally, design patterns are modeled as a lass with a single fun tionapply that is a lass operator. This pre ondition for this fun tion olle ts thelogi al onditions required to use the pattern with su ess. Basi ally, this meansthat the pattern pre ondition establishes the appli ability of the pattern, talkingin terms of the se tions in the pattern des ription. For instan e, in the Compositepattern we mentioned above, the pre ondition needs to ensure that all the lassesin leafs dene the ommon methods with the same signature.On the other hand the post ondition en ompasses most of the elements of theintent and onsequen es se tions of the pattern des ription. In the Compositepattern, the post ondition establishes that input lasses leafs now inherit fromComponent and lasses Composite and Component are introdu ed, the rst oneinheriting from the se ond one. The Composite state is a olle tion of Componentsand its methods are des ribed by iterative alls to the orresponding leafs meth-ods.In order to des ribe all this elements, the re e tive features play a signi -ant role be ause they allow inspe ting argument lasses and to des ribe new lasses as result. Design patterns an be des ribed by a (polymorphi ) lassDPattern. The method apply des ribes the full behaviour of the pattern by a - epting a olle tion of lasses as arguments (the previous design) and returninga new olle tion of lasses. The lass argument ( oming from the polumorphi denition) is o asionally needed to instru t the pattern about the sele tion of lasses, methods, et . that take part in the pattern. This argument is stored inthe pattern by a dedi ated onstru tor. lass DPattern (T)DPattern state (arg : T)publi onstru tor instantiate (T) : DPatterninstantiate (x)post : result . arg = xpubli fun tion apply ([ Class ): [ Class Inheritan e is used to derive on rete design patterns. It is also needed toinstantiate the type argument and supplying a value for the state. Noti e thatdesign pattern variants is easily supported in our model.Let us des ribe the method by some examples taken from [8. We have hosenone pattern for ea h omponent of the lassi ation: reational, stru tural, andbehavioral patterns. A graphi al des ription omplements the formal denitionusing an OMT-based notation taken again from [8. More examples an be foundin [15.4.1 Composite patternThe Composite pattern is part of the obje t stru tural patterns. It is used to ompose obje ts intro tree stru tures to represent part-whole hierar hies. Us-

Page 198: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

De larative Re e tion and its Appli ation as a Pattern Language 191ing the pattern the lients treat individual obje ts and ompositions of obje tuniformly.When we treat it as a lass operator, we have the olle tion of basi obje tsas argument ( alled the leafs). The result "invents two new lasses Componentand Composite. Component is just an interfa e for all the ommon methods in allthe leaf lasses plus some methods to add, remove and onsult internal obje ts.Composite inherits from Component and stores olle tion of omponents. Theresult also olle ts all the lasses in leafs that are modied by inheriting fromComponent. The methods in Composite an be grouped in two parts. On onehand, we have methods to add and remove a omponent, and also to onsult theith element in the omponent olle tion (getChild). On the other hand, we haveall the ommon methods of the leafs that have a very simple spe i ation byiterative alling the same operation in all the omponents. See gure 1 for the omplete Slam-sl spe i ation.4.2 State patternThe State pattern belongs to the obje t behavioral lassi ation. It an be usedto allow an obje t to alter its behavior when its internal state hanges. Theobje t will appear to hange its lass. When studied as a lass operator, it takesa olle tion of on rete state lasses as argument. All these lasses are presentin the result, ex ept that they inherit from the State lass des ribed below. Theresult adds two lasses: one to abstra t the behavior of all the on rete states, alled State, that represents an interfa e ontaining all the ommon methods inall the on rete states. The se ond one is Context that is designed for allingstate operations. It ontains a State as attribute and all the ommon methods,des ribed as merely alls to the orresponding operation of the attribute. This lass an be rened by inheritan e to introdu e more fun ionality. The ompletespe i ation an be found in gure 2.4.3 Builder patternThe Builder pattern (belonging to the obje t reational patterns) is designed toseparate the onstru tion of a omplex obje t from its representation, so thatthe same onstru tion pro ess an reate dierent representations.As a lass operator, the Builder patterns takes a olle tion of on rete build-ers as an argument. Another lass dire tor is part of the arguments and it isassumed that it ontains the algorithm to onstru t obje ts. It is also assumedthat all the on rete builders share some operations that are used to build ob-je ts. Those methods are alled builders and need to be dened in all the on retebuilders. The argument lass is a boolean fun tion isBuilder that is applied tomethods in the on rete builders, dete ting if they are builders or not. Methods lassied as builders are abstra ted into the Builder lass. The on rete buildersappear in the result but they are for ed to inherit from Builder. The dire tor lass is modied in the following way: on e an attribute belongs to one of the

Page 199: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

192 J. J. Moreno-Navarro, A. Herranz-Nieva on rete lasses it is abstra ted to the Builder lass. See gure 3 for the detaileddes ription.4.4 Slam-sl as a pattern languageThe formalization of design patterns in terms on lass operators and using the(de larative) re e tive features of an spe i ation language has a number ofadvantages: Coherent spe i ations of patterns are essential to improve their omprehen-sion and to reason about their properties. It is possible to develop tools for supporting design patterns. In fa t weare interested in introdu ing them in existing development environments(as Visual Studio, Visual Age, et .). The tool an allow applying a designpattern to the proje t you are working on. The proje t should be modieda ording to our des ription adopting the design pattern. In this way, we an apply design patterns to already existing ode and with "every dayexisting CASE environments. Patterns an be ombined by simply applying fun tion omposition. The fun tional semanti s of Slam-sl an be modied to support fun tional-logi semanti s. Fun tional-logi languages amalgamate the main features offun tional languages and Prolog-like languages, in su h a way that inversefun tions a be omputed. This means that, in prin iple, we an identify a on rete design patterns into an existing design/spe i ation.In the literature we an nd some other formalizations of design patterns.The work in [1 is fo used on the formalization of ar hite tural design patternsbased on an obje t oriented model integrated with a pro ess oriented methodto des ribe the patterns. [14 presents a way to formalize temporal behaviorsof design patterns, so ommuni ation between obje ts is the main goal of thespe i ation that uses primitives of a pro ess algebra. Although both use anspe i ation language for the formalization they do not propose any supportingtool and re e tion is not used. The proje t proposed in [5, 6 are more fo used onproviding tools that intera t with existing ode. They use a metaprogramminglanguage based on a (limited form of) verbal spe i ation. A tool an read it andprodu e what they all a tri k, basi ally an algorithm to manipulate programs.They have also designed a visual language for spe ifying patterns (LePus). Theyshare some of our goals and even more, but we laim that we an get a similarpower with a simpler approa h.In fa t, thanks to its de larative re e tion features, Slam-sl an be onsideredas a pattern language. On e you an model a patterns as a lass operator, Slam-sl an be used to spe ify it and this spe i ation an be used to instru t theasso iated tool to apply the pattern to existing designs and programs.5 Con lusionThe pre ise denition of software design patterns is a prerequisite for allow-ing tool support in their implementation. Thus omprenhensive spe i ations

Page 200: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

De larative Re e tion and its Appli ation as a Pattern Language 193of patterns are essential not only to improve their understanding and propertyreasoning, but also for supporting an automatization of their use.We have proposed a formal spe i ation of design patterns as lass operators.Of ourse, our approa h is not ne esarily \better" than others. In fa t, dierentformalizations fo used on a parti ular aspe ts yields to dierent tools. We onlyen ourage the fa t that it is very simple and easy to automatize in existingdevelopment tools. On the ontrary, it is not already lear that all the designpatterns an be modeled as lass operators (for instan e the Fa tory Methodthat an only be seen as a lass operator in a very tri ky way).We have also presented the de larative re e tion hara teristi s of SLAM.The main advantage with respe t to other re e tive languages is that the se-manti s of a lass method an be inspe ted (by onsulting pre and post ondi-tions) what is very useful for a number of appli ations like omponent basedsystems and the denition of grey box frameworks [2. Our on lusion is thatde larative re e tion is a key feature for: A simple formalization of design patterns in terms of lass operators. Supporting on rete tools that permit applying design patterns to existing ode.Referen es1. P. Alen ar, D. Cowan, and C. Lu ena. A Formal Approa h to Ar hite tural DesignPatterns. In M. Gaudel and J. Wood o k, editors, FME'96: Industrial Benet andAdvan es in Formal Methods, LNCS, pages 576594. Springer Verlag, 1996.2. M. Bue hi and W. We k. The Greybox Approa h: When Bla kbox Spe i ationHide too mu h. Te hni al Report TUCS-TR-297a, Turku University, Findland,1999.3. C# language spe i ation. Draft standard ECMA/TC39/TG2/2000/3.4. M. Clavel, F. Duran, S. Eker, P. Lin oln, N. Mart-Oliet, J. Meseguer, andJ. Quesada. A Maude Tutorial. CSL, SRI International, Mar h 2000.5. A. Eden, A. Yehudai, and J. Gil. Pre ise Spe i ation and Automati Appli a-tion of Design Pattern. In Pro . 12th Annual Conferen e on Automated SoftwareEngineering, 1997.6. A. Eden, A. Yehudai, and J. Gil. LePUs - a De larative Pattern Spe i ationLanguage. Te hni al Report 326/98, Department of Computer S ien e, Tel AvivUniversity, Israel, 1998.7. B. Foote and R. Johnson. Re e tive Fa ilities in Smalltalk-80. In Pro . OOPSLA'89, pages 327335, 1999.8. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns - Elements ofReusable Obje t Oriented Software. Addison-Wesley, 1995.9. J. A. Goguen, T. Winkler, J. Meseguer, K. Futatsugi, and J.-P. Jouannaud. Intro-du ing OBJ. Te hni al report, Oxford + SRI, O tober 1993.10. J. V. Guttag and J. J. Horning. A tutorial on Lar h and LCL, a Lar h/C interfa elanguage. In S. Prehn and W. J. Toetenel, editors, VDM91: Formal SoftwareDevelopment Methods. Springer-Verlag Le ture Notes in Computer S ien e 551,O tober 1991.

Page 201: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

194 J. J. Moreno-Navarro, A. Herranz-Nieva11. A. Herranz and J. Moreno-Navarro. Towards Automating the Iterative RapidPrototyping Pro ess with the SLAM System. In Pro eedings VI Spanish Conferen eon Software Engineering, pages 217228, 2000.12. C. B. Jones. Systemati Software Development Using VDM. Prenti e Hall, 1986.13. S. P. Jones and J. Hughes, editors. Report on the Programming Language Haskell98. A non-stri t Purely Fun tional Language. February 1999.14. T. Mikkonen. Formalizing Design Patterns. In Pro . ICSE'98, pages 115124.IEEE Computer So iety Press, 1998.15. J. Moreno Navarro and A. Herranz Nieva. Design Patterns as Class Operators.submitted to OOPSLA, 2001.16. The SLAM site. http://lml.ls.fi.upm.es/slam.17. J. B. Wordsworth. Software Development with Z. Addison-Wesley, 1992.

Page 202: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

De larative Re e tion and its Appli ation as a Pattern Language 195Composite arguments Composite results

Leaf operation()

Leaf operation()

Leaf operation()

Leaf operation()

Leaf operation()

Leaf operation()

Component operation() add(Component:) remove(Component:) getChild(Nat:)

Composite operation() add(Component:) remove(Component:) getChild(Nat:)

children

forall g in children g.operation() lass CompositeComposite inherits DPattern ()publi fun tion apply ([ Class ): [ Class pre : (not leaf . isEmpty ) and (not ommonMethods.isEmpty)apply ( leafs )post : result = [ omponent, omposite +map in leafs with n inh . insert ( omponent)wherem in ommonMethods equiv (forall l in leafs with m in l .meths) omponent = makeClass ("Component", emptyDe , fg, $true$,map m in (builderMethods + [ reate, add, remove, getChild )with m n pre = $false$ and post = $true$) omposite = makeClass ("Composite", [makeDe ( hildren, [ omponent), fg, $true$,[ reate , add, remove, getChild +map m in builderMethods gen (m) reate = makeMethod($ onstru tor$, $publi $, " reate", emptyDe , $true$, $(result = [)$)add = makeMethod($modier$, $publi $, "add", [makeDe (" ", omponent), $true$,$(result = hildren. insert ( ))$)remove = makeMethod($modier$, $publi $, "remove", [makeDe (" ", omponent), $true$,$( result = hildren.remove ( ))$)getChild = makeMethod($observer$, $publi $, "getChild", [makeDe ("i", Nat), $true$,$( result = hildren[ i )) $gen (m) = m n pre = $(forall in hildren with m.pre [this/ )$ andpost = $(result = map in hildren with makeCall (m.name, [ +m. all))$Fig. 1. Composite pattern spe i ation.

Page 203: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

196 J. J. Moreno-Navarro, A. Herranz-NievaState arguments State results

ConcreteState handle()

ConcreteState handle()

ConcreteState handle()

ConcreteState handle()

ConcreteState handle()

ConcreteState handle()

Context request()

state.handle()

State handle()

state

lass StateState inherits DPattern ()publi fun tion apply ([ Class ): [ Class pre : (not on reteState . isEmpty ) and (not ommonMethods.isEmpty)apply ( on reteStates )post : result = [ ontext , abs state +map in on reteStates with n inh . insert (state)wherem in ommonMethods equiv (forall l in leafs with m in l .meths)abs state = makeClass ("State", emptyDe , fg, true,map m in ommonMethods with m n pre = $false$ andpost = $true$) ontext = makeClass ("Context", [makeDe (stt, abs state ), fg, $true$,map m in ommonMethods transfer (m)transfer (m) = m n post = $(result = stt.makeCall (m.name, m. all))$Fig. 2. State pattern spe i ation.

Page 204: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

De larative Re e tion and its Appli ation as a Pattern Language 197Builder arguments Builder results

ConcreteBuilder buildPart() otherMethod()

ConcreteBuilder buildPart() otherMethod()

ConcreteBuilder buildPart() otherMethod()

Director

construct()builder

forall b in builder b.buildPart()

ConcreteBuilder buildPart() otherMethod()

ConcreteBuilder buildPart() otherMethod()

ConcreteBuilder buildPart() otherMethod()

Director

construct()builder

forall b in builder b.buildPart()

Builder buildPart()

lass BuilderBuilder inherits DPattern (Methods:Bool)publi fun tion apply ([ Class ): [ Class pre : ( lasses . length > 2) and (not builderMethods.isEmpty)apply ( lasses )post : result = [ builder +[ dire tor n st = map d in dire tor . st with abstra tToBuilder (d) +map in on reteBuilders with n inh. insert ( builder )wheredire tor = lasses . prex (1) on reteBuilders = lasses . suÆx (1)isBuilder = argm in ommonMethods equiv (forall l in on reteBuilders with m in l .meths)builderMethods = lter m in ommonMethods with isBuilder (m)builder = makeClass ("Builder", emptyDe , fg, $true$,map m in builderMethods with m n pre = $false$ andpost = $true$)abstra tToBuilder (d) =if d.type in on reteBuildersthen d n type = builderelse d Fig. 3. Builder pattern spe i ation.

Page 205: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 206: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Un lenguaje modelo para la deni ion y analisisde refa toriza ionesYania Crespo, Valentn Carde~noso, and Jose Manuel MarquesDepartamento de Informati a. Universidad de Valladolid. Espa~na.fyania, valen, jmm ginfor.uva.esResumen En este trabajo se propone el lenguaje modelo MOON onsu iente poder expresivo para representar las onstru iones abstra tasne esarias en la deni ion y analisis de refa toriza iones. Gra ias a es-te modelo, el esfuerzo de refa toriza ion para un lenguaje parti ular sereparte entre la tarea de representar enMOON el odigo y la de refa to-riza ion propiamente di ha en el lenguaje modelo. Este ultimo esfuerzo,no obstante, es laramente reutilizable, lo que ha e que en onjunto elempleo de nuestro lenguaje modelo reduz a sustan ialmente el esfuerzode refa toriza ion. Tambien se ha denido una arquite tura y un pro- eso para integrar el modelo en herramientas de refa toriza ion. Como aso on reto se detalla la redu ion a MOON de un lenguaje de pro-grama ion bien ono ido y se ilustra la viabilidad de nuestra propuestades ribiendo un algoritmo de refa toriza ion on reto.Palabras lave: transforma ion de programas, refa toriza ion, abstra - ion de lenguajes, modelo de familia de lenguajes.1 Introdu ionEl proposito fundamental de esta omuni a ion es presentar brevemente un len-guaje modelo denido on un objetivo muy on reto, fa ilitar la labor de ladeni ion y analisis de refa toriza iones y avanzar ha ia la posibilidad de esta-ble er una ierta independen ia del lenguaje en este ampo. Fundamentalmentepresentaremos el analisis razonado de las de isiones del dise~no del lenguaje mo-delo y la forma en que este apoya las tareas de refa toriza ion. Hemos empleadoel modelo en una apli a ion on reta que se presenta omo aso de estudio de lafa tibilidad de proseguir por este amino.En lo que sigue, la presenta ion se organiza de la siguiente forma. La Se ion 2introdu e el problema de la refa toriza ion y la dependen ia del lenguaje de loselementos objetos de la transforma ion. En la Se ion 3 se exponen otros trabajosque se rela ionan on la aproxima ion que hemos tomado. Posteriormente en laSe ion 4 se dene y se analiza el modelo propuesto y en la Se ion 5 se expli a elpapel del modelo en la deni ion y analisis de refa toriza iones. La Se ion 6 esla presenta ion de un aso de estudio, mientras que en la Se ion 7 se on luye.

Page 207: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

200 Y. Crespo, V. Carde~noso, J. M. Marques2 Refa toriza ion de softwareEl termino refa toriza ion fue introdu ido por primera vez por Opdyke en [1.Las refa toriza iones son transforma iones de elementos de software Orientadoa Objetos (OO) que, realizando reestru tura ion y reorganiza ion, preservanel omportamiento. Reestru turar es transformar la estru tura interna de unelemento de software. Una reestru tura ion que transforma la manera en que serela ionan diferentes elementos se di e una reorganiza ion.En el area de la refa toriza ion de software nos en ontramos on una intensaa tividad a tualmente. En este ampo se trabaja para abordar diferentes as-pe tos tales omo la propia deni ion de opera iones de refa toriza ion [1, la onstru ion de herramientas que apoyen la eje u ion de refa toriza iones [2,la elabora ion de atalogos de \patrones" de refa toriza ion que ayuden a losdesarrolladores a de idir uando refa torizar y que opera iones apli ar [3, lain orpora ion de te ni as para poder llegar a inferir automati amente uando yque refa torizar [4. Tambien se en uentran trabajos entrados en el analisis ydemostra ion de preserva ion del omportamiento al apli ar una refa toriza ion[5 y en la introdu ion en el i lo de vida de metodos de desarrollo [6.Denir una refa toriza ion pasa por denir las opera iones a realizar, mostrarque las reglas de validez se preservan y proponer uando eje utar la refa toriza- ion. Finalmente, para que una refa toriza ion denida pueda ser apli ada e az-mente, es deseable ontar on una herramienta que la reali e automati amenteo al menos asista en su eje u ion.La herramienta debe garantizar que a partir de elementos orre tos, una vezapli ada la transforma ion, se obtengan elementos orre tos. Para esto es ne- esario ono er de forma pre isa la estru tura de los elementos a transformary sus reglas de validez. Esto ha ondi ionado que los trabajos realizados hastael momento en refa toriza ion sean dependientes del lenguaje que dene a loselementos objeto de las transforma iones, ha iendo que se multipliquen los es-fuerzos en la deni ion de las refa toriza iones por ada lenguaje en parti ulary por ada pro eso de desarrollo de las herramientas que las eje utan.Sin embargo, la experien ia en el area nos lleva a las siguientes ideas. Enprimer lugar, las refa toriza iones no modi an el omportamiento sino la ar-quite tura que se ha dise~nado para la solu ion, de modo que no todas las ons-tru iones de los lenguajes son importantes a la hora de denir e implementarrefa toriza iones. Por otra parte, de la experimenta ion on diferentes lenguajespodemos dete tar que aunque di hos lenguajes tengan ara tersti as diferentes,si enfo amos aquellas que han sido fundamentales para denir e implementar unarefa toriza ion, en ontramos mu hos on eptos omunes. La perspe tiva esboza-da por las ideas anteriores se resume en que podemos avanzar ha ia estable er,al menos, una ierta independen ia del lenguaje.Nuestro enfoque para abordar esta nueva perspe tiva onsiste en on entrar-nos en los aspe tos omunes y en las onstru iones que interesan desde el puntode vista de la refa toriza ion, deniendo un lenguaje modelo que responda aestas ara tersti as. De esta forma, ontando on di ho modelo, omo primerpaso, podemos denir las refa toriza iones para las onstru iones del modelo y

Page 208: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Un lenguaje modelo para la deni ion y analisis de refa toriza iones 201redu ir los esfuerzos, de parti ularizar para un lenguaje, a mirar ada lenguajepor el prisma del modelo.Otros aspe to muy importante, y mu has ve es pasado por alto, en el ambitode las refa toriza iones es el analisis de las onse uen ias que tiene su apli a- ion para los elementos que dependen de los transformados y para los objetospersistentes que fueron reados previos a la modi a ion. La deni ion de lasrefa toriza iones sobre el modelo tambien ayuda a abordar esta tarea. En [7 he-mos denido un lenguaje modelo para el analisis y deni ion de refa toriza iones,que posteriormente hemos apli ado en asos de estudio.3 Trabajos rela ionadosEn [8 se presenta el modelo FAMIX omo un meta-modelo para alma enarinforma ion en un repositorio que permita la integra ion de diferentes entornosde desarrollo de software on soporte para la refa toriza ion y por otro ladose presenta un estudio de fa tibilidad, a partir del analisis de dos lenguajes,Java y Smalltalk, para validar su propuesta de meta-modelo que abstraelas ara tersti as ne esarias para realizar refa toriza iones. Java y Smalltalkson lenguajes on diferen ias muy mar adas omo la presen ia de meta- lases enSmalltalk y de interfa es en Java, y de tipado estati o en Java y dinami oen Smalltalk. De esta forma obtienen un modelo que onsidera la abstra ionde estas ara tersti as.En ambio en nuestro modelo nos hemos on entrado en abstraer ara -tersti as de lenguajes basados en lases, estati a y fuertemente tipados y ongeneri idad, ha iendo espe ial enfasis en la onsidera ion de ara tersti as avan-zadas en uanto a heren ia y generi idad. Hemos omprobado en la implemen-ta ion para Java de la refa toriza ion que denimos en [9, que la adapta ionpara onsiderar interfa es a lo Java no es un problema para nuestro modelo, nila ausen ia de tipos. Sin embargo reemos que la onsidera ion de meta- laseses un problema mayor para nuestro modelo, al igual que la in lusion en FAMIXde generi idad al mismo nivel que en el nuestro, es tambien un problema mayor.Una lnea interesante sera intentar fusionar ambos modelos.Hasta donde ono emos, este es el uni o trabajo que se ha publi ado on unproposito igual al nuestro: ir ha ia un motor de refa toriza iones independientedel lenguaje.La idea, en el sentido de brindar soporte para multiples lenguajes en unaherramienta de refa toriza ion, fue esbozada en [10, aunque tambien puede ins-pirarse en las dire iones de investiga ion que propone [11 en lo que denomina\te nologas para lenguajes generi os".A ontinua ion presentamos el enfoque de nuestra propuesta mediante lades rip ion, primeramente, del lenguaje modelo denido y su posterior apli a iona la deni ion, el analisis y la implementa ion de refa toriza iones, mostrandonalmente un aso de estudio.

Page 209: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

202 Y. Crespo, V. Carde~noso, J. M. Marques4 El lenguaje MOONLa esen ia del lenguaje modelo que hemos propuesto radi a en intentar ser mi-nimal, en el sentido de enfo ar solamente en las onstru iones que aportaninforma ion fundamental a la hora de denir y analizar refa toriza iones, y a lavez intentar que sea lo mas general posible para dar abida a una amplia familiade lenguajes. Con este objetivo se han estudiado un onjunto de lenguajes paraabstraer sus ara tersti as. El resultado de di ho estudio se puede onsultar en[7. Con este objetivo se han denido variantes en el modelo. La varia ion se entra en las reglas de tipos. Tener bien denidas las reglas de las onstru ionesdel lenguaje y del sistema de tipos permiten analizar si las refa toriza iones, unavez apli adas, dan lugar a elementos orre tos en uanto a estru tura y tipos.El lenguaje modelo minimal-general que se dene se denomina MOON1.MOON no intenta ser un lenguaje para programar sino para abstraer omo serepresentan estru turalmente los prin ipales on eptos y onstru iones a teneren uenta para denir y analizar refa toriza iones. En este lenguaje las lasesson implementa iones impl itas de tipos y se onsidera la presen ia de heren iamultiple. La estru tura de los tipos que di has lases implementan, estara dadapor un modelo de espe i a ion de tipos basado en estru tura y signatura.MOON se basa en istBOPL, lenguaje denido en [12. El lenguaje istBO-PL es una extension que se ha e a partir de otro lenguaje nombrado BOPL2,a~nadiendo a este ultimo: de lara ion de tipos, heren ia y generi idad. BOPL fuedenido omo un lenguaje basi o a partir del ual se van a~nadiendo propieda-des, hasta llegar a istBOPL. BOPL es un lenguaje basado en lases mientrasque istBOPL es un lenguaje OO, segun la lasi a ion denida en [133. Estoslenguajes fueron dise~nados para ilustrar onstru iones basi as, son lenguajesbasi os sin adornos. En la Figura 1 se muestra la rela ion de las ara tersti asde MOON respe to a sus ante esores.Se ha de idido basarMOON en istBOPL porque este ultimo onstituye untron o omun a la familia de lenguajes estudiados y porque ya asume simpli- a iones que nos ayudan en el intento de bus ar minimalidad. La presenta ionde MOON la haremos en dos partes, la primera re eja la busqueda de aun masminimalidad a partir de istBOPL y la segunda la obten ion de mas generalidada partir de la onsidera ion de mas omplejidad en la heren ia, la generi idad yel sistema de tipos.1 MOON es un a ronimo de Minimal Obje t-Oriented Notation.2 BOPL e istBOPL son a ronimos de Basi Obje t Programming Language y deInheritan e, Substitution and Types for BOPL, respe tivamente.3 Breve resumen de la lasi a ion de Wegner: 1- lenguaje basado en objetos, ofre e onstru iones para denir objetos, 2- lenguaje basado en lases, ofre e onstru io-nes para denir lases y objetos, 3- lenguaje orientado a objetos, ofre e onstru io-nes para denir lases, objetos e in orpora el me anismo de heren ia.

Page 210: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Un lenguaje modelo para la deni ion y analisis de refa toriza iones 203MOON

Minimal Object Oriented Notation

IST BOPL inheritance, substitution and types for BOPL

[Palsberg y Schwartzbach, 1994]

BOPL Basic Object Programming Language

[Palsberg y Schwartzbach, 1994]

BOPL +declaración de tipos + reglas de tipos + herencia (sencilla) y ligadura tardía + genericidad

IST BOPL + herencia múltiple + acotación en la genericidad + 3 variantes del sistema de tipos - envíos de mensajes en cascada - instrucciones de control del flujo de ejecución - algunas formas de expresiones

> definición de clases > creación de objetos > autorreferencia > envío de mensajes > asociación de objetos a entidades > instrucciones de control del flujo de ejecución > expresiones Figura 1. Pre edentes de MOON.4.1 Simpli a iones a partir de istBOPLEn el modelo MOON se propor iona una gramati a de la sintaxis on retapara la des rip ion de las lases, deni iones de la sintaxis abstra ta y reglasformales del sistema de tipos ( omunes y variantes). A partir de la gramati a dela des rip ion de una lase se propor iona la deni ion de la estru tura de losobjetos y de los objetos persistentes.La gramati a que se presenta en el Apendi e A dene la sintaxis on reta deMOON y por tanto determina la estru tura de las lases que se pueden denir.Un modulo en MOON se orresponde on la deni ion de una lase (regla1). Cada lase tiene atributos y metodos que pueden ser rutinas o fun iones. Unarutina eje uta un onjunto de instru iones y una fun ion omputa un resultado.Los atributos y los metodos denen las propiedades de las lases. Las signaturasde las propiedades intrnse as de las lases se de laran en el grupo de signaturas(reglas 5 y 13). La regla 23 dene las anota iones de tipo que se pueden ha eren MOON, a la que ondu en las de lara iones de entidades (reglas 19 y 22).Sinta ti amente un envo de mensaje a una entidad se denota, omo es ha-bitual, on la nota ion de punto, es de ir: entidad.mensaje. En MOON se denesin perdida de generalidad, que no se permiten envos de mensajes (llamadas)en as ada. Todo envo de mensajes en as ada se puede transformar en una su- esion de envos de mensajes. Las llamadas en as ada, e1.e2. . . en (n > 2), queaparez an en los elementos de un lenguaje en parti ular, que se mira desde elprisma de MOON, al margen de los argumentos que pueda tener ada mensajeinvolu rado en la as ada, se pueden redu ir onsiderando la siguiente se uen iade instru iones MOON:t1 := e1:e2;t2 := t1:e3; : : :

Page 211: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

204 Y. Crespo, V. Carde~noso, J. M. Marquesti1 := ti2:ei; (2 < i < n)si e1:e2 : : : en es una expresion, tn1 := tn2:ensi e1:e2 : : : en es una instru ion, tn2:en (1)Esta redu ion del envo de mensajes en as ada no va en aminada a dar unaalternativa al tratamiento dinami o ni a la genera ion de odigo, sino a ha er untratamiento estati o simpli ado de la as ada. De esta forma las dependen iasimpl itas de tipos que o asiona una as ada se eliminan, quedando todas lasdependen ias expresadas de forma lara y expl ita omo propone la ley de De-meter [14. La elimina ion de las llamadas en as ada esta re ogida en las reglas36 y 41.Por otra parte, los argumentos reales en los envos de mensajes solamentepodran venir dados por expresiones atomi as (una entidad o una onstante ma-niesta). Este aso tampo o impli a una perdida de generalidad puesto que si sequiere analizar la presen ia de una expresion no atomi a exp , e1. . . en (n > 1) omo argumento real en un envo de mensaje tal que a.f(e1. . . en), el analisis sepuede ha er sobre la apli a ion de (1) a e1. . . en y la sustitu ion a.f(tn1). Esta onsidera ion se re eja en la regla 44.En el lenguaje istBOPL, que se tomo omo punto de partida para denirMOON, las formas de expresiones admitidas son: expresiones atomi as, expre-siones de envo de mensajes, expresiones binarias y expresiones unarias. De lasformas anteriores de expresiones, enMOON no se in luyen las dos ultimas (regla39). Las expresiones binarias o unarias se pueden onsiderar omo una expresionde envo de mensaje (e.g. a+b omo a.+(b)).Tambien en istBOPL el onjunto de instru iones esta formado por: instru - ion ompuesta, instru ion de asigna ion, instru ion de rea ion de objetos,instru ion de envo de mensajes, instru ion ondi ional (if EXPR then INSTRelse INSTR) e instru ion de repeti ion (while EXPR do INSTR). De este onjuntode instru iones, en MOON se eliminan las dos ultimas, ondi ional y de re-peti ion que son las instru iones de ontrol del ujo de eje u ion denidas enistBOPL (regla 32). Esto se debe a que desde el punto de vista de los analisisque interesan a la hora de refa torizar, la presen ia en un lenguaje parti ular deinstru iones omo estas se miran desde el prisma de MOON omo: 1: Boolean; 2: Boolean; 1 := EXPR; 2 := 1.eq(BOOLEAN CONSTANT);INSTRDe esta forma se pueden analizar laramente las rela iones de dependen iasentre lases, las aso ia iones de entidades, la orre ion en uanto a tipos, et .,sin prestar aten ion a mas detalles.4.2 Reglas y variantes del sistema de tipos de MOONA partir de istBOPL, para denirMOON en la busqueda de re ejar la riquezade on eptos de una mayor familia de lenguajes, se a~nade la apa idad de de la-rar heren ia multiple de lases y una amplia gama de modi adores de heren ia,

Page 212: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Un lenguaje modelo para la deni ion y analisis de refa toriza iones 205se a~nade tambien la apa idad de a otar los parametros formales de una lasegeneri a y se enrique e el sistema de tipos onsiderando algunas variantes.En el sistema de tipos de MOON: se onsidera la existen ia un tipo universal U que es implementado por una lase predenida de nombre Obje t. Toda lase hereda de Obje t de formaimpl ita, dire ta o indire tamente. se onsidera la existen ia de lases predenidas que son implementa ion detipos basi os de objetos. no se denen rela iones entre los tipos basi os. se dene un nu leo de reglas omunes y variantes.Las reglas omunes se denen de forma similar al sistema de tipos de Fundes rito en [15, teniendo en uenta las observa iones aportadas en [16, y la orresponden ia de renombramiento que se utiliza en la deni ion de subtipode [17. En la variante 1) las reglas de la heren ia y la asigna ion polimor ase basan en las reglas de subtipado ( ontravarianza) y los tipos parametri osse a otan mediante subtipado, un ejemplo de lenguaje parti ular que se adaptaa esta variante de MOON es Trellis/Owl. En la variante 2) las reglas dela heren ia se basan en las reglas de subtipado ( ontravarianza) y los tipos pa-rametri os se a otan mediante lausulas tal que4, un ejemplo de lenguaje que seadapta a esta variante de MOON es Theta. En la variante 3) las reglas de laheren ia se basan en reglas de onformidad ( ovarianza) y los tipos parametri osse a otan mediante onformidad, un ejemplo de lenguaje que se adapta a estavariante de MOON es Eiffel.Un lenguaje parti ular que no in luya generi idad se puede mirar fa ilmentedesde el prisma de MOON, igualmente lenguajes omo C++ que in luyen unaforma muy rudimentaria de generi idad en la que no hay a ota ion. En estos asos lo uni o que su ede es que se simpli a aun mas el modelo. Lo mismopodemos de ir de lenguajes sin anota iones de tipo.La deni ion de MOON tiene omo limita ion que no permite fa ilmente eltransito a poder modelar lenguajes on nivel meta avanzado, omo Smalltalk.Pero este es un aspe to que podremos ata ar en un futuro tomando omo baselo que se ha desarrollado en FAMIX para ese aso.4.3 Estru tura de los objetosLa deni ion de la estru tura de los objetos depende en ultima instan ia de laestru tura de las lases y de la deni ion de los tipos ompletamente instan ia-dos que di has lases implementan. Cono iendo la estru tura de los objetos deun tipo dado, se podra analizar las onse uen ias de la apli a ion de las refa -toriza iones para evaluar si son respetuosas on los objetos, lo que ondu ira asaber si es ne esario ha er, lo que en bases de datos se denomina, migra ion depobla iones.4 lausulas tal que, del termino en ingles where lauses.

Page 213: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

206 Y. Crespo, V. Carde~noso, J. M. MarquesLos objetos forman parte de la extension de algun tipo no parametri o o dealgun tipo parametri o ompletamente instan iado. El modelo de tipos asumidodene que la estru tura de un tipo esta dada por un re ord uyos ampos se orresponden on las signaturas de las propiedades del tipo, atributos y metodos.Por eso es inmediato pensar en la estru tura de un objeto omo el valor de unre ord. El valor de un re ord ontiene los valores de ada ampo denido en elre ord.Digamos enton es que en el re ord que representa el objeto tenemos los valo-res de los ampos que se orresponden on atributos, el valor orrespondiente alidenti ador del tipo del objeto, un ampo uyo valor sera el identi ador uni odel objeto al que se le suele denominar oid y un ampo que indi a donde en on-trar las implementa iones de los metodos. Este ampo se ono e omo referen iaa la tabla de metodos.Los valores de los atributos de un objeto en MOON pueden ser: una re-feren ia a otro objeto o onstantes maniestas (regla 40, Apendi e A). Comoreferen ia a otro objeto bastara tener el valor de su oid. Esto ha e homogeneo elvalor de los atributos en la estru tura de los objetos persistentes y de los objetosen eje u ion. Por laridad asumimos que los valores son homogeneos, es de ir,las referen ias a objetos son oids.La estru tura de los objetos MOON, en presen ia de heren ia de sus lases,es una estru tura basada en on atena ion [18. Esta es la forma mas fre uente,segun hemos dete tado, en las implementa iones de los lenguajes revisados.Se dene que los objetos persistentes tienen la misma estru tura que losobjetos en eje u ion ex epto la referen ia a la tabla de metodos pues esta se a -tualiza uando el objeto se arga desde el soporte externo durante una eje u ion,utilizando el valor del identi ador del tipo del objeto.El analisis de las onse uen ias para los objetos de la apli a ion de las refa -toriza iones, se ha e a partir de la estru tura de los objetos persistentes. Puedepare er que para este analisis tambien hara falta denir la estru tura de la ta-bla de metodos pues, evidentemente, uando se apli a una refa toriza ion, estapuede ambiar. Una vez que se reali e la refa toriza ion, hay que volver a \ om-pilar" (o realizar una a ion on un efe to similar) las lases transformadas. Deesta forma la tabla de metodos se regenera. Esto no se re eja en la estru turadel objeto pues solamente tiene una referen ia a la tabla. Para lo que s tiene onse uen ias es para los mensajes que el objeto es apaz de responder. Perodeterminar esto se orresponde on el analisis de las onse uen ias de la refa to-riza ion para los lientes. A partir de la estru tura del objeto lo que se analiza essi los objetos persistentes, que estan dados fundamentalmente por los valores desus atributos, siguen siendo validos en una sesion posterior a la refa toriza ion.5 MOON y refa toriza ionSe ha denido una arquite tura y un pro eso para integrar el modelo en herra-mientas de refa toriza ion. En este apartado presentamos ambos aspe tos.

Page 214: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Un lenguaje modelo para la deni ion y analisis de refa toriza iones 207Repositorio de clases

preanalizadas según MOON an

aliz

ador

es s

egún

MO

ON

recu

pera

dore

s

otras herramientas de apoyo

refactorizadores

clase en lenguaje objetivo

clase en lenguaje objetivo

clase en lenguaje objetivo

clase en lenguaje objetivo

clase en lenguaje objetivo

clase en lenguaje objetivo Figura 2. Arquite tura de refa torizadores basada en MOON.5.1 Arquite turaEn el mar o de MOON denimos una arquite tura de refa torizadores en laque entran lases a un repositorio pasando por un analizador que extrae loselementos relevantes (denidos por MOON) y alma ena el resultado en formade un objeto persistente uya estru tura responde a un modelo de lases quedes ribe las partes mas relevantes del arbol sinta ti o que se genera del analisis deuna lase MOON. A este formato le llamamos formato de lases preanalizadas.La entrada de una lase al repositorio impli a la a tualiza ion de las rela ionesentre las lases preanalizadas. Las rela iones entre las lases preanalizadas se handenido formalmente en el modelo de MOON omo un Grafo de Dependen iasque tiene en uenta las rela iones de heren ia y liente entre las lases, as omolas rela iones de heren ia y liente on sustitu ion (para los parametros formales)en presen ia de lases generi as. El modelo formal esta denido mediante ungrafo dirigido etiquetado.Se estable en reglas de forma ion del Grafo de Dependen ias a partir dela estru tura de las lases. Las reglas de forma ion onsideran la presen ia derela iones on sustitu ion para expandir las dependen ias. Tambien se denen onsultas que permiten extraer informa ion del repositorio a partir de la es-tru tura de las lases preanalizadas y del Grafo de Dependen ias (e.g. lasesde las que depende una lase, lases que dependen de una lase, origen de unapropiedad, et .).A partir de estas deni iones, en la arquite tura propuesta, la estru tura dela nueva lase que llega al repositorio determina la forma en que se a tualiza elGrafo de Dependen ias.Las herramientas de refa toriza ion a tuan sobre las lases preanalizadas quese en uentran en el repositorio. De los objetos persistentes que representan las lases preanalizadas del repositorio se debe poder extraer el texto equivalente enel lenguaje de partida. De esta forma se obtienen los resultados de la refa tori-za ion. La Figura 2 muestra un esquema de di ha arquite tura.

Page 215: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

208 Y. Crespo, V. Carde~noso, J. M. MarquesCon este enfoque se disminuye la omplejidad de la deni ion de una herra-mienta de refa toriza ion pues esta se entra en elementos que responden a unaestru tura que ontiene solo lo que tiene que onsiderar la herramienta pararefa torizar, apartandole de lidiar on los detalles propios del analisis de unlenguaje parti ular.Como ya hemos di ho, es muy importante analizar si la refa toriza ion ob-tiene elementos orre tos, omo se afe tan las lases que dependen de las lasesmodi adas y omo se afe tan los objetos persistentes que hayan sido readospreviamente a la refa toriza ion. De la misma forma que la deni ion, el analisisse ve simpli ado por el modelo. El Grafo de Dependen ias nos permite analizarlas lases que deben ser transformadas y la forma en que se afe tan las lases quedependen de las transformadas. La orre ion de los nuevos elementos y las on-se uen ias para los objetos se analiza desde la estru tura y las reglas denidasen MOON.5.2 Pro esoEl pro eso que gua la inser ion de MOON en el ambito de las refa toriza ionestiene dos partes fundamentales: deni ion y analisis, e implementa ion, que seresumen a ontinua ion.1. Deni ion y Analisis(a) Poner en orresponden ia el lenguaje objetivo on MOON(b) Denir en MOON la refa toriza ion( ) Analizar sus onse uen ias2. Implementa ion(a) Construir un analizador del lenguaje objetivo que obtiene omo resultadopara ada lase un objeto uya estru tura viene dada por el modelo de lases que se deriva del arbol sinta ti o si se analizaran textos MOON.Estos objetos estan enlazados por un grafo que representa el Grafo deDependen ias del Repositorio.(b) Construir un re uperador de textos en el lenguaje objetivo a partir di hoGrafo. Este paso y el anterior se ondi ionan.( ) Implementar la refa toriza ion denida, a tuando sobre el Grafo de De-penden ias del Repositorio.En este es enario, la inten ion de agregar una nueva refa toriza ion parael mismo lenguaje objetivo impli a trabajar en 1(b), 1( ) y 2( ), mientras queapli ar la misma refa toriza ion para elementos de un nuevo lenguaje impli atrabajar en 1(a), 2(a) y 2(b).6 Un aso de estudioEn esta se ion se presenta un aso de estudio del modelo en dos partes. Enprimer lugar un aso de estudio del modelo omo abstra ion de lenguajes, y

Page 216: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Un lenguaje modelo para la deni ion y analisis de refa toriza iones 209en segundo lugar un aso de estudio del modelo omo base para la deni ion yanalisis de refa toriza iones. Para esto se han elegido el lenguaje Eiffel y unarefa toriza ion denida por nosotros y presentada en [19 y [20.La sele ion de Eiffel viene dada por sus re ursos en uanto a generi idad(in luyendo a ota iones) y de la heren ia que permiten explotar bien el modelo.Ademas, la laridad de la sintaxis, el tratamiento uniforme de las entidades, laausen ia de punteros y el manejo automati o de la memoria, fa ilitan la deni ione implementa ion de los analizadores ne esarios.6.1 Eiffel visto desde MOONEl lenguaje sele ionado (Eiffel) se orresponde on la variante 3) de MOON,teniendo en uenta ademas algunos aspe tos parti ulares omo los tipos an la yexpandidos, su onjunto de instru iones y sus formas de expresiones.Todas las onstru iones se pueden redu ir, a la hora de realizar un analisisestati o de las lases Eiffel, de la misma forma que se presentaron las simpli- a iones de MOON en la Se ion 4. Las instru iones de rea ion, asigna ion, yenvo de mensajes y las formas de expresiones de envo de mensajes y onstantesmaniestas son la base de las demas.Evidentemente, hay que tener en uenta, tal y omo se analizo, en la pre-senta ion de MOON (al no in luir las instru iones if y while) que iertas ins-tru iones exigen un tipo determinado de expresiones, e.g. expresiones de tipoBoolean, omo en la instru ion if, o de tipo Integer, omo en la parte variant deuna instru ion loop de Eiffel. La solu ion que se presento en las simpli a io-nes de MOON: asumir que existe una aso ia ion on una onstante maniestadel tipo requerido, es valida para este aso.Los aspe tos relativos al onjunto de instru iones de Eiffel se vuelven aredu ir a la instru ion de rea ion, la instru ion de asigna ion (el intento deasigna ion ?= en Eiffel se analiza desde MOON omo una asigna ion), y lainstru ion de envo de mensajes. Los envos de mensajes en as ada se simpli- an. En uanto a las formas de expresiones que se orresponden on expresiones on operadores binarios y unarios en Eiffel, se trataran omo expresiones deenvo de mensajes, tal y omo se expuso en Se ion 4. Esto se puede ha er dire -tamente en Eiffel, sin tener que ambiar ninguna onsidera ion, porque todoslos tipos basi os se orresponden on una lase de la bibliote a Kernel.6.2 Desarrollo de una refa toriza ion: parameterizeEn este apartado se presenta una refa toriza ion que hemos denido y deno-minado parametriza ion. El objetivo de esta refa toriza ion es obtener lasesgeneri as a partir de lases que no lo son y transformar el software basado enestas lases para utilizar las nuevas lases generi as y sus instan ia iones.Dada una orden de parametriza ionC.parameterize(e as T)

Page 217: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

210 Y. Crespo, V. Carde~noso, J. M. Marquesdonde C es la lase objetivo, la lase que se quiere ha er generi a; e es la enti-dad gua, la entidad uyo tipo espe o va a pasar a estar dado por el nuevoparametro formal T; la eje u ion de la refa toriza ion pasa por:1. Determinar el grafo que forman las lases que parti iparan en la obten ionde las entidades generi o-dependientes a partir de la entidad gua y las rela- iones entre di has lases. A este grafo se le denomina universo de trabajo yse denota GI .Las entidades generi o-dependientes son aquellas que deben modi ar su ti-po a generi o produ to del ambio del tipo de e. El grafo del universo detrabajo se espe i a muy fa ilmente segun el modelo del Grafo de Depen-den ias estable ido a partir de MOON. Este grafo estara determinado porlos ondi ionantes de C (an estros y proveedores), y por sus des endientes.2. Determinar las entidades generi o-dependientes dire tas e indire tas.Las entidades generi o-dependientes pueden ser dire tas o indire tas, en alu-sion a la forma en que ambia su tipo. El tipo de la entidad e ambia paraser el nuevo parametro generi o formal, algunas entidades (las dire tas) am-biaran de la misma forma, mientras que otras (las indire tas) ambian paraque su tipo pase a ser un tipo generi o instan iado on el nuevo parametro(si su tipo era A ahora sera A[T.La lara espe i a ion de las reglas del sistema de tipos de MOON y laabstra ion en sus onstru iones simpli an en gran medida la deni ionde omo obtener estas entidades y el analisis de la orre ion de su sele ion.Hay que garantizar orre ion de tipos una vez eje utada la transforma ion.Las reglas fundamentales a tener en uenta son las que guan la orre ionde las aso ia iones entre entidades y expresiones. Las reglas 34, 35, 42 y 44son las que determinan, y la ausen ia de envos de mensajes en as ada, as omo la restri ion sobre las expresiones que pueden ser argumentos realesen un envo de mensaje, lari an la deni ion formal y el analisis de laforma ion de los onjuntos de entidades generi o-dependientes.3. Determinar si es posible proseguir on la parametriza ion y on que lases.Con esto se obtiene un subgrafo del grafo GI . Este subgrafo pasa a onstituirel grafo de las lases andidatas a parti ipar en la parametriza ion y se denotaGC .Nuevamente las reglas de tipos y las aso ia iones determinan. Se ha e ne e-sario un analisis exhaustivo de los ambios que pueden o urrir y de las reglasque se deben umplir para determinar que ir unstan ias ondu iran a ob-tener elementos in orre tos, y prohibirlas. Por ejemplo, no se puede obteneruna entidad uyo tipo es un parametro formal aso iada on una onstantemaniesta.4. Si del paso anterior se determina que no se puede proseguir o si no se desea:Terminar5. Eliminar de GC las lases a las que no es ne esario propagar la opera ion(las lases que no ontienen ninguna de las entidades generi o-dependientesdeterminadas).

Page 218: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Un lenguaje modelo para la deni ion y analisis de refa toriza iones 211El grafo resultante se denomina grafo de lases nales y se denota GF . on-sultar si se desea proseguir y on que lases, rearmando GF ada vez que seelimine una lase intera tivamente.Las entidades que tienen que ambiar su tipo determinan las lases que tienenque ser modi adas y las rela iones de dependen ia de estas determinan sila elimina ion de una lase ondu e a la elimina ion de otras.6. Analizar la generi idad a otada.Se analiza la ne esidad de a otar los nuevos parametros formales. Se deter-mina uales deben ser las restri iones. La forma de expresarlas vara dea uerdo a la variante de a ota ion modelada en MOON. La que mejoresresultados da es la variante 2) (a ota ion mediante lausulas tal que).7. Comenzar la parametriza ion a partir de las lases an estros en el grafo deheren ia que subya e en GF hasta las des endientes ( onsiderando el analisisde generi idad a otada).Las estru turas que pueden ser afe tadas son las dadas por las siguientesreglas:regla 3, porque de no haber sido generi a la lase, habra que modi ar la onstru ion que da paso a los parametros formales.regla 7, porque habra que a~nadir el nuevo parametro formal, y en el asode la variante 2), en esta regla se da paso a la onstru ion para a otar elnuevo parametro formal si es ne esario (regla 49W).regla 8, porque en las variantes 1) y 3) es aqu donde hay que dar paso ala onstru ion para a otar el nuevo parametro formal si es ne esario (regla48S).reglas 49W y 50W, en el aso de la variante 2).regla 48S, en las variantes 1) y 3).regla 10, porque hay que veri ar si el padre, tiene omo lase determinanteuna lase que ha sido modi ada por la parametriza ion. En ese aso, el tipodel padre debe modi arse a~nadiendole el parametro real orrespondiente ala sustitu ion.reglas 19 y 22, porque las entidades generi o-dependientes de laradas apartir de estas reglas deben ambiar a variable su tipo.Los ambios en las reglas 48S, 10, 19 y 22 ondi ionan que hay que reformarlas dependen ias expresadas en el Grafo de Dependen ias del Repositorio.Las dependen ias ambian en las siguientes formas: una rela ion puede pasara ser de sustitu ion, puede ambiar la sustitu ion de una rela ion, puedeapare er una nueva rela ion produ to de la in lusion de a ota ion para losnuevos parametros formales en el aso de las variantes 1) y 3)8. Reajustar las lases que no estan en GF y que dependen dire tamente (hijoso lientes dire tos) de las lases parametrizadas para que pasen a dependerde las nuevas lases generi as instan iadas.Esto ultimo indi a que la refa toriza ion parameterize no respeta a los lien-tes (dire tos) de las lases transformadas. El otro aspe to signi ativo a analizarsobre las onse uen ias de la refa toriza ion es su impa to en los objetos per-sistentes. El modelo de objetos basado en on atena ion, la estru tura de los

Page 219: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

212 Y. Crespo, V. Carde~noso, J. M. Marquesobjetos persistentes on el identi ador de su tipo (ausen ia de referen ia a losmetodos), y la gestion del repositorio sobre la identi a ion de los tipos ha eque la transforma ion no tenga onse uen ias para los objetos persistentes.Esta refa toriza ion se implemento en el aso de estudio de Eiffel, siguiendola arquite tura dise~nada (Figura 2). Los uni os aspe tos que hubo que tener en uenta por en ima del modelo de lases preanalizadas segun MOON fueron: notransformar el tipo de una entidad de larada omo tipo an la pues la de lara ion omo an la es mas signi ativa que tener las dos entidades de laradas del mismotipo; y tener en uenta la presen ia de tipos expandidos en el analisis de generi- idad a otada, pues si el resultado de la a ota ion es un tipo expandido, debidoa las reglas de onformidad de tipos, se limitan las posteriores instan ia iones.Se onstruyeron las siguientes herramientas: un preanalizador de lases Eiffel: genera objetos persistentes representandolas lases preanalizadas segun el modelo de MOON un gestor de repositorio que mantiene el Grafo de Dependen ias y permiteextraer informa ion de los objetos que representan las lases preanalizadas. un refa torizador que implementa la opera ion parameterizeCon este aso de estudio hemos omprobado la viabilidad del modelo y de laarquite tura dise~nada para la deni ion y analisis de refa toriza iones. Estamostrabajando a tualmente en una version de Java on generi idad para migrarautomati amente bibliote as de lases no generi as. El modelo y arquite turasMOON esta mostrandose muy efe tivo en la redu ion del esfuerzo de imple-mentar la refa toriza ion para otro lenguaje, lo que era uno de los objetivosfundamentales de la propuesta.7 Con lusionesHemos presentado un lenguaje modelo, MOON, para la deni ion y analisis derefa toriza iones, as omo una arquite tura para su integra ion en herramientasde refa toriza ion. El proposito fundamental es disminuir el esfuerzo de deni iony desarrollo de herramientas para refa torizar elementos de diferentes lenguajes.Se ha realizado un aso de estudio de la viabilidad de este proposito dandoresultados muy positivos.Nuestro trabajo pare e estar en la misma lnea que el ini iado por Ti helaaret al. [8 (Se ion 3). A diferen ia de este ultimo, que dene un modelo de inter- ambio de informa ion mediante un esquema entidad-rela ion y su espe i a ionse basa en CDIF, nosotros denimos un lenguaje modelo dado por una gramati ade atributos y las reglas de tipos del lenguaje, entre otros aspe tos, que ondu ea una representa ion de las lases analizadas segunMOON omo objetos persis-tentes uya estru tura viene dada por el modelo de lases que se deriva del arbolsinta ti o. Derivar de esta estru tura un modelo de inter ambio resulta inmedia-to. Por otra parte, reemos que esta forma de abordar el problema nos estable eun punto de partida inmejorable para abordar la refa toriza ion independientedel lenguaje. En esta sentido, nuestras a tividades apuntan ya a la genera ion

Page 220: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Un lenguaje modelo para la deni ion y analisis de refa toriza iones 213automati a de herramientas de refa toriza ion partiendo de las gramati as y delsistema de tipos de MOON y del lenguaje de programa ion objetivo.Referen ias[1 W.F. Opdyke. Refa toring Obje t-Oriented Frameworks. PhD thesis, Dept. ofComputer S ien e, University of Illinois at Urbana-Champaign, 1992.[2 W.G. Griswold and D. Notkin. Ar hite tural trade os for a meaning preser-ving program restru turing tool. IEEE Transa tions on Software Engineering,21(4):275287, 1995.[3 M. Fowler, K. Be k, J. Brant, W. Opdyke, and D. Roberts. Refa toring: Improvingthe Design of Existing Code. Addison-Wesley, 1999.[4 G. Snelting and F. Tip. Reengineering lass hierar hies using on ept analysis.Pro eedings of the 6th International Symposium on the Foundations of Softwa-re Engineering, ACM SIGSOFT Software Engineering Notes, 23(6):99110, Nov.1998.[5 D. Roberts. Pra ti al Analysis for Refa toring. PhD thesis, University of Illinoisat Urbana-Champaign, 1999.[6 K. Be k. Extreme Programming explained: embra e hange. Addison-Wesley, 1999.[7 Y. Crespo. In remento del poten ial de reutiliza ion del software mediante refa -toriza ion. PhD thesis, Dpto. de Informati a, Universidad de Valladolid, 2000.[8 S. Ti helaar, S. Du asse, S. Demeyer, and O. Nierstrasz. A meta-model forlanguage-independent refa toring. In Pro eedings ISPSE 2000. IEEE, 2000.[9 J.J. Rodrguez, Y. Crespo, and J.M. Marques. Transforma ion de jerarquas deheren ia multiple en jerarquas de heren ia sen illa. Te hni al Report TR-GIRO-03-98, Dpto. de Informati a, Universidad de Valladolid, 1998.[10 M. O Cinneide and P. Nixon. A methodology for the automated introdu tionof design patterns. In Pro eedings of the International Conferen e on SoftwareMaintenan e ICSM'99, 1999.[11 M. van den Brand, P. Klint, and C. Verhoef. Re-engineering needs generi pro-gramming language te hnology. ACM SIGPLAN Noti es, 32(2), Feb. 1997.[12 J. Palsberg and M. S hwartzba h. Obje t-Oriented Type Systems. John Wiley &Sons, 1994.[13 P. Wegner. Dimensions of obje t-based language design. In Pro eedings of OOPS-LA'87, 1987.[14 K.J. Lieberherr, I. Holland, and A. Riel. Obje t-oriented programming: An ob-je tive sense of style. In Conferen e Pro eedings of OOPSLA'88, pages 323334,Sept. 1988.[15 L. Cardelli and P. Wegner. On understanding types, data abstra tion and poly-morphism. Computing Surveys, 17(4):471523, De 1985.[16 K.B. Bru e and P. Wegner. An algebrai model of subtypes in obje t-orientedlanguages. In ACM SIGPLAN Noti es. Obje t-Oriented Programming Workshop.,O t. 1986.[17 B. Liskov and J.M. Wing. Family values: A semanti notion of subtyping. Te h-ni al Report MIT-LCS-TR-562, MIT, De . 1992.[18 A. Taivalsaari. On the notion of inheritan e. ACM Computing Surveys, 28(3):438479, Sept. 1996.[19 Y. Crespo, J.J. Rodrguez, F.J. Gar a, and J.M. Marques. Obten ion automati ade lases generi as a traves de una opera ion de parametriza ion. In A tasJISBD'99, pages 343354, Nov. 1999.

Page 221: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

214 Y. Crespo, V. Carde~noso, J. M. Marques[20 Y. Crespo, J.J. Rodrguez, and J.M. Marques. Obtaining generi lasses automa-ti ally through a parameterization operator. A fo us on onstrained generi ity. InPro eedings of TOOLS 31th, Asia'99. IEEE CS Press, Sept.A Sintaxis on reta de MOON1 MODULE , CLASS DEF2 CLASS DEF , [deferred lass CLASS NAME HEADER SIGNATURES CLASS BODY end3 CLASS NAME , CLASS ID [FORMAL PARAMETERS4 HEADER , INHERITANCE LIST5 SIGNATURES , signatures SIG LIST6 CLASS BODY , body f METHODS IMPL `;' . . . g7 FORMAL PARAMETERS , `[' f FORMAL PAR `,' . . .g+ `' [ BOUND W variante w8 FORMAL PAR , FORMAL GEN ID [ BOUND S variante s9 INHERITANCE LIST , f INHERITANCE CLAUSE `;' . . . g10 INHERITANCE CLAUSE , inherit CLASS TYPE OPLUS hereda11 OPLUS , f MODIFIER `;' . . . g12 MODIFIER , rename PROP ID as PROP ID j redene PROP ID j makedeferred PROP ID jmakeee tive PROP ID j sele t PROP ID13 SIG LIST , ATTRIBUTE DECS METHOD DECS14 ATTRIBUTE DECS , attributes f ATT DEC `;' . . .g15 METHOD DECS , methods f METH DEC `;' . . . g16 ATT DEC , VAR DEC17 METH DEC , ROUTINE DEC j FUNCTION DEC18 ROUTINE DEC , WITHOUT RESULT19 FUNCTION DEC , WITHOUT RESULT `:' TYPE es liente20 WITHOUT RESULT , [deferred METHOD ID [FORMAL ARGUMENTS21 FORMAL ARGUMENTS , `(' f VAR DEC `,' . . . g+ `)'22 VAR DEC , VAR ID `:' TYPE es liente23 TYPE , FORMAL GEN ID j CLASS TYPE24 CLASS TYPE , CLASS ID [REAL PARAMETERS >de que lases?25 REAL PARAMETERS , `[' f TYPE `,' . . . g+ `' >de que lases?26 METHOD IMPL , NONE DEFERRED R j NONE DEFERRED F27 NONE DEFERRED R , MSIG [LOCAL DECS METHOD BODY28 NONE DEFERRED F , MSIG `:' TYPE [LOCAL DECS METHOD BODY29 LOCAL DECS , f VAR DEC `;' . . . g+30 METHOD BODY , do INSTR end31 MSIG , METHOD ID [FORMAL ARGUMENTS32 INSTR , COMPOUND INSTR j CREATION INSTR jASSIGNMENT INSTR j CALL INSTR no hay instru iones de ontrol33 COMPOUND INSTR , fINSTR `;' . . . g ontinua en la pagina siguiente . . .

Page 222: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Un lenguaje modelo para la deni ion y analisis de refa toriza iones 215. . . ontinua ion de la pagina anterior34 CREATION INSTR , reate VAR ID35 ASSIGNMENT INSTR , VAR ID `:=' EXPR36 CALL INSTR , CALL INSTR LONG1 j CALL INSTR LONG2 no hay llamadas en as ada37 CALL INSTR LONG1 , METHOD ID [REAL ARGUMENTS38 CALL INSTR LONG2 , CALL EXPR LONG1`.'CALL INSTR LONG139 EXPR , MANIFEST CONSTANT j CALL EXPR se redu en las formas deexpresiones40 MANIFEST CONSTANT , nil j REAL CONSTANT j INTEGER CONSTANT j BOOLEAN CONSTANT jCHAR CONSTANT j STRING CONSTANT41 CALL EXPR , CALL EXPR LONG1 j CALL EXPR LONG2 no hay llamadas en as ada42 CALL EXPR LONG1 , ENTITY [REAL ARGUMENTS43 CALL EXPR LONG2 , ENTITY`.'CALL EXPR LONG144 REAL ARGUMENTS , `(' fEXPR ATOM `,' . . .g+ `)'45 EXPR ATOM , MANIFEST CONSTANT j CALL EXPR LONG146 ENTITY , VAR ID j result j self47 PROP ID , VAR ID j METHOD IDLos smbolos BOUND S y BOUND W que apare en en las reglas anteriores, dependen deque variante de a ota ion de parametros generi os formales este en onsidera ion. Lasreglas orrespondientes a estos smbolos se denen a ontinua ion de a uerdo a lavariante de lenguaje a la que dara lugar.48S BOUND S , `->'CLASS TYPE es liente48WBOUND S , 49S BOUND W , 49WBOUND W , where f WHERE CLAUSE `,' . . .g+50WWHERE CLAUSE , FORMAL GEN ID has SIG LISTCuando la forma de a ota ion de los parametros generi os formales que se dena parael lenguaje este dada por a ota ion mediante subtipado o onformidad, las reglas quese utilizan son las mar adas on S (reglas 48S y 49S).Cuando la forma de a ota ion de los parametros generi os formales que se denapara el lenguaje este dada por a ota ion mediante lausulas tal que, las reglas que seutilizan son las mar adas on W (reglas 48W, 49W y 50W).

Page 223: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 224: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

El Visitante Genérico Extensible⋆

Francisco Moya, José M. Moya y Juan Carlos López

Universidad de Castilla-La ManchaEscuela Superior de InformáticaE-13071 Ciudad Real, España

fmoya, jmmoya, [email protected]

Resumen En el presente artículo describimos la implementación de unaversión del patrón Visitante [2]. Esta implementación fue diseñada en elcontexto del desarrollo del núcleo de simulación Kepler, con el n de aña-dir soporte de almacenamiento persistente de la mayoría de las estruc-turas de datos empleadas. Frente a un visitante tradicional, el VisitanteGenérico Extensible permite extender una jerarquía cualquiera de ele-mentos concretos visitables sin tener que modicar todos los visitantes,incluso en tiempo de ejecución.

1 Introducción

El patrón Visitante [2] es usado con mucha frecuencia en todas las labores querequieren recorrer estructuras de datos realizando operaciones especícas en cadaelemento de la estructura (e.g. almacenamiento persistente). Las operaciones derecorrido quedan delegadas en la propia estructura de datos mientras que lasoperaciones concretas que hay que realizar se agrupan en una clase visitante.

El patrón visitante consta de dos jerarquías de clases paralelas: las clases con-cretas visitables y las clases visitantes, que realizan operaciones especícas conobjetos de cada clase concreta. En la descripción de Gamma et al., los primerosse caracterizan por tener un método accept que admite como argumento unobjeto visitante e invoca un método de ese objeto visitante. Los objetos visitan-tes tienen una serie de métodos especícos visitXXX para cada clase concreta.Esta técnica suele también llamarse despachado dinámico doble.

El patrón clásico resulta muy conveniente cuando las estructuras de datosestán prejadas en la propia aplicación, pero hoy en día es cada vez más fre-cuente que las aplicaciones puedan extenderse mediante bibliotecas de carga di-námica (plugins) y se tiende a utilizar formatos de almacenamiento igualmenteextensibles, como XML. Estas características impiden el uso del patrón visitantetradicional en C++, puesto que no es posible extender las tablas de despachadodinámico de la clase visitante en tiempo de ejecución.

Nosotros proponemos una implementación del visitante que abstrae la tablade funciones virtuales en forma de un objeto función, que denominamos specia-

lizer. Así mismo se propone una implementación genérica del patrón en forma⋆ Este trabajo ha sido nanciado por el Programa Nacional de I+D+I (CICYT) através del proyecto CORE, TIC2000-0583-C02-01

Page 225: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

218 F. Moya, J. C. Lopezde plantillas de C++. De esta forma puede aplicarse a cualquier estructura sinañadir prácticamente código y evitando replicar código muy monótono.

2 Implementación del visitante

Nuestra implementación comparte con el Extrinsic Visitor [3] y con el IndirectVisitor [5,6] las motivaciones de reducción de acoplamiento entre los objetosparticipantes, pero es considerablemente más simple su implementación y su uso.De forma análoga a los ya citados, la capacidad de poder ampliar un visitanteen tiempo de ejecución obligará a transgredir un principio básico del patrónvisitante [7]:

The Visitor pattern is the classic technique for recovering lost type

information without resorting to dynamic casts.

El Visitante Genérico Extensible necesita recurrir al operador de conversión di-námica de tipos de C++ dynamic_cast para permitir que elementos visitablesconcretos puedan ser incorporados en tiempo de ejecución mediante la carga debibliotecas dinámicas. Por contra, un visitante tradicional debe conocer todoslos elementos visitables concretos presentes en el sistema con antelación. Con elesquema propuesto en este artículo los visitantes preexistentes funcionarán sinproblemas si se extiende el número de elementos concretos, pero sólo los nuevosvisitantes podrán aprovechar la existencia de nuevos elementos concretos.

Frente a losWalkabouts descritos en [4] nuestro Visitante Genérico Extensible

evita las antiestéticas y propensas a errores escaleras de if-else , además depermitir la extensión de los visitantes en tiempo de ejecución.

visitable_base_template+accept(v:visitor_base<abstract_type>&): void

abstract_typevisitor_base_template

+visit(v:acceptor_base<abstract_type>&): void

abstract_type

Default visit methoddoes nothing

visitor* cv = specializer_type(v);if(cv) cv->visit(*this);else v.visit(*this);

visitor_baseabstract

visitable_base

«bind»(abstract)

«bind»(acceptor_base)

visitor_template+visit(v:concrete_type&): void

concrete_type

visitor1

«bind»<concrete1>

concrete1

specializer

visitable1

visitable_template+accept(v:visitor_base<abstract_type>&): void

concrete_typespecializer_type

«bind»(concrete1,specializer)

The trivial specializer is a dynamic_cast adapter

concrete_visitor1a+visit(v:concrete1&): void+visit(v:acceptor_base&): void

visitable2

concrete2

«bind»(concrete2,specializer)

concrete_visitor1b+visit(v:concrete1&): void+visit(v:concrete2&): void

visitor2

«bind»(concrete2)

Concrete visitors mayredefine default visitmethod and must providea specific visit method

Many specialized visit methods arepossible through multiple inheritance

Figura 1. Diagrama de clases UML para el Visitante Genérico Extensible

En la gura 1 se muestra un diagrama de clases UML de nuestra imple-mentación. El usuario debe proporcionar el interfaz común para todas las clasesvisitables relacionadas (llamado abstract en el diagrama). Con este interfaz se

Page 226: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

El Visitante Generi o Extensible 219puede instanciar la plantilla visitable_base para constituir la raiz de la je-rarquía de clases visitables. Esta plantilla simplemente añade el método virtualaccept y servirá como clase base para todos los visitantes de la jerarquía:

template <class T>class visitable_base : public T

typedef visitable_base <T> _Self ;public :

visitable_base ( ) virtual ~visitable_base ( )

public :struct visitor_base

typedef _Self base_type ;virtual void visit (_Self & vb )

;virtual void accept (visitor_base & v ) = 0 ;

;

Como puede apreciarse, el método visit tiene una implementación vacíaen lugar de ser un método abstracto, como en el caso del visitante tradicional.La intención es similar a la del Default Visitor descrito en [3]. Este métodose invocará en caso de no disponer de un método visit especíco para unadeterminada clase visitable concreta.

Para cada clase visitable concreta denimos una clase visitante diferente, quesimplemente añade un método sobrecargado visit especializado. Este métodoes equivalente a los métodos visitXXX en el patrón visitante tradicional:

template <class T>struct visitor : public virtual T : : visitor_base

typedef T base_type ;virtual void visit (T& cc ) const = 0;

;

El parámetro de plantilla T se asume que deriva de una instancia de la clasevisitable_base denida anteriormente (raiz de la jerarquía de visitables). Elcaso normal, en el que se requiere que un mismo visitante pueda visitar múltiplestipos concretos, se puede implementar bien utilizando herencia múltiple, o bienutilizando un adaptador [2] que realice una búsqueda más sosticada del visitanteconcreto. Ambos casos serán analizados a continuación.

El caso más simple, en el que se utiliza herencia múltiple para crear una clasevisitante, justica el uso de herencia virtual al derivar de visitable_base .

En cualquiera de las dos posibilidades mencionadas se necesita un mecanis-mo para obtener un visitante especializado a partir de la referencia al visitantebase que se pasa al método accept . Esta traducción se lleva a cabo medianteun specializer. En el caso más simple, visitantes compuestos mediante herenciamúltiple, la especialización corresponde a un simple dynamic_cast :

template <class T>class trivial_specializer

typedef visitor <T> visitor_type ;

Page 227: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

220 F. Moya, J. C. Lopezpublic :

operator visitor_type ∗ ( ) return _q ; template <class Q> trivial_specializer (Q& t )

: _q (dynamic_cast <visitor_type ∗>(&t ) )private :

visitor_type ∗ _q ; ;

En este caso se trata de un simple envoltorio de dynamic_cast . En otroscasos el objeto función encargado de la especialización puede permitir la cargadinámica de módulos y consultas a una base de datos.

El caso más simple está prácticamente completo. Tan solo falta denir unmétodo accept adecuado para cada una de las clases visitables. La implemen-tación es idéntica en todos los casos, se trata de una invocación al método visitespecializado. Por tanto es un candidato ideal para ser implementado como unaplantilla de C++:

template <class T , class specializer = trivial_specializer <T> >class visitable : public T

typedef visitable <T> _Self ;public :

typedef typename T : : visitor_base visitor_base ;typedef visitor <T> visitor_type ;

public :void accept (visitor_base & v )

visitor_type ∗ cv = specializer (v ) ;if ( cv ) cv−>visit (∗ this ) ;else v . visit (∗ this ) ;

;

Como en el caso del Default Visitor propuesto en [3], si el visitante no puedeser especializado para una clase concreta invoca el método visit no especializa-do, denido en la base de la jerarquía de visitantes. Este método no especializadotambién puede redenirse si se desea (la plantilla visitable_base lo denecon una implementación nula).

3 Ejemplo de uso

Un pequeño ejemplo de uso puede servir para claricar nuestra implementación:

#include "visitor . hh"#include <iostream >

class Root ;typedef visitable_base <Root > VisitableRoot ;

struct A_base : public VisitableRoot void sayHello ( ) cout << "Hello from A" << endl ;

Page 228: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

El Visitante Generi o Extensible 221 ;

struct B_base : public VisitableRoot void sayGoodbye ( ) cout << "Goodbye from B" << endl ;

;

typedef visitable <A_base > A ;typedef visitable <B_base > B ;

struct Visitor : public A : : visitor_type , public B : : visitor_type void visit (A_base & a ) const a . sayHello ( ) ; void visit (B_base & b ) const b . sayGoodbye ( ) ;

;

int main ( )

A a ; B b ; Visitor v ;a . accept (v ) ; b . accept (v ) ;return 0 ;

El código de este ejemplo no es signicativamente más complejo que la im-plementación de un visitante tradicional, pero tampoco explota las capacidadesde extensión que ofrece el Visitante Genérico Extensible. La siguiente seccióndescribe cómo extender un visitante de este tipo.

3.1 Visitantes extensibles

Para jerarquías de objetos basadas en prototipos resulta muy conveniente dispo-ner de un visitante que se pueda extender durante la ejecución de la aplicación.En ese caso el visitante contendrá un conjunto de visitantes especícos, quepodrían haberse añadido en tiempo de compilación o de ejecución:

class visitor_dynamic : public visitor_base typedef const type_info key_type ;typedef map<key_type ∗ , visitor_base ∗> container_type ;

public :void append_visitor (const key_type & k , visitor_base & v )

_known [&k ]= &v ;void remove_visitor (const key_type & k , visitor_base & v )

_known . erase (&k ) ;visitor_base ∗ lookup (const key_type & k )

return _known [&k ] ;

private :container_type _known ;

;

Page 229: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

222 F. Moya, J. C. LopezTodas las clases visitantes especícas deben derivarse de visitor_base y

el visitante que las contiene debe ser una instancia de visitor_dynamic .En este caso el objeto función encargado de especializar al visitante deberá

consultar la tabla de clases concretas visitables conocidas (_known ) utilizan-do el soporte de información de tipos en tiempo de ejecución de C++. Estoobliga a una invocación adicional de dynamic_cast con respecto al caso deltrivial_specializer .

template <class T>class dynamic_specializer

typedef visitor <T> visitor_type ;typedef typename T : : visitor_dynamic visitor_dynamic ;

public :operator visitor_type ∗ ( ) return _q ; template <class Q>dynamic_specializer (Q& t ) : _q (dynamic_cast <visitor_type ∗>(&t ) )

if ( ! _q ) visitor_dynamic ∗ v = dynamic_cast <visitor_dynamic ∗>(&t ) ;if ( v )

_q = dynamic_cast <visitor_type ∗>(v−>lookup (typeid (visitor_type ( ) ) ) ) ;

private :visitor_type ∗ _q ;

;

Nótese que dynamic_specializer también funciona con visitantes nor-males (no dinámicos) con una pequeña penalización en tiempo de ejecución.

3.2 Cuellos de botella

La generalidad y exibilidad de nuestra implementación de visitantes implicauna serie de ineciencias respecto al visitante tradicional:

1. La necesidad de usar dynamic_cast para no requerir un conocimientoprevio de toda la jerarquía de clases concretas visitables. Esto es causa deuna penalización relativamente importante en muchos compiladores. En lagura 2 se muestra una gráca de la sobrecarga introducida por el uso dedynamic_cast en lugar de una simple llamada a un método virtual utili-zando diversos compiladores. En la gura se comparan dos versiones recientesdel compilador de GNU. Como puede apreciarse, el impacto puede ser muydiferentes dependiendo del compilador utilizado.

2. La necesidad de usar herencia virtual desde la clase raiz de la jerarquía devisitantes, para evitar ambigüedades al denir un visitante para múltiplesclases concretas. Esto añade un nivel de indirección adicional, aunque elimpacto global puede ser despreciado en la mayoría de las situaciones (verg. 3).

Page 230: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

El Visitante Generi o Extensible 223

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

0 200000 400000 600000 800000 1e+06 1.2e+06 1.4e+06

Tie

mpo

de

ejec

ucio

n (s

egun

dos)

Numero de iteraciones

Sobrecarga de dynamic_cast frente a despachado dinamico

virtual method, gcc 2.95.4 virtual method, gcc 3.0 dynamic_cast, gcc 2.95.4 dynamic_cast, gcc 3.0

Figura 2. Representación gráca de la sobrecarga debida al uso de dynamic_cast .

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0 200000 400000 600000 800000 1e+06 1.2e+06 1.4e+06

Tie

mpo

de

ejec

ucio

n (s

egun

dos)

Numero de iteraciones

Sobrecarga de la herencia virtual

virtual inheritance, gcc 2.95.4 virtual inheritance, gcc 3.0 non-virtual inheritance, gcc 2.95.4 non-virtual inheritance, gcc 3.0

Figura 3. Representación gráca de la sobrecarga debida a la herencia virtual.

Page 231: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

224 F. Moya, J. C. Lopez3. La necesidad de tres niveles de herencia. Esto no es causa de degradación de

prestaciones, pero un número excesivo de niveles de herencia es un síntoma deun diseño pobre. En nuestro caso los dos niveles de herencia adicionales conrespecto al visitante tradicional son debidos a extensiones comunes aplicadasmediante plantillas C++ a clases provistas por el usuario. Realmente estasextensiones no introducen acoplamiento innecesario, puesto que las plantillasC++ de nuestro patrón visitante se suponen estables.

Además de las ineciencias mencionadas es frecuente encontrar rechazo a laherencia múltiple. En ese caso el usuario puede simplemente proporcionar unobjeto función de especialización, diferente del trivial_specializer , queretorne un nuevo visitante especializado en lugar de convertir explícitamente eltipo del visitante utilizado en la llamada a accept .

4 Conclusiones

Nuestra implementación ofrece un compromiso entre generalidad y prestaciones.Mantiene la integridad de tipos característica de C++ y permite detectar la ma-yoría de los errores en tiempo de compilación. Por otro lado logra un alto gradode desacoplamiento entre los integrantes de la jerarquía de clases concretas visi-tables y clases concretas visitantes. Frente a otras versiones del patrón visitante,el Visitante Genérico Extensible añade:

Desacoplamiento de visitantes y visitables hasta un nivel similar al ExtrinsicVisitor [3].

Implementación genérica utilizando plantillas de C++ para evitar la repli-cación de código.

Capacidad de extensión en tiempo de ejecución o de compilación.

A pesar de todo, para algunas aplicaciones es muy importante evitar la pér-dida de rendimiento debida al uso de dynamic_cast . En esos casos C++ nopuede proporcionar un método para automatizar la declaración y manejo delpatrón visitante, pero podría implementarse utilizando herramientas de prepro-cesado como OpenC++ [1] que añaden propiedades reexivas a C++.

Referencias

1. Shigeru Chiba. OpenC++ 2.5 Reference Manual. Institute of Infor-mation Science and Electronics. University of Tsukuba, available online inhttp://www.softlab.is.tsukuba.ac.jp/˜chiba , 1999.

2. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns:Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.

3. Martin E. Nordberg. Variations on the Visitor Pattern. Tech-nical report, Quintessoft Engineering, Inc, available online inhttp://siesta.cs.wustl.edu/˜schmidt/PLoP-96/nordberg.ps.gz ,July 1996.

Page 232: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

El Visitante Generi o Extensible 2254. Jens Palsberg and C. Barry Jay. The essence of the visitor pattern. In

Proceedings of COMPSAC'98, 22nd Annual International Computer Softwareand Applications Conference, pages 915, available online in http://www-staff.mcs.uts.edu.au/˜cbj/Publications/visitor.ps.gz , Vienna,Austria, August 1998.

5. Jack Reeves. Yet another visitor pattern. The C++ Report, March 1998.6. Jack Reeves. Yet another visitor pattern, part ii. The C++ Report, May 1998.7. John Vlissides. Type Laundering. The C++ Report, February 1997.

Page 233: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 234: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Generic Description, Behavior and Animation of VisualModeling Languages

Hartmut Ehrig, R. Bardohl, and C. Ermel

FB 13 Informatik, Tech. Univ. Berlin, Franklinstrasse 28/29, 10587 Berlin, Germany.

Visual modeling techniques including UML as well as graph and net basedtechniques are of growing interest for software system specification and de-velopment. The GENGED approach developed at the Technical University ofBerlin allows already the generic description of visual modeling laguages basedon formal graph transformation and graphical constraint solving techniques andtools.

In this paper, the GENGED approach is reviewed and extended in order toallow the description of dynamic behavior and animation of systems. The basicidea is to define visual behavior and animation rules on top ofthe rules defin-ing the corresponding visual modeling laguage and to allow adomain specificlayout for the animation view of the system. A simple versionof a traffic lightsystem is used as running example, where the system view is given by a Petrinet. The animation view shows directly the dynamic changes of the colors oftraffic lights at a street crossing.

Page 235: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 236: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Modelling Implementations as Institution

Morphisms⋆

C. Domınguez, L. Lamban, M. V. Pascual and J. Rubio

Departamento de Matematicas y Computacion, Universidad de La Rioja.

Edificio Vives, Luis de Ulloa s/n, E-26004 Logrono (La Rioja, Spain).

cedomin,lalamban,mvico,[email protected]

Abstract. In this paper, the role of coalgebras for specifying a concrete

software system is explained. We show how, from this particular goal, a

generic construction of institutions for coalgebras (on certain constant

functors) has been obtained. This also reveals a new application field in

which the two concepts algebra/coalgebra (and the initial/final matters)

are fruitfully confronted.

Keywords. Institution, algebraic specification, coalgebra, symbolic com-

putation

1 Introduction and Motivation

When an analyst undertakes the task of specifying a symbolic computation sys-tem in Algebraic Topology he finds a challenging context. This was the casewhen we started the study of the data structures in the EAT (Effective Alge-braic Topology) system [17, 16]. In such a system two layers of data structuresexist. In the first layer, one finds the usual data structures as (finite) lists ortrees of symbols or integer numbers (for representing linear combinations, poly-nomials and so on). In the second layer, one must deal with algebraic structuresas (graded) groups or rings in which the elements are data belonging to thefirst layer. Besides, two additional features of these layers enrich even more theproblem. On the one hand, structures of the two layers have to be created andhandled at runtime. This should be compared with other mathematical packages(in the field of Commutative Algebra or in general systems such as Mathemat-ica or Maple) in which the two above mentioned layers obviously exist, but inwhich only one (or very few) algebraic structure is created in each session (in apre-processing time, one can say) and then a massive work on usual (first layer)data is carried out inside this structure. In contrast, in a typical calculation withEAT, several hundred algebraic structures must be created and handled throughseveral hours of CPU time (see examples in [17, 16]).

On the other hand, the interesting algorithms in Algebraic Topology use, inan essential way, infinite structures as intermediaries for computing the sought

⋆ Partially supported by DGES, project PB98-1621-C02-01 and by Universidad de La

Rioja, project API-00/B28

Page 237: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

230 C. Domnguez, L. Lamban, V. Pas ual, J.Rubio(finite) results. (The loop space construction is the more important of this kind[16].) Let us stress that these infinite data structures are not the usual sequentialor hierarchical structures, as infinite lists or streams or infinite trees, in whichcanonical ways of traversing the structure are known. In EAT, one must im-plement infinite groups, rings and so on, in which the aspects of behavior andobservation are more important than the storing and traversing aspects.

These particular characteristics imply that, even if for the first-layer datastructures the usual algebraic specification techniques (and the initial algebraconstruction, in particular) are enough for the modelling task, for the second-layer data structures, a research effort is required, since the direct applicationof known techniques is not possible.

Our first remark was that in a system such as EAT we are not only im-plementing an Abstract Data Type, or ADT (as a group, for instance), butalso dealing, at runtime, with implementations (in the example, several hun-dred implementations of the ADT group would populate the program memory).Working with the classical notion of ADT implementation due to Hoare [8] anddealing with the semantic subtleties of the programming language in which EATwas developed (Common Lisp), we were able in [11] of proving that the EAT(second-layer) data structures were as general as possible, in the sense that theyare ingredients of final objects in certain categories of ADT implementations.Later on, directed by this finality property found, we reinterpreted in [4, 12] ourresults related to hidden and coalgebraic technology in a purely (co)algebraicsetting (without considering implementation or programming language issues).In this paper, we continue this line and we introduce some constructions in theinstitutional framework with the aim of illustrating that our previous resultsgive some generic insights on the field of (co)algebraic specifications.

After this motivating introduction, the paper is organized as follows. Section2 is devoted to collect some well known definitions and facts on (co)algebraicspecification. In Section 3, a general procedure to obtain an institution for coal-gebras from another institution is introduced. Then, Section 4 particularizes thisgeneral construction to the case in which the source institution is one of the well-known algebraic institutions with certain constraints on the carrier sets. In thissame section, the interpretation of this institution as for hidden specificationsand implementation matters is briefly considered too. The paper ends with asection of conclusions and future work.

2 Preliminaries

In order to ease the reading of the paper, we start recalling some well-knowndefinitions presented as in [13].

Definition 1 (Signature and Algebra). A signature Σ is a pair (S, Ω) ofsets, whose elements are called sorts and operations respectively. Each operationconsist of a (k + 2)-tuple, ω : s1 . . . sk → s with s1, . . . , sk, s ∈ S and k ≥ 0.In the case k = 0, the operation is called a constant of sort s.

Page 238: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Modelling implementations as institution morphisms 231Let Σ = (S, Ω) and Σ′ = (S′, Ω′) be two signatures. A signature morphism

µ : Σ → Σ′ from Σ to Σ′ is a pair µ = (µS : S → S′, µΩ : Ω → Ω′) of functionssuch that for each operation n : s1 . . . sk → s ∈ Ω, k ≥ 0, there exists anoperation m, with µΩ(n : s1 . . . sk → s) = (m : µS(s1) . . . µS(sk) → µS(s)).

Let Σ = (S, Ω) be a signature. A total algebra for Σ (or Σ-algebra) assignsa set A(s) to each sort s ∈ S, called the carrier set of the sort s, and a totalfunction A(ω : s1 . . . sk → s) : A(s1) × . . . × A(sk) → A(s) to each operationω ∈ Ω.

The Σ-algebras can be organized as a category Alg(Σ) using the followingnatural notion of morphism. Let A, B be two Σ-algebras, Σ = (S, Ω). A Σ-homomorphism h : A → B from A to B is a family hs : A(s) → B(s)s∈S offunctions such that

hs(A(ω)(a1, . . . , ak)) = B(ω)(hs1(a1), . . . , hsk

(ak))

for ω : s1 . . . sk → s ∈ Ω and for all ai ∈ A(si), i = 1, . . . , k.

Next, we introduce the notion of coalgebra (which first appeared in the fieldof algebraic specification in [14] and which has been developed in [18, 9, 10],among other papers).

Definition 2 (Coalgebra). Let F : Set → Set be an endofunctor of Set, thecategory of sets. Then a F -coalgebra is a couple (A, cA), where A is a set andcA : A → F (A) is a map. A morphism between F-coalgebras (A, cA), (B, cB) isa map f : A → B such that F (f)cA = cBf .

The F -coalgebras, together with the morphisms between them, define a cate-gory which is denoted by CoAlg(F ).

The following definitions of institution and institution morphism have beenextracted from [6].

Definition 3 (Institution). An institution I consists of

1. a category Sign, whose objects are called signatures,2. a functor Sen : Sign → Set, giving for each signature a set whose elements

are called sentences over that signature,3. a functor Mod : Sign → Catop giving for each signature Σ a cate-

gory whose objects are called Σ-models, and whose arrows are called Σ-(model)morphisms, and

4. a relation |=Σ⊆ Obj(Mod(Σ)) × Sen(Σ) for each Σ ∈ Obj(Sign), calledΣ-satisfaction,

such that for each morphism φ : Σ → Σ′ in Sign, the Satisfaction Condition

m′ |=Σ′ Sen(φ)(e) iff Mod(φ)(m′) |=Σ e

holds for each m′ ∈ Obj(Mod(Σ′)) and each e ∈ Sen(Σ).

Page 239: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

232 C. Domnguez, L. Lamban, V. Pas ual, J.RubioDefinition 4 (Institution morphism). Let I and I ′ be institutions. Then,an institution morphism Φ : I → I′ consists of

1. a functor Φ : Sign → Sign′,2. a natural transformation α : Φ; Sen′ ⇒ Sen, and3. a natural transformation β : Mod ⇒ Φ;Mod′

such that the following Satisfaction Condition holds

m |=Σ αΣ(e′) iff βΣ(m) |=′

Φ(Σ) e′

for any Σ-model m from I and any Φ(Σ)-sentence e′ from I ′.

As usual, the first example of institution is the one obtained from the equa-tional algebraic specification [13]:

Example 1 (Equational algebraic institution). We can organize the equationalalgebraic specifications as an institution considering

– the category Sign as the category with objects the signatures Σ and mor-phisms the signature morphisms,

– the functor Sen : Sign → Set, giving for each signature Σ the set of sen-tences EL(Σ), that is to say, pairs of Σ-terms,

– the functor Mod : Sign → Catop, giving for each signature Σ the categoryAlg(Σ),

and considering as Σ-satisfaction the usual equational satisfaction definitionobtained from the interpretation of a Σ-term in a Σ-algebra.

To finish this preliminary section, we define the notion of hidden algebrawhich will be used in Section 4.

Definition 5 (Hidden algebra). Let V Σ = (V S, V Ω) be a signature. Let usfix a V Σ-algebra D and let us include in V Ω, as constants, the elements ofthe carrier sets of D which do not correspond to constants previously in V Ω.The elements of V S are called visible sorts and those of V Ω are called visibleoperations. The V Σ-algebra D is called data domain. Then a hidden signature,on V Σ and D, is a signature HΣ = (S, Ω) such that:

– S = HS ⊔ V S; the elements of HS are called hidden sorts of HΣ.– Ω = HΩ ⊔ V Ω and for each operation ω : s1 . . . sn → s in HΩ the following

property hold: in s1, . . . , sn there is one and only one hidden sort and it isassumed that this hidden sort appears in the first position (that is, it is s1).

(This definition only covers a particular case of the notion introduced in [7],but it is enough for our purposes in this paper.)

A hidden algebra A for a hidden signature HΣ, on V Σ and D, is a HΣ-algebra such that AV Σ = D (in other words, the restriction of A to the visiblepart is equal to the data domain D). A hidden morphism between two hiddenalgebras is a HΣ-homomorphism f such that fD is the identity on D.

The hidden algebras for HΣ on V Σ and D, together with the hidden mor-phisms, define a category HAlgD(HΣ).

Hidden specifications can be organized as an institution (see, for instance,[2]) but this fact will not be used in this paper.

Page 240: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Modelling implementations as institution morphisms 2333 Coalgebric Institution Associated to an Institution

3.1 Definition of Institutions for Coalgebras

The starting point is an institution I, with the property that for eachΣ ∈ Obj(Sign

I), ModI(Σ) is a small category, that is to say, the class

Obj(ModI(Σ)) is a set. This condition could seem very restrictive, but in fact,it is not. For instance, if we are specifying a software system by means of an alge-braic institution, it is quite natural to impose that any Σ-algebra has carrier setswhich are subsets of a fixed data universe, namely the set of all objects definablein a particular programming language. Then the corresponding institution hasthe aforementioned property.

From such an institution I, a coalgebraic institution CoAlg(I) is introduced.Let us stress that these institutions do not cover general coalgebras: only coal-gebras on (particular) constant functors are considered, but this poor class ofcoalgebras is enough for our modelling purposes. The detailed construction isgiven in the following definition.

Definition 6 (Coalgebric institution associated to an institution).Let I = (Sign

I, SenI ,ModI , |=I) be an institution so that for each Σ ∈

Obj(SignI), ModI(Σ) is a small category. We define the coalgebric institu-

tion associated to I, denoted by CoAlg(I) as follows:

1. The category SignCoAlg(I) is the category with

– objects: for each Σ ∈ Obj(SignI) we include as object of SignCoAlg(I)

the endofunctor FΣ : Set → Set which is constant on the setObj(ModI(Σ)),

– morphisms: for each µ : Σ → Σ′ ∈ Morph(SignI), we include as mor-

phism between FΣ and FΣ′ in SignCoAlg(I) the natural transformationFΣ′ ⇒µ FΣ between FΣ′ and FΣ defined in the natural way through thesignature morphism µ1.

2. The functor SenCoAlg(I) : SignCoAlg(I) → Set is defined bySenCoAlg(I)(FΣ) = SenI(Σ) for each endofunctor FΣ with Σ ∈Obj(Sign

I). For a morphism FΣ′ ⇒µ FΣ, between the endofunctors FΣ

and FΣ′ , the functor is defined in the natural way through the signaturemorphism µ.

3. The functor ModCoAlg(I) : SignCoAlg(I) → Catop is defined byModCoAlg(I)(FΣ) = CoAlg(FΣ) for each endofunctor FΣ with Σ ∈Obj(Sign

I). For a morphism FΣ′ ⇒µ FΣ, between the endofunctors FΣ

and FΣ′ , the functor is defined in the natural way through the natural trans-formation.

4. The satisfaction condition |=CoAlg(I)FΣ

⊆ Obj(ModCoAlg(I)(FΣ)) ×SenCoAlg(I)(FΣ) with FΣ ∈ Obj(SignCoAlg(I)) is defined as

1 The contravariant flavour of the definition is introduced in order to maintain the

variancy which is usual when dealing with institutions (that is to say, the target of

Sen is Set and that of Mod is Catop).

Page 241: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

234 C. Domnguez, L. Lamban, V. Pas ual, J.RubioA |=

CoAlg(I)FΣ

e iff α(x) |=I

Σ e, ∀x ∈ X, where A = (X, α : X →FΣ(X)) ∈ Obj(ModCoAlg(I)(FΣ)) and e ∈ SenCoAlg(I)(FΣ).

3.2 Institution Morphism between an Institution I and itsCoalgebraic Institution CoAlg(I)

It is intuitively clear from the construction above that the institution I can bemapped in CoAlg(I). Nevertheless, to achieve this mapping it is necessary toimpose a new condition on I: each morphism in ModI(Σ) must be an endo-morphism. We will see in Section 4 that this condition is naturally held in ourcontext (and, in fact, in the context of hidden specifications, too).

Thus, let I = (SignI, SenI,ModI , |=I) be an institution such that for each

Σ ∈ Obj(SignI), ModI(Σ) is a small category in which a morphism is always

an endomorphism. We define the following mappings.

1. A functor ΦI : SignI→ SignCoAlg(I) is defined as:

– for each Σ ∈ Obj(SignI), ΦI(Σ) = FΣ , the constant endofunctor on

Obj(ModI(Σ)).– for each µ : Σ → Σ′ ∈ Morph(Sign

I), ΦI(µ) = FΣ′ ⇒µ FΣ is the

natural transformation between the corresponding endofunctors FΣ′ andFΣ (recall that this is a SignCoAlg(I)-morphism from FΣ to FΣ′).

2. A natural transformation αI : ΦI ; SenCoAlg(I) ⇒ SenI, is defined as afamily of applications αIΣ

: SenCoAlg(I)(ΦI(Σ)) → SenI(Σ), where αIΣis

the identity for each Σ ∈ Obj(SignI).

3. A natural transformation βI : ModI ⇒ ΦI ;ModCoAlg(I) is defined by afamily of functors βIΣ

: ModI(Σ) → ModCoAlg(I)(ΦI(Σ)), one for eachΣ ∈ Obj(Sign

I) such that βIΣ

(A) = (∗, αA : ∗ → ΦI(Σ)(∗)) whereαA is defined by αA(∗) = A, i.e. the coalgebra defined by a singleton as setand the map applying the unique element to A, for each A ∈ ModI(Σ).

It is straightforward to check that these mappings define an institution mor-phism, and then we obtain the following result.

Theorem 1. Let I be an institution so that for each Σ ∈ Obj(SignI),

ModI(Σ) is a small category and each morphism in ModI(Σ) is an endo-morphism. Then, there exists a canonical institution morphism between I andCoAlg(I).

4 Coalgebric Institution Associated to an Algebraic

Institution

4.1 Equational Algebraic Institution Defined over a Data Universe

We particularize the constructions of the previous section by considering assource institutions a special kind of equational algebraic institutions. Let usremark that the adjective “equational” could be removed and, in fact, our ar-guments easily extend to any kind of algebraic institution (with conditional or

Page 242: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Modelling implementations as institution morphisms 235first order axioms, for instance). We have preferred to explain our ideas in themore precise and comfortable setting of equational algebraic specifications.

First of all, a set U (the universe of sorts) is fixed. Then, for each s ∈ U a(non-empty) set Ds is also fixed. The family D = Dss∈U is called data universeand, if no confusion can arise, we will not explicitly refer to the universe of sortsU .

Definition 7 (Algebraic institution defined over a data universe).The equational algebraic institution defined over a data universe D, ID =

(SignID , SenID ,Mo dID , |=I

D

) is defined as the equational algebraic institu-tion evoked in the Example 1, except for the following modifications. The objectsin Sign

ID are signatures Σ = (S, Ω∪C), where S ⊆ U , Ω is a set of operationswithout constants and C = d :→ s | for each d ∈ Ds, for each s ∈ S is a setof constants. The morphisms in Sign

ID are morphisms between signatures suchthat the constants in C are invariant. For each Σ = (S, Ω ∪C) ∈ Obj(Sign

ID),ModID (Σ) is the category whose objects are Σ-algebras A such that A(s) = Ds

for each s ∈ S and A(d) = d for each d ∈ C, and the only morphisms onModID (Σ) are the identities.

Thus, in the institutions ID, the two conditions on the size and the mor-phisms in the categories of models are satisfied and we conclude the existence ofa canonical institution morphism between ID and the corresponding coalgebraicinstitution CoAlg(ID). Anyone who knows something about hidden specifica-tions will observe a parallelism between our constructions and terminology andthe hidden techniques. But, before making even more explicit this relationship,we want to give an interpretation with respect to our initial modelling problem.

4.2 Coalgebraic Institutions and ADT Implementations

Let us come back to the ideas presented in the introduction. It is quite obviousthat the data universe D is related with the first-layer of data structures in EAT.In fact, even if in the previous subsection the data universe was fixed once andas a whole, the practical way of working is defining each Ds as the initial modelfor a previous signature (usually based on the built-in Common Lisp operationsfor managing list, arrays and so on). In this context, it is not necessary tointroduce in each signature the complete set of constants C, condition which isquite unrealistic in most cases (see [5] and [15] for details on this constructingprocess).

It is clear that the second-layer data structures in EAT should be related tothe models of the institution ID. Nevertheless, it is also clear that each modelrepresents one algebraic structure (one group, for example), but in EAT we mustdeal not only with one group but with families of groups (which will be createdat runtime) and, besides, we must model the implementations (that is to say,the computer-memory counter-part of Σ-algebras) of such models. Then, theconclusion is that second layer EAT data structures are implementations of themodels in ID and therefore that algebraic institutions such as ID are too poorto formally specify the features of the EAT system.

Page 243: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

236 C. Domnguez, L. Lamban, V. Pas ual, J.RubioIn [11], we rely on Hoare’s notion of ADT implementation [8] in order to

model these data structures and then we are obliged to deal with invariant,equality, partiality and Common Lisp semantics matters. If all these technicali-ties are skipped and we place ourselves in the simpler setting of pure algebraicspecifications (even if doing so, we move away from our main goal: modellingthe actual features of the EAT system), we realize that our second layer datastructures are implementing nothing but families of Σ-algebras. That is to say,we move from a category of models in ID to an indexed (or fibered) category onit (see [20]). Or, from another point of view, we can identify each second layerEAT data structure with a coalgebra recovering the corresponding Σ-algebras.This is exactly what was formally expressed in the previous section in the trans-fer from ID to CoAlg(ID). Let us note that the idea of seeing a coalgebra asan implementation is not really fullfiled by the institution morphism. This istrue from the syntactic point of view (that is to say, the functors in the imageof the morphism can be accurately interpreted as the signatures for the imple-mentations of Σ-algebras) but from the semantic point of view, the models inthe image of the morphism represent almost trivial implementations (concretely,they are implementations of a unique datum). However, we will see in Subsection4.4 how these images can be gathered (as coproducts) to produce final objectswhich directly correspond to the data structures in EAT. But before stating thisresult, the relationship with hidden specifications is presented.

4.3 The Hidden Specification Point of View

Let Σ = (S, Ω) be a signature in ID, and let us suppose that Ω = (ω1, . . . , ωm)is an enumeration of the operation symbols (here we are not considering the con-stants C, for the reasons explained in the previous subsection). A new signatureΣImp = (SImp, ΩImp) is defined as follows:

– SImp = imp Σ∪S where imp Σ is a fresh symbol (that is to say, a symbolwhich does not belong to the universe of sorts U of ID),

– ΩImp = (imp ω1, . . . , imp ωm) in which for each operation ω : s1 . . . sn →s ∈ Ω, an operation imp ω : imp Σ s1 . . . sn → s ∈ ΩImp is included.

This signature can be considered a hidden signature [7] by declaring imp Σ

as a unique hidden sort. Then, the ΣImp-hidden algebras can be interpreted asfamilies of Σ-algebras and the relation with EAT data structures becomes clear.

The category of hidden algebras HAlgD(ΣImp) is canonically equivalent tothe category of coalgebras ModCoAlg(ID)(ΦID(Σ)) (as it can be deduced, forinstance, from [3]), showing that, as it is widely considered, the two formalism areroughly equivalent in expressiveness. In addition, it is not difficult to check thatnot only signatures and models, but also sentences and satisfacibility, are well-transferred through hidden logics. In other words, the mappings of Subsection3.2 factorize through a hidden institution [2], completing the picture of ourapproach2.2 But, please note that we are not claiming that our institution morphism can be

expressed as the composition of two institution morphisms.

Page 244: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Modelling implementations as institution morphisms 2374.4 Final Objects

The existence of a final object in the category ModCoAlg(ID)(FΣ) can be reachedfrom a good number of sources: from the indexed or fibered category theory [20],from general results on coalgebras [1], from the coalgebraic specification area[14], from the hidden approach [7], or in our very particular case, simply by anelementary category theory argument, because that category is nothing but acategory of sets over a fixed set (slice category).

This final object can be described as the identity map 1lD

:Obj(ModID(Σ)) → Obj(ModID(Σ)). Interestingly enough, to take advantageof such an inoffensive theoretical object it was necessary to use all the power ofCommon Lisp as a functional programming language [11]. This simple objectcan be also understood as the cause of the “universal” and very general scope ofEAT and, in particular, of its capability for dealing with infinite data structures(this is not surprising because it is well-know that coalgebras have always beenproposed for the specification of infinite data structures; see [18] for instance).

In EAT [16], the final object is encoded by means of a record of CommonLisp functions (lexical closures [19]) with a field for each operation in Σ. Notethat the elements of each algebraic structure (which is represented by an in-stance of the record) are chosen among the data D which is fixed in advance,or constructed from initial semantics, and so they do not require an explicitstoring. If we consider that each particular implementation (i.e., each particularinstance of the record) is “summed” in the record structure, we obtain a prac-tical interpretation of the following result, which shows that the models in theimage of the institution morphism enable the re-construction of the final objects(as in the case of the existence of final objects, the proof of this theorem can beinterpreted as a particular case of more general results on coalgebras [18]).

Theorem 2. The final object 1lD

is the coproduct of the image on models of thecanonical institution morphism from ID to CoAlg(ID).

Proof. For each A ∈ Obj(ModID(Σ)), we have the FΣ-coalgebra βI

D

Σ

(A) =

(∗, αA : ∗ → ΦI(Σ)(∗)), where αA is defined by αA(∗) = A. We can

consider a morphism iA between this coalgebra and 1lD

, concretely iA : ∗ →Obj(ModID(Σ)), defined also by iA(∗) = A. Let (X, α : X → FΣ(X)) beanother FΣ-coalgebra so that a morphism hA : ∗ → X between the coalgebrasβI

D

Σ

(A) and (X, α) exists for each A ∈ Obj(ModID(Σ)). We can then define

f : Obj(ModID(Σ)) → X as f(A) = hA(∗), ∀A ∈ Obj(ModID (Σ)), and itis clear that this is the (unique) morphism so that f(iA(∗)) = hA(∗) holds,∀A ∈ Obj(ModID (Σ)).

5 Conclusions and Future Work

In this paper we have showed the interest of the coalgebraic methods for mod-elling features of actual software systems such as EAT, a symbolic computation

Page 245: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

238 C. Domnguez, L. Lamban, V. Pas ual, J.Rubiosystem for Algebraic Topology. In addition, we have also illustrated how thiskind of applied research can have theoretical relevance, in our case, casting lighton a new algebra-coalgebra relationship and introducing a family of coalgebraicinstitutions with an intuitive and practical interpretation.

Without leaving the field of coalgebraic methods, further work will be nec-essary to know if our coalgebraic institutions can be generalized in order tocover coalgebras associated to non-constant functors without losing our intu-itive and practical interpretation. This will be the first step to establish aninstitutional comparison between the hidden and the coalgebraic approaches,comparison which, up to the authors’ knowledge, is still missing in the literature(this missing bridge has prevented us from presenting our institution morphismas the composition of two institution morphisms through a hidden institution).

References

1. M. Barr, Terminal coalgebras in well-founded set theory, Theoretical Computer Sci-

ence 114 (1993) 299-315.

2. R. Burstall, R. Diaconescu, Hiding and behaviour: an institutional approach, in A

Classical Mind: Essays in Honour of C.A.R. Hoare, Prentice-Hall (1994) 75-92.

3. C. Cırstea, Coalgebra semantics for hidden algebra: parameterised objects and in-heritance, Lecture Notes in Computer Science 1376 (1997) 174-189.

4. C. Domınguez, L. Lamban, M.V. Pascual, J. Rubio, Hidden specification of a func-tional system, in Proceedings EUROCAST’2001, Lecture Notes in Computer Science

2178 (2001).

5. C. Domınguez, J. Rubio, Modeling inheritance as coercion in a symbolic computationsystem, in Proceedings ISSAC’2001, ACM Press (2001) 109-115.

6. J. Goguen, R. Burstall, Institutions: Abstract model theory for specification andprogramming, Journal of the Association for Computing Machinery, 39(1) (1992)

95-146.

7. J. Goguen, G. Malcolm, A hidden agenda, Theoretical Computer Science 245 (2000)

55-101.

8. C. Hoare, Proofs of correctness of data representations, Acta Informatica 1 (1972)

271-281.

9. B. Jacobs, Mongruences and cofree coalgebras, Lecture Notes in Computer Science

936 (1995) 245-260.

10. B. Jacobs, J. Rutten, A tutorial on (co)algebras and (co)induction, EATCS Bulletin

62 (1997) 222-259.

11. L. Lamban, V. Pascual, J. Rubio, Specifying implementations, in Proceedings IS-

SAC’99, ACM Press (1999) 245-251.

12. L. Lamban, V. Pascual, J. Rubio, An object-oriented interpretation of the EATsystem. Preprint.

13. J. Loeckx, H. D. Ehrich, M. Wolf, Specification of Abstract Data Types, Wiley-

Teubner, 1996.

14. H. Reichel, An approach to object semantics based on terminal coalgebras, Mathe-

matical Structures in Computer Science 5 (1995) 129-152.

15. J. Rubio, Locally effective objects and Artificial Intelligence, Lecture Notes in Ar-

tificial Intelligence 1930 (2001) 223-226.

Page 246: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Modelling implementations as institution morphisms 23916. J. Rubio, F. Sergeraert, Y. Siret, EAT: Symbolic Software for Effective Homology

Computation, ftp://fourier.ujf-grenoble.fr/pub/EAT, Institut Fourier, Greno-

ble, 1997.

17. J. Rubio, F. Sergeraert, Y. Siret, Overview of EAT, a system for effective homologycomputation, Symbolic and Algebraic Computation Newsletter 3 (1998) 69-79.

18. J. Rutten, Universal coalgebra: a theory of systems, Theoretical Computer Science

249 (2000) 3-80.

19. G. Steele Jr., Common Lisp. The language, Second Edition, Digital Press (1990).

20. A. Tarlecki, R.M. Burstall, J.A. Goguen, Some fundamental algebraic tools for thesemantics of computation: Part 3. Indexed categories, Theoretical Computer Science

91 (1991) 239-264.

Page 247: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 248: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Tight and Loose Semantics for Transformation Systems

Fernando Orejas2, Hartmut Ehrig1, and Elvira Pino2

1 FB 13 Informatik, Tech. Univ. Berlin, Franklinstrasse 28/29, 10587 Berlin, [email protected]

2 Dpto de L.S.I., Universidad Politecnica de Catalunya, Campus Nord, Modul C6, Jordi Girona1-3, 08034 Barcelona, Spain.fpino,[email protected]

Abstract. When defining the requirements of a system, specification units typ-ically are partial or incomplete descriptions of a system component. In this con-text, providing a complete description of a component meansintegrating all theexisting partial views for that component. However, in manycases defining thesemantics of this integration operation is not an easy task.In particular, this isthe case when the framework used at the specification level is, in some sense, an“operational” one (e.g. a Petri net or a statechart). Moreover, this problem mayalso apply to the definition of compositional semantics for modular constructs forthis kind of frameworks.In this paper, we study this problem, at a general level. First, we define a gen-eral notion of framework whose semantics is defined in terms of transformationsover states represented as algebras and characterize axiomatically the standardtight semantics. Then, inspired in thedouble-pullback approachdefined for graphtransformation, we axiomatically present a loose semantics for this class of trans-formation systems, exploring their compositional properties. In addition, we seehow this approach may be applied to a number of formalisms.

1 Introduction

When defining the requirements of a system, specification units typically arepartial or incomplete descriptions of a system component. For example, aview-point [8] describes a component of a system from a certain perspective (e.g., aexternal user’s point of view), or ause case[18] describes (perhaps partially)one possible behaviour of a component or system. In this context, providing acomplete description of a component means integrating all the existing partialviews for that component. However, in many cases defining thesemantics ofthis integration operation is not an easy task. In particular, this is the case whenthe framework used at the specification level is, in some sense, an “operational”one (e.g. a Petri net or a statechart). Moreover, this problem may also apply tothe definition of compositional semantics for modular constructs for this kind offrameworks.

In this paper, we study this problem at a general level. First, we define ageneral notion of framework whose semantics is defined in terms of transfor-mations over states represented as algebras, and characterize axiomatically the

Page 249: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

242 F. Orejas, H. Ehrig, E. Pinostandardtight semantics. The approach is inspired in thedouble-pullback ap-proach[12, 13] defined for graph transformation and, especially in[7]. In thatpaper, the double pullback approach is, in a way, extended ina conceptual wayto deal with other frameworks. In this paper, the approach isdifferent. In par-ticular, we approach the problem in an axiomatic way characterizing tight andloose semantics for a general class of transformation systems, studying somecompositionality properties for the loose case. The basic idea in the case ofthe loose semantics consist in considering that the transformations defined by agiven specification should be interpreted as the minimal changes that should beperformed over a given state. In contrast to the case of the tight semantics wherethe transformations define exactly the changes that should be performed over agiven state. This is equivalent to eliminating the so-called frame assumption.

We believe that our approach may also be applicable for the definition ofcompositional semantics of modular constructs for certainclasses of program-ming or specification languages. Actually, another source of inspiration was thedefinition of compositional semantics for logic programs with negation [15].This was considered a difficult task due to the non-monotonicnature of negationas failure. In that paper, we avoided that problem by defininga loose semanticsfor this class of logic programs and, then, by defining adequate algebraic con-structions to define a least model semantics.

In order to show the application of our approach, we use as running ex-amples the cases of graph transformation using the double pushout approach,the single pushout approach and the double pullback approach, and the case ofplace/transition nets. Moreover, at the end of the paper we present the essentialideas underlying a loose semantics for logic programs with negation.

The paper is organized as follows. In section 2, we present a general formu-lation of tight transformation frameworks, showing how graph transformationby double and single pushouts and place/transition nets fit in our approach. Insection three, we modify the previous definitions to characterize loose trans-formation frameworks, showing that graph transformation by double pullbacksis a loose framework, and we show how these ideas can be used toprovidea loose semantics to tight transformation frameworks. Moreover, we define anoperation for combining transformation rules, that may be considered comple-mentary, and we provide an informal example of how our approach can be usedto give semantics to viewpoints specifications. Finally, insection four, we showhow one can restrict the loose interpretation of transformation rules by meansof constraints and we apply these ideas to the definition of semantics of logicprograms.

In this paper, we assume that the reader has a certain knowledge of themost standard algebraic concepts, together with the most usual notation (for

Page 250: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Tight and loose semanti s for transformation systems 243details, for example, one may consult [1]). We also assume that the reader hassome very basic knowledge of algebraic graph transformation (see e.g. [17]),place/transition nets [16] and logic programming [2].

2 Transformation systems

In this section we present the basic ideas underlying our approach. First, we de-fine a general notion of transformation framework and then weaxiomatize thestandard tight semantics that these formalisms usually have. As running exam-ples to discuss our definitions we study graph transformation (double and singlepushout approaches) and place/transition nets.

2.1 Basic notions

We consider that a transformation system is some kind of specification that de-fines a relation (a transformation relation) over a well-defined class of states. Inthis sense, a transformation framework is a formalism for specifying transfor-mation systems.

Some examples of transformation formalisms that we will consider alongthis paper are graph transformation systems (using the double pushout approachand the single pushout approach) and place/transition nets. Other obvious can-didates are all kinds of approaches based on the transformation of algebras, suchas Abstract State Machines (formerly called evolving algebras) [4, 11], D-oids[3], algebraic approaches to object specification [6] or Algebra TransformationSystems, [10]. Moreover, in the last section we will deal with the special case oflogic programs. In the case of graph transformation systems, states are graphsand transformation systems are sets of graph productions. In the case of thedouble pushout approach, productions are pairs of injective graph morphismsL H ! R, while in the case of the single pushout approach, productions areinjective partial graph morphismsL! R. In the case, of place/transition nets,states are net markings and the transformation systems are the nets themselves.The transformations denoted by a net are the possible firings.

In our case, to achieve a reasonable degree of generality, weassume thatstates are partialΣ-algebras. This covers most reasonable cases. For instance,in the case of graph transformation, graphs can be seen as total algebras over asignature including two sorts (one for vertices and one for edges) and two oper-ations providing, respectively, the source and target of each edge. Similarly, inthe case of place/transition nets, markings can be seen as algebras over a signa-ture including the signature of the natural numbers and, in addition, having asmany constants of sort natural as places in the net. However,we may consider

Page 251: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

244 F. Orejas, H. Ehrig, E. Pinothat not all the algebras over this signature are valid states. In particular, we mayconsider that the only valid states are the algebras whose carrier associated to thesortnatural corresponds to the set of natural numbers and where the interpre-tation of the natural number operators coincide with the corresponding naturalnumbers operations. On the other hand, we consider that a state transformationconsists of twoΣ-algebras (the source and target states) together with a trackingmap, which is an injective partial map relating the elementsof the source andtarget states that remain unchanged by the transformation.However, again, wemay consider that not all the possible tracking maps are valid for a given for-malism. For instance, in the case of place/transition nets only the identity shouldbe a valid tracking map. The reason is that this is the only reasonable relationbetween the elements (the natural numbers) of the source andtarget states.

Following these intuitions, we may define a transformation frameworkT asa 5-tuple consisting of: a class of signaturesSigT ; a mapping,States: SigT !P (PAlg), that associates to each signatureΣ the class of partialΣ-algebras thatcan be considered allowable states in the given framework; another mapping,Tmaps: SigT ! PIn jMaps, that associates to each signatureΣ the class ofpartial injectiveSorts(Σ)-maps that can be used as tracking maps in transfor-mations, a set of the transformation rules,Rules, allowed in the given frame-work; and a mapping,Tra fos: Rules! StateTra fos, that associates to eachtransformation rule the set of transformations defined by that rule. In particular,StateTra fosis the set of all possible transformations, i.e. the set of all 4-tuplesconsisting of a signatureΣ, two Σ-states which are the source and target of thetransformation, and a tracking mapt. We do not assume that the set of rules ofa given transformation framework has any specific form.

Definition 1. A transformation frameworkT is a 5-tuple(SigT ;States: SigT !P (PAlg);Tmaps: SigT ! PIn jMaps;Rules;Tra fos: Rules! StateTra fos),whereSigT is included inSig, the class of all signatures, andStateTra fosis theset of all possible state transformations inT . In particular, a state transforma-tion in StateTra fosis a 4-tuple(Σ;A1;A2; t), whereA1 andA22 States(Σ) arecalled the source and target states, respectively, andt = fts : A1! A2gs2Sorts(Σ)is the tracking map of the transformation, which is a family of partial injectivefunctions, writtent : A1! A2. In addition, we assume that, for every ruler ,Tra fos(r) is closed up to isomorphism and tracking maps, i.e. if(Σ;A1;A2; t)is in Tra fos(r), h1 : A1 ! A10 and h2 : A2 ! A20 are Σ -isomorphisms and(t 0 : A10!A20)2Tmaps(Σ), such thatdom(t 0)= h1(dom(t))andt 0h1= h2t,then(Σ;A10;A20; t 0) is also inTra fos(r).Example 2.The double pushout approach to graph transformation can be de-fined formally as follows.SigT , contains only the graphs signature:

Page 252: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Tight and loose semanti s for transformation systems 245GRAPHS= sortsvertex;edge

opns source; target: edge! vertex

States are total algebras over the above signature. Rules are spans of injectivehomomorphisms,L K ! R. Tracking maps are pairs of arbitrary injectivepartial maps,tvertex : Gvertex! Hvertex andtedge: Gedge! Hedge, defined as fol-lows:

– For everyn in Dvertex, tvertex(l(n)) = r(n)– For everyn in Gvertexnl(D), tvertex(n) is undefined– For everye in Dedge, tedge(l(e)) = r(e)– For everye in Gedgenl(D), tedge(e) is undefined

Finally, (Σ;G;H; t), is a transformation associated to the previous rule ifthere is a graphD and morphismsm;d;m; l andr such that diagrams (1) and(2) in figure 1 are pushouts. Then, for every ruler , Tra fos(r) is closed un-der isomorphism and tracking maps by the definition of the associated trackingmaps and because pushouts are closed under isomorphism.

D

K

H

R

G

L

(1) (2)? ? - ?- d mm

rlFig. 1. Double pushout

Example 3.The single pushout approach to graph transformation can be de-fined formally as follows.SigT , StatesandTmapsare defined as for the doublepushout approach.Rulesare partial injective homomorphisms,p : L! R. Fi-nally, (Σ;G;D; t), is a transformation associated to the previous rule if there aremorphismsm, m and p such that the diagram in figure 2 is a pushout in thecategory of graphs and partial graph morphisms, and wheret is the restrictionof p to the category of sets and partial mappings.

Again,Tra fos(r) is closed under isomorphism and tracking maps becausepushouts are closed under isomorphisms.

Page 253: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

246 F. Orejas, H. Ehrig, E. PinoG

L

H

R? - ?-m m

pp

Fig. 2. Single pushout

Example 4.Place/transition nets can be defined formally as follows. Assaidabove,SigT consists of signatures extending the signature of natural numberswith a number of constants of sortnat, a constant representing each place in thenet.Statesare total algebras extending the natural numbers. The only trackingmaps considered are the identity functions. As said above, the reason is that,in this case, the states only contain value sorts (the natural numbers) and theyshould remain unchanged under transformation.Rulesare the sets of transitionsin a net. Finally,(Σ;A1;A2; t) is a transformation associated to a netN if we canpass from the markingA1 to the markingA2 by the firing of some transition inN.

2.2 Tight transformations frameworks

Two basic ideas underlie standard (tight) transformation frameworks. The firstone is what we may call the locality assumption. This principle says that, ifa given rule defines a transformation on a stateA, producing as result a stateB, then this rule may also be applied to a larger stateA0, includingA in somewell-defined sense, obtaining a stateB0, includingB. The second basic idea isthe so-called frame assumption. This assumption implies that, when applyinga local transformation on part of a stateA, the rest of the state should remainunchanged in the result.

In order to formalize these two assumptions, we must, first, define whatwe mean by saying that a stateA0 includes a stateA. On the one hand, wemay consider that ifA is a subalgebra ofA0 thenA0 includesA. For instance,dealing with graphs as algebras, the subgraph relation would correspond to thesubalgebra relation. On the other hand, we may also considerthat if a signatureΣ is included inΣ0, and the statesA andA0 are, respectively aΣ-algebra and aΣ0-algebra, such thatA0jΣ = A, thenA0 also includesA. For instance, ifA denotes amarking of a certain net, then an extension ofA with respect to a larger signaturewould correspond to a marking of a net including more places.Mixing these

Page 254: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Tight and loose semanti s for transformation systems 247two conditions, we may say that aΣ-stateA is included in aΣ0-stateA0 if A is asubalgebra ofA0jΣ.

According to these ideas, we may say that a transformation framework is atight transformation framework if the locality and the frame assumptions hold.This may be formalized as follows:

Definition 5. T = (SigT ;States;Tmaps;Rules;Tra fos) is a tight transforma-tion framework if the following two properties hold:

(1) If τ= (Σ;A;B; t)2 Tra fos(r), then for everyΣ0 2 SigT , A0;B0 2 States(Σ0),such thatΣ Σ0, A0jΣ = A andB0jΣ = B, and every tracking mapt : A0 ! B0such that: For everys in Sorts(Σ); t 0s= ts For everys in Sorts(Σ0)nSorts(S); t 0s= id For everyσ in Σs1:::sn;s;σB0 = σB For everyσ in Σ0

s1:::sn;snΣ and for all(a10; : : :;an0) in B0s1 : : :B0

sn

σB0(a10; : : :;an0) = t 0s(σA0(t 0 1s1 (a10); : : :; t 0 1

sn (an0)))where= should be interpreted as strong equality (i.e.e= e0 if both ex-pressions are defined and equal or both are undefined), and where if onesubexpression in undefined (e.g.,t 0 1

s1 (a10)) then the result of the wholeexpression is considered undefined.

we have that the transformation(Σ0;A0;B0; t 0) 2 Tra fos(r).(2) If τ = (Σ;A;B; t) 2 Tra fos(r), then for everyA0;B0 2 States(Σ), such that

A A0, andB B0, and every tracking mapt : A0 ! B0 such that: For everys in Sorts(Σ), B0s= (A0

snAs)+Bs, where, as usual,+ denotes disjoint union. For everya2 As, t 0s(a) = ts(a). For everya2 A0snAs, t 0s(a) = a. For everyσ in Σs1:::sn;s and for all(a10; : : : ;an0) in B0

s1 : : :B0sn

σB0(a10; : : :;an0) = t 0s(σA0(t 0 1s1 (a10); : : :; t 0 1

sn (an0)))we have that the transformation(Σ0;A0;B0; t 0) 2 Tra fos(r).Properties (1) and (2) take care of the locality and frame assumptions for

both kinds of state inclusion described above, and the combination of both prop-erties takes care of the general notion of state inclusion. We could have provideda single property combining (1) and (2) in an obvious way. However we thinkthat the splitting into two properties is simpler to deal with.

Page 255: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

248 F. Orejas, H. Ehrig, E. PinoProposition 6. 1. The double pushout approach for graph transformation is a

tight transformation framework.2. The single pushout approach for graph transformation is atight transfor-

mation framework.3. Place/transition nets are a tight transformation framework.

Proof. 1. Property (1) holds trivially for graph transformation since there isjust one signature inSigT . With respect to property (2), let us suppose that(Σ;G;H; t) 2 Tra fos(r) by means of the double pushout diagram in figure1, and suppose thatG0, H 0 andt 0 are as in property (2) above. Then, we canbuild the double pushout diagram in figure 3, where all the vertical arrowsare inclusions, and where the pushout complementD0 is D0 = D+(G0nG).

D0D

H 0H

G0G? ? - ?- rlFig. 3.

To show thatD0 is indeed a pushout complement we must show that the top-most left corner satisfies the so-called gluing conditions.In particular, wemust show that the “dangling condition” holds (the so-called identificationcondition holds trivially in our case), i.e. that there cannot be an edgee inG0nG which is incident to a node inGnD. Suppose thatn = sourceG0(e)(or, similarly,n= targetG0(e)) is in GnD and e is inG0nG. Then we wouldhave thattnode(n) is undefined, by the definition of the tracking map asso-ciated to the first double pushout, and, as a consequence, so is thatt 0

node(n).However, according to the conditions stated in property (2), we would havethatt 0

edge(e) = eandsourceH0(e) = t 0edge(sourceG0(e)), which means thatH 0

would be ill-formed.Now, the gluing of the two double pushout diagrams provides us with thedesired transformation and the corresponding tracking mapcoincides withthe definition in property (2)

2. Again, it is enough to prove that property (2) holds. The proof is similar.Suppose that(Σ;G;H; t) 2 Tra fos(r) by means of the pushout diagram in

Page 256: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Tight and loose semanti s for transformation systems 249figure 2, and suppose thatG0, H 0 andt 0 are as in property (2) above. Then, thediagram in figure 4, where the vertical arrows are inclusions, is a pushout.

G0G

H 0H? - ?-pFig. 4.

Finally, the gluing of the two pushout diagrams provides us with the de-sired transformation and the corresponding tracking map coincides with thedefinition in property (2).

3. In this case it is property (2) that holds trivially, sincethe only states alloweddiffer only on the number and the value of the constants representing theplaces of the nets. This means that there do not exist two statesA andBsuch thatA is a strict subalgebra ofB. With respect to property (1), it shouldbe clear that, independently of the places in a net the effectof a firing onlymodifies the values of the constants associated to the positions involved inthe transition.

3 Loose transformation frameworks

As discussed in the introduction, requirements specifications are typically in-complete specifications, i.e. they usually describe some partial aspects of thebehaviour of a system. In the case of specifications using some kind of trans-formation framework, this means that the transformation rules associated to agiven event only describe, partially, the state transformations that should hap-pen when this event occurs. According to this intuition, we may consider that,in this context, an event may cause some additional transformations not spec-ified by the given transformation system. This is equivalentto eliminating theframe assumption when defining the semantics of a transformation system. Thiscan be obtained by relaxing properties (1) and (2) of tight transformation sys-tems, just asking for the satisfaction of the locality assumption. In particular,the below properties, (3) and (4), state that if a certain transformation can be

Page 257: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

250 F. Orejas, H. Ehrig, E. Pinoapplied to a stateA, yielding a stateB, then this transformation should be alsoapplicable to any larger stateA0. In this case, any stateB0 includingB, in somewell-defined sense, could be a possible result of the transformation. The idea isthat the concrete stateB0 obtained depends on the additional changes caused bythe “environment”.

In our opinion, this kind of loose transformation frameworks are adequatefor certain forms of requirements specifications. This is the case, for instance, ofthe so-called viewpoints approach. The idea is that, when specifying a given sys-tem, one describes its functionality by means of several complementary pointsof view (e.g. the external user view, the system manager view, etc.) Then, thecomplete specification of the system is given by the integration or combinationof all the views. In what follows, we informally describe an example of thespecification of a system using this approach, to motivate the rest of the section.

Example 7.Let us consider as a simple example the specification of a logisticsinformation system for a certain company. We assume that this company has acertain number of stores, where the items produced by the company are keptin stock, and certain number of shops that sell these items tothe end customer.Moreover the company has also a number of trucks, whose location is not fixeda priori, for delivering the items. From time to time, a certain shop may askthe system for a supply ofN units of a certain item. Then the system mustdecide from which store are these items supplied and register the delivery on thecompany accounts. In what follows, we briefly describe this supply operationfrom different viewpoints.

– A shop manager viewpoint: From the point of view of the manager of ashop, the effect of asking for the supply ofN units of a certain item couldbe that the stock of one store (maybe more than one as possiblechoices)should be decreased byN units and the stock in the shop of that item shouldbe increased byN units.

– The logistics manager viewpoint: From the point of view of the person incharge of the logistics of the company, the effect of asking for the supply ofN units of a certain item to a given shop could be that the stock of that itemon a certain store should be decreased byN units and the stock in the shopof that item should be increased byN units. In addition, that store is selectedamong the stores having enough stock for that delivery, on the basis of thetransportation cost, considering the distance of the storeto the shop and tothe closer free truck. Moreover, the selected truck should be marked as busy.

– The accounting manager viewpoint: From the point of view of the person incharge of the accounting of the company, the effect of askingfor the supplyof N units of a certain item to a given shop could be that the globalvalue

Page 258: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Tight and loose semanti s for transformation systems 251of the stocked items should be decreased by the value of the items deliveredand the income of the company should be increased by that value.

Now we could formalize these viewpoints by means of some kindof algebratransformation approach. Each viewpoint would be described by a transforma-tion rule that describes only part of the transformations associated to the supplyoperation. It may be noted that, in this example, the second and the third (or thefirst and the third) viewpoints are, in a way, orthogonal. Their associated trans-formations would deal with different parts of the “global” state of the system.However, in the case of the shop manager viewpoint and the logistics managerviewpoint, their associated transformations partially overlap. In particular, withrespect to that overlapping the logistics manager viewpoint can be seen as a re-finement of the shop manager viewpoint, since in the latter case the choice ofthe store is nondeterministic.

Then, the complete specification of the supply operation would be the com-bination, using the operation described at the end of the section, of the transfor-mation rules associated to these three viewpoints.

Definition 8. T = (SigT ;States;Tmaps;Rules;Tra fos) is a loose transforma-tion framework if the following two properties hold:

(3) If τ = (Σ;A;B; t) 2 Tra fos(r), then for everyΣ0 2 SigT and everyA0;B0 2States(Σ0), such thatΣΣ0;A0jΣ =AandB0jΣ =B, and for everyt 0, such thatt 0jSorts(Σ) = t, we have that the transformation(Σ0;A0;B0; t 0) 2 Tra fos(r).

(4) If τ = (Σ;A;B; t)2 Tra fos(r), then for everyA0;B0 2 States(Σ0), such thatA A0 andB B0, and for everyt 0, such thatt 0jA = t, we have that thetransformation(Σ0;A0;B0; t 0) 2 Tra fos(r).

wheret 0jSorts(Σ) andt 0jA denote, respectively, the restriction oft 0 to the sorts ofthe signatureΣ and the restriction oft 0 to the elements of the subalgebraA.

Definition and Proposition 9. The double pullback approach for graph trans-formation is a loose transformation framework

Proof. The double pullback approach to graph transformation can bedefinedformally as follows.SigT , States, Rulesand tracking maps are as for the doublepushout approach. Then,(Σ;G;D; t), is a transformation associated to the ruleL K ! R, if there is a graphD and morphismsm;d;m; l andr such thatl andr are injective homomorphisms and diagrams (1) and (2) in figure 5 arepullbacks, and wheret is defined as follows:

– For everyn in Dvertex, tvertex(l(n)) = r(n)

Page 259: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

252 F. Orejas, H. Ehrig, E. Pino– For everyn in Gvertexnl(D), tvertex(n) is undefined– For everye in Dedge, tedge(l(e)) = r(e)– For everye in Gedgenl(D), tedge(e) is undefined

D

K

H

R

G

L

(1) (2)? ? - ?- d mm

rlFig. 5.Double pullback

Moreover, for every ruler , Tra fos(r) is closed under isomorphism andtracking maps by the definition of the associated tracking maps and becausepullbacks are closed under isomorphism.

In this case, we just have to prove property (4). Suppose that(Σ;G;H; t)2Tra fos(r) by means of the double pullback diagram in figure 5, and supposethat G G0, H H 0 and t 0jG0 = t. Then, we can build the double pullbackdiagram in figure 6, whereD0 =D+(dom(t 0)ndom(t))and where all the verticalarrows are inclusions. The gluing of the two double pullbackdiagrams providesus with the desired transformation.

D0D

H 0H

G0G? ? - ?- rlFig. 6.

Additionally, the tracking map associated to this double pullback coincides,by construction, witht 0.

Obviously, every loose transformation framework is also a tight transforma-tion framework, but the converse is not true in general.

Page 260: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Tight and loose semanti s for transformation systems 253Fact 10. If T is a loose transformation framework thenT is a tight transfor-mation framework.

This fact may seem counterintuitive, since, together with the previous propo-sition, it states that the double pullback approach is a tight transformation frame-work. An alternative definition of tight and loose transformation frameworkscould consist in, first, considering that, in a transformation framework, everyrule r defines a set of minimal transformations,MinTra fo(r). Then, we wouldsay that a transformation framework is tight (resp. loose) if, for every ruler ,Tra fo(r) is the closure ofMinTra fo(r) with respect to properties (1) and (2)(resp. with respect to properties (3) and (4)). According tothat alternative defi-nition, in general, loose transformation frameworks wouldnot be tight. Instead,we could consider tight transformations as special cases ofloose transforma-tions, as double pushout transformations can be seen as special cases of doublepullback transformations, as we will see below. This would probably fit betterour intuition.

On the other hand, the previous fact gives us a way of defining aloosetransformation semantics for tight transformation frameworks. In particular, itis enough to make a closure, with respect to the properties (3) and (4) above, ofthe transformations associated to the given rules:

Definition 11. Let T = (SigT ;States;Tmaps;Rules;Tra fos) be a transforma-tion framework andr be a rule inRules, we define the loose extension ofTra fos(r), denotedLoose(Tra fos(r)) as the least set of transformations, sat-isfying properties (3) and (4) that includesTra fos(r). We also define the loosetransformation framework associated withT , Loose(T ) as:

Loose(T ) = (SigT ;States;Tmaps;Rules;LTra fos)where, for everyr , LTra fos(r) = Loose(Tra fos(r))

One may wonder whether the double pullback approach is the loose versionof the double pushout approach. The answer is negative. There are some doublepullback transformations which can not be obtained by the loose closure of thedouble pushout transformations. The reason is that, given aproductionL K! R and a morphism fromL to a graphG we can not always build a doublepushout to define a transformation. It is required that certain conditions (theso-called gluing conditions) hold. However, for building adouble pullback therequired conditions are looser. In this context, a double pullback transformation,where the gluing conditions are not satisfied, would not correspond to any looseextension of a double pushout transformation.

Page 261: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

254 F. Orejas, H. Ehrig, E. PinoDefinition and Proposition 12. The faithful double pullback approach for graphtransformation is the loose transformation framework associated with the dou-ble pushout approach.

Proof. The double pullback transformation in figure 7 is faithful ifm satisfiesthe identification condition. This means that ifx1 andx2 are elements (verticesor edges) ofL such thatm(x1)=m(x2) then, eitherx1= x2, or there existy1 andy2 in K such thatl(y1) = x1 andl(y2) = x2. Then the faithful double pullback

D

K

H

R

G

L

(1) (2)? ? - ?- d mm

r

rllFig. 7.

approach is defined as the double pullback approach, but where only faithfultransformations are allowed. The proof that this frameworkis a loose transfor-mation framework is like the one for the general double pullback approach. Theproof that every faithful double pullback transformation is an extension, withrespect to property (4), of a double pushout transformationcan be found in [13].

The loose versions of the single pushout approach and of place/transitionnets are quite obvious: we can loosely transform graphG into graphH by meansof the graph productionL! R, if there are graphsG0 andH 0 such thatG0 G,H 0 H and the diagram in figure 8 is a pushout.

By analogy with the case of double pushouts/pullbacks, one may wonderwhether this can be characterized by means of a simple pullback, but the answeris no. The problem is that a pushout diagram in the category ofgraphs and partialmorphisms, such as the one in figure 8 may be not a pullback in that category asthe following counter-example shows. IfL is a graph with just two nodes, sayn1andn2, R andG0 are graphs with just one node, sayn1, p is a partial morphismbindingn1 in L to n1 in Randm is a morphism bindingn1 andn2 in L to n1 inG0. Then the result of the pushout,H 0 would be the empty graph. However, thepullback ofp andm would be the empty graph and notL.

Page 262: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Tight and loose semanti s for transformation systems 255G0L

H 0R? - ?-m m

pp

Fig. 8.

With respect to the case of place/transition nets, the result of a loose trans-formation associated to a given transition for a certain marking M would be anyother marking such that the value of the positions associated to the transitionare the ones specified by the transition, but the values of therest of the positionsmay have changed in any arbitrary way.

As said above, the intuition behind loose transformation frameworks is thatrules specify incompletely a certain class of transformations. In this context, wedefine an operation for combining the effects of two (or more rules). The ideais that, using this operation, one can complete or refine an incomplete transfor-mation specification. The definition of this operation is quite simple: one cantransform a stateA into a stateB if a “parallel” application of the combinedrules provide this effect:

Definition 13. Let T = (SigT ;States;Tmaps;Rules;Tra fos) be a loose trans-formation framework , the combination of two rulesr andr 0, rjr 0 is a rule thatdefines the following set of transformations:(Σ;A1;A2; t)2Tra fos(rjr 0) if and only if there existΣ0;Σ002SigT ;B0;C02States(Σ0);B00;C00 2 States(Σ00), and tracking mapst0 : B0! C0 andt00 :B00 !C00, such that:

– (Σ0;B0;C0; t0)2 Tra fos(r)– (Σ00;B00;C00; t00) 2 Tra fos(r 0)– B0 A1jΣ0 andB00 A1jΣ00– C0 A2jΣ0 andC00 A2jΣ00– t0= tjB0 andt00 = tjB00 wheretjB0 andt 0jA denotes, respectively, the restric-

tion of t 0 to the sorts of the signatureΣ0 and to the elements of the subalgebraB0.

As one can expect, the combination of two rules has a very simple compo-sitional semantics:

Proposition 14. Tra fos(rjr 0) = Tra fos(r)\Tra fos(r 0)

Page 263: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

256 F. Orejas, H. Ehrig, E. PinoProof. If (Σ;A1;A2; t)2 Tra fos(rjr 0) then,according to the previous definition,there existΣ0 2 SigT ;B02 States(Σ0);B00 2 States(Σ00), and a tracking mapt0 : B0!C0, such(Σ0;B0;C0; t0)2 Tra fos(r), B0A1jΣ0 andt0= tjB0. Thismeans that(Σ;A1jΣ0;A2jΣ0; tjΣ0) 2 Tra fos(r), since the framework is closedunder (4). But this implies that(Σ;A1;A2; t)2 Tra fos(r) since the frameworkis closed under (3). The proof forr 0 is similar. Conversely, if(Σ;A1;A2; t) 2Tra fos(r) and(Σ;A1;A2; t)2 Tra fos(r 0) then(Σ;A1;A2; t)2 Tra fos(rjr 0): itis enough to takeΣ0=Σ= Σ00, B0=A1=B00,C0=A2=C00, andt0= t = t00.4 Loose transformation frameworks with constraints

One may consider that loose transformation frameworks are too loose for manypractical applications. In particular, we may know that state transformations de-fined by a given rule should not produce any effect on a certainpart of the state,i.e. we may want to have some restricted form of the frame assumption. This ishandled in the double pullback approach by defining open transformations overtyped graphs [14, 12], allowing us to express that part of thegiven graph shouldnot change after a transformation. We could have defined something similar byassuming that, given a certain signatureΣ0, when applying a transformationover aΣ-stateA, with Σ includingΣ0, this transformation should not produceany change on theΣ0 part ofA. This means that, ifB is the result of the transfor-mation, thenBjΣ0 = AjΣ0. However, this may be not enough. We may also wantthat the resulting state satisfies certain conditions with respect to the sourcestate. For instance, if the given signatureΣ includes a constantc of sort integer,we may want to restrict the transformations overΣ-states so that the value ofc in the target state is always greater that the value ofc in the source state. Asimple way of doing this is to assume that transformation frameworks may beequipped with a set of constraints that may be imposed on the rules. We may as-sume that these constraints are some kind of logic formula. However, in order tobe general enough, we will not assume that constraints have any specific form.Instead, we will define constraints in a kind of institution-independent way [9],similarly to the related notion of logic of constraints in [5]

Definition 15. Let T = (SigT ;States;Tmaps;Rules;Tra fos) be a transforma-tion framework, a logic of constraints forT is a pair(Constraints; j=), whereConstraints: SigT ! Set is a functor associating to every signatureΣ in SigTa set of constraints over state transformations on that signature, andj== fj=ΣStateTra fos(Σ)Constraints(Σ)gΣ2SigT is aΣ-indexed family of relations be-tweenConstraints(Σ) andΣ-transformations, whereStateTra fos(Σ) is the set

Page 264: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Tight and loose semanti s for transformation systems 257of all possibleΣ-transformations(Σ;A;B; t). In addition we require the follow-ing satisfaction condition:

For everyΣ1;Σ22 SigT , every signature morphismh : Σ1! Σ2, everyΣ1-constraintc1, everyΣ2-statesA2;B2 and every tracking mapt : A2! B2, wehave that: (Σ2;A2;B2; t) j=Σ2 c2 i f f (Σ1;A2jh;B2jh; tjh j=Σ1 c1)wherec2=Constraints(h)(c1), and wheretjh denotes the reduction oft alongh, i.e. for everys2 Σ1, (tjh)s= tjh(s).

As usual, the satisfaction condition ensures that constraints over a givensignature are uniformly translated over signature morphisms. This implies, inparticular, that if a constraint is satisfied by a transformation over a given state,then this constraint (or, rather, its translation) would also be satisfied by anyextension of this transformation over a state having a larger signature.

Now, we can extend the previous definition of loose transformation frame-works to include constraints. The idea, on the one hand, is toconsider that eachrule considered is equipped with a set of constraints. To this aim, we will firstdefine the class of all constraints associated to a given logic and, then, extend theconstraints satisfaction relation to sets of constraints over different signatures.

Definition 16. Let L = (Constraints; j=) be a logic of constraints over a trans-formation frameworkT , we defineConstr(L), the class of all constraints asso-ciated toL, as:

Constr(L) = [Σ2SigT

f(Σ;c)= c2Constraints(Σ)gIf C is a set of constraintsCConstr(L), we say that a transformation(Σ;A;B; t)satisfiesC, denoted(Σ;A;B; t) j=C if and only if 8(Σ;c) 2C, (Σ;A;B; t) j=Σ c.

On the other hand, it is assumed that properties 3) and 4) should apply onlyto transformations satisfying the given constraint:

Definition 17. Let T = (SigT ;States;Tmaps;Rules;Tra fos) be a transforma-tion framework andL = (Constraints; j=) be a logic of constraints overT , thenT is a loose transformation framework with respect to the set of constrainedrulesCRules RulesP (Constr(L)) if and only if for every(r;C) 2 CRulesthe following two properties hold:

(5) If τ = (Σ;A;B; t)2 Tra fos(r) and(Σ;A;B; t) j=C, then for everyΣ0 2 SigTand everyA0;B0 2 States(Σ0), such thatΣ Σ0, A0jΣ = A andB0jΣ = B, andfor everyt 0, such thatt 0jSorts(Σ) = t, if (Σ0;A0;B0; t 0) j=C then(Σ0;A0;B0; t 0) 2Tra fos(r).

Page 265: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

258 F. Orejas, H. Ehrig, E. Pino(6) If τ = (Σ;A;B; t) 2 Tra fos(r) and(Σ;A;B; t) j= C, then for everyA0;B0 2

States(Σ), such thatA A’ and B B0, and for everyt 0, such thatt 0jA = t,if (Σ0;A0;B0; t 0) j=C then(Σ0;A0;B0; t 0) 2 Tra fos(r).Now, we can extend the composition operation defined in the previous sec-

tion to the composition of constrained rules:

Definition 18. Let T = (SigT ;States;Tmaps;Rules;Tra fos) be a loose trans-formation framework, the combination of two constrained rules(r;C) and(r 0;C0),(r;C)j(r 0;C0) is the constrained rule(rjr 0;C[C0).Proposition 19. If T is a loose transformation with respect to the set of con-strained rules CRules, then for all rules(r;C) and(r 0;C0) in CRules:

Tra fos((r;C)j(r 0;C0)) = Tra fos((r;C))\Tra fos((r 0;C0))Proof. If (Σ;A1;A2; t)2 Tra fos(rjr 0) and(Σ;A1;A2; t) j=C[C0 then we havethat(Σ;A1;A2; t)2 Tra fos(r) and, obviously,(Σ;A1;A2; t) j=C. The converseis trivial.

Now, using the approach of loose transformation frameworkswith con-straints, we will see how we can define a compositional semantics for logicprograms with negation. For simplicity, we will just consider the propositionalcase. The approach presented in the example is a (very) simplified reformula-tion of part of the work presented in [15], where the general first-order case isconsidered.

Example 20.A propositional logic program with negation is a set of groundclauses having the form:

a :`1; ::; `n

wherea is an atom and eachi is a positive or a negative literal, i.e.ai or :ai ,whereai is an atom. There are several ways to define the semantics of a logicprogramP. Here we will just consider the semantics in terms of a (continuous)immediate consequence operatorTP. This semantics is used to define a leastmodel semantics by means of the least fixpoint ofTP. This operator is defined asa mapping transforming logical structures into logical structures, where a logicalstructure, in this context, is a 3-valued Herbrand structure that is, a pairA =(A+;A) of sets of atoms (representing the positive and the negativeinformationin the structure) satisfyingA+i \A

i = (consistency condition). The idea of theimmediate consequence operator is thatTP(A) should contain all the atoms thatare one-step consequences of the programP and the information inA . Thismeans thatTP(A) = (B+;B), where:

Page 266: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Tight and loose semanti s for transformation systems 259B+ = A+[faj9a : `1; ::; `n2 P such that 1; ::; `n2 Ag (a)

B = A[faj8a : `1; ::; `n2 P;9i such that:`i 2 Ag (b)where` 2 A means that 2 A+, in case` is positive, or` 2 A, in case isnegative. Definition (a) is the standard one when dealing with positive programs(without negation). On the other hand, Definition (b) is a very weak version ofnegation-as-failure.

Now, we can reformulate the above definitions as a tight transformationframework. States are sets of atoms (which can easily be formulated in severalways as algebras over an appropriate signatureΣ), rules are programs, states are3-valued Herbrand structures, and the transformation defined by a programPon a stateA is TP(A). Finally, since the transformations associated to a programalways add atoms to the given structure, we may consider thatthe tracking mapsare always the identity.

In order to define a compositional semantics, we will now present a loosesemantics for this class of programs. However, this definition is not a directapplication of definition 11. The key idea is to consider that, if we think that aprogramP is incomplete, then the transformation associated toP, when appliedto a stateA = (A+;A), shouldat leastadd toA+ all the immediate positiveconsequences (i.e.faj9a : `1; ::; `n 2 P such that 1; ::; `n2 Ag) and shouldatmostadd toA all the immediate negative consequences (i.e.faj8a :`1; ::; `n2P;9i; such that:`i 2 Ag). The reason is that adding more clauses toP wouldprovide additional positive consequences but fewer negative consequences.

Now, we may obtain the desired semantics as follows. First, we reformu-late the tight semantics considering programs as if they were positive. Thismeans that(Σ;A ;B ; t) is a transformation associated toP if B+ = A+[faj9a :`1; ::; `n 2 P such that 1; ::; `n2 Ag, B = A andt is the identity.

Then, we consider the loose extension of this framework. In this case, wecan see that this loose extensionLTra fo(P) would include all transformations(Σ;A ;B ; t) such that there are structuresA 0 A andB 0 B , such thatB0+ =A0+[faj9a :`1; ::; `n2P such that 1; ::; `n2Ag andB0=A0. However, thisloose extension is not yet what we want. We have to make sure that the negativeatoms that can be added inB with respect toB 0 are consistent with the negationas failure rule. This can be done by imposing a constraint on rules. In particular,this constraintC would be:8a2 BnA0;8a : `1; ::; `n2 P;9i, such that:`i 2 A

It is not difficult to prove that the following compositionalityproperty holds:

LTra fos((P1[P2;C)) = LTra fos((P1;C))\LTra fos((P1;C))

Page 267: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

260 F. Orejas, H. Ehrig, E. Pino5 Conclusions

The work presented in this paper has been motivated by the need of providinga loose semantics to transformation systems, in order to deal with requirementsspecifications and to provide compositional semantics to modular units. In thissense, we have introduced a general axiomatic approach to deal with transfor-mation systems, showing how this approach can be applied to anumber of cases.In particular, the double and single pushout approaches andthe double-pullbackapproach to graph transformation, place/transition nets and logic programs withnegation have been considered.

First, we have defined a notion of tight transformation framework, charac-terizing the locality and frame assumptions that underlie most operational ap-proaches. Then, we have seen how, by eliminating the frame assumption, onecan define loose transformation frameworks that can be used to give loose se-mantics to tight transformation approaches. Finally, we have seen how one canimpose some constraints to restrict, as needed, the semantics of loose frame-works.

AcknowledgementsThis work has been partially supported by the CICYTproject HEMOSS (ref. TIC98-0949-C02-01) and CIRIT GRC 1999SGR-150.

References

1. E. Astesiano. H.-J. Kreowski, B. Krieg-Brueckner,Algebraic Foundations of System Speci-fication, IFIP State of the Art Reports, Springer, 1999.

2. K.R. Apt,, Logic Programming, inHandbook of Theoretical Computer Science, Vol B: For-mal Models and Semantics, Chapter 10, Elsevier, 1990.

3. Astesiano, E., Zucca, E.: D-oids: A Model for Dynamic DataTypes.Mathematical Struc-tures in Computer Science5 (1995), pp. 257–282

4. Boerger, E., Huggins, J.K.: Abstract State Machines 1988-1998; Commented ASM Bibliog-raphy,Bull. EATCS64 (1998), pp. 105–127

5. H. Ehrig, A Categorical Concept of Constraints for Algebraic Specifications; in:CategoricalMethods in Computer Science - with Aspects from Topology, (H. Ehrig, H. Herrlich, H.-J.Kreowski, G. Preuss, eds.), Springer LNCS 393 (1989).

6. H.-D. Ehrich, Object specification, in [AKK 99], 1999.7. H. Ehrig, R. Heckel, M. Llabres, F. Orejas, J. Padberg, G. Rozenberg A Rule-Based Frame-

work with Incomplete Information, inTheory and Applications of Graph Transformations(H. Ehrig, G. Engels, H.-J. Kreowski, G. Rozenberg eds.), Springer LNCS 1764 (2000) 85–102.

8. A. Finkelstein, J. Kramer, B. Nuseibeh, M. Goedicke, L. Finkelstein, Viewpoints: A frame-work for integrating multiple perspectives in system development,Int. J. of Software andKnowledge Engineering2,1 (1992) 31–58.

9. J.A. Goguen, R.M. Burstall. Institutions: Abstract model theory for specification and pro-gramming,J. of the ACM39(1), 95–146, (1992)

10. Grosse-Rhode, M.: Algebra Transformation Systems and their Composition, Springer LNCS1382 (1998), pp. 107–122

Page 268: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Tight and loose semanti s for transformation systems 26111. Gurevitch, Y.: Evolving Algebras, A Tutorial Introduction. Bull. EATCS43 (1991), pp. 264-

28412. R. Heckel,Open Graph Transformation Systems: A New Approach to the Compositional

Modelling of Concurrent and Reactive Systems, PhD Thesis, TU Berlin 1998.13. R. Heckel, H. Ehrig, U. Wolter, A. Corradini, Double-Pullback Transitions and Coalge-

braic Loose Semantics for Graph Transformation Systems,Applied Categorical Structures9(2001) 83–110.

14. R. Heckel, A. Corradini, H. Ehrig, M. Loewe, Horizontal and Vertical Structuring of TypedGraph Transformation Systems,Mathematical Structures in Computer Science6(6) (1996)613–648.

15. P. Lucio, F. Orejas, E. Pino. An algebraic framework for the definition of compositionalsemantics of Normal Logic Programs.Journal of Logic Programming40(1) (1999) 89–124.

16. Reisig, W.:Petri Nets. EATCS Monographs in TCS 4, Springer Verlag, 198517. Rozenberg, G. (ed.):Handbook of Graph Grammars and Computing by Graph Transforma-

tion, Vol 1 Foundations, World Scientific, 199718. G. Schneider, J. Winters,Applying use cases, Addison Wesley, 1998.

Page 269: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 270: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Comparison between three Non-determinismAnalyses in a Parallel-Fun tional LanguageRi ardo Pe~na and Clara SeguraDepartamento de Sistemas Informati os y Programa ionUniversidad Complutense de Madrid, Spaine-mail: fri ardo, seguragsip.u m.esAbstra t. The paper ompares three analyses to determine when anEden expression is sure to be deterministi , and when it may be non-deterministi . This work extends previous works where the three anal-yses were presented and ompared with respe t to expressiveness andeÆ ien y. The rst analysis has linear ost, the se ond one exponential ost, and the third one polynomial ( ubi ) ost. In this paper: (1) the se -ond and third analyses are ompleted with polymorphism, (2) we provethat the domains in the se ond and third analyses form a ategory inwhi h the morphisms are embedding- losure pairs of fun tions; and (3)we formally relate the analyses and prove that the rst analysis is a safeapproximation to the third one (in a previous paper we already provedthat the third one is a safe approximation to the se ond one). So thethree analyses be ome totally ordered by in reasing ost and pre ision.1 Introdu tionThe parallel-fun tional language Eden [2 extends the lazy fun tional languageHaskell by onstru ts to expli itly dene and ommuni ate pro esses. It is im-plemented by modifying the Glasgow Haskell Compiler (GHC) [13. The threemain new on epts are pro ess abstra tions, pro ess instantiations and the non-deterministi pro ess abstra tion merge. Pro ess abstra tions of type Pro ess ab an be ompared to fun tions of type a -> b, and pro ess instantiations an be ompared to fun tion appli ations. An instantiation is a hieved by using the pre-dened inx operator (#) :: Pro ess a b -> a -> b. Ea h time an expressione1 # e2 is evaluated, a new parallel pro ess is reated to evaluate (e1 e2). Non-determinism is introdu ed in Eden by means of a predened pro ess abstra tionmerge :: Pro ess [[a [a whi h fairly interleaves a set of input lists, to pro-du e a single non-deterministi list. The presen e of non-determinism reatessome problems [11 in Eden: It ae ts the referential transparen y of programs[8, 16 and invalidates some optimizations done in the GHC [15.The paper ompares three analyses to determine when an Eden expression issure to be deterministi , and when it may be non-deterministi . This work is a ontinuation of [11 and [10. In [11, the rst and se ond analyses were presentedand ompared with respe t to expressiveness and eÆ ien y. In that paper someopen questions were left whi h are extensively treated here: (1) to omplete these ond analysis with polymorphism; (2) to prove that the domains in the se ondanalysis form a ategory in whi h the morphisms are embedding- losure pairs offun tions, respe tively alled abstra tion and on retisation fun tions; and (3) to

Page 271: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

264 R. Pe~na, C. Seguraprove that the rst analysis is a safe approximation to the se ond one, i.e. when-ever it hara terizes an expression as being deterministi , so will do the se ondone. In the se ond paper [10, a third, intermediate analysis was developed as awidening [4, 5, 7, 14 of the se ond one in order to have a less ostly representationof fun tions and to speedup the xpoint omputation. There, it was proved thatthis new analysis is a safe approximation to the se ond one. It also des ribed analgorithm to annotate the program expressions with non-determinism informa-tion, so that it an be used to avoid the harmful transformations.The plan of the paper is as follows: In Se tion 2 the language and the threeanalyses are brie y summarized. All of them are based on abstra t interpretation.In Se tion 3 the properties of the abstra tion- on retisation fun tion pairs areproved. In Se tion 4 polymorphism in the se ond and third analysis is treatedin detail. Se tion 5 shows that the rst one is a safe approximation to the thirdone. Finally, some on lusions and open questions are drawn. All the proofs anbe found in [10, available at authors' web page.2 Three Analyses for Non determinism in Eden2.1 The LanguageThe language being analysed is an extension of Core-Haskell [13, i.e. a simplefun tional language with se ond-order polymorphism, so it in ludes type ab-stra tion and type appli ation. A program is a list of possibly re ursive bindingsfrom variables to expressions. Su h expressions in lude variables v, lambda ab-stra tions, appli ations of a fun tional expression to an atom x (a variable ora literal k), onstru tor appli ations, primitive operators appli ations, and aseand let expressions. Constru tor and primitive operators appli ations are satu-rated. The variables ontain type information, so we will not write it expli itlyin the expressions. When ne essary we will write e :: t to make it expli it. A typemay be a basi type K, a tuple typle (t1; : : : ; tm), an algebrai type T t1 : : : tm,a fun tional type t1 ! t2 or a polymorphi type 8:t.The new Eden expressions are a pro ess abstra tion pro ess v ! e, and apro ess instantiation v # x. There is also a new type Pro ess t1 t2 representingthe type of a pro ess abstra tion pro ess v ! e where v has type t1 and e hastype t2. Frequently t1 and t2 are tuple types and ea h tuple element representsan input/output hannel of the pro ess.2.2 The First AnalysisFigure 2 shows the abstra t domains for the rst analysis. There is a domainBasi with two values: d represents determinism and n possible non-determinism,with the ordering d v n. This is the abstra t domain orresponding to basi typesand algebrai types (ex ept tuples). Tuples are spe ially treated as tuples of basi abstra t values1 (see [11 for justi ation). The ordering between basi values isnaturally extended to tuples. Several least upper bound (lub) operators as well1 We use b to denote a basi abstra t value and a to denote either a basi value or atuple of basi values.

Page 272: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Comparison between three Non-determinism Analyses in ... 265Basi = fd; ng where d v nD1K = D1T t1:::tm = D1 = Basi D1(t1;:::;tm) = f(b1; : : : ; bm) j bi 2 Basi gD1t1!t2 = D1Pro ess t1 t2 = D1t2D18:t = D1tFig. 1. Abstra t domains for the rst analysist : Basi ! D1tb(t1;:::;tm) = (1b; : : : ;mb)bt1!t2 = bPro ess t1 t2 = bt2b8:t = btbt = b if t = K; ; T t1 : : : tm n t b = n btb = bd t b = b bt(b1; : : : ; bm) = Fi bib t (b1; : : : ; bm) = (b1 t b; : : : ; bm t b)Fig. 2. Adaptation fun tion denition, lub and attening operatorsas an operator to atten the internal tuples an be dened, shown in Figure 2.The domains orresponding to fun tions and pro esses are identied with theirrange domains (this is the most important dieren e with the se ond analysis).The abstra t domain of a polymorphi type is that of its smallest instan e [1,i.e. that one in whi h K is substituted for the type variable. So the domain orresponding to a type variable is Basi .In Figure 3 the abstra t interpretation is shown. The interpretation of a tupleis a tuple of basi abstra t values, so the abstra t value of ea h omponent ispreviously attened (by using bt). In the interpretation of a onstru ted value,we take a step further: On e the omponents are attened, the lub is appliedso that a nal basi value is obtained. This means that the information aboutthe omponents is lost. As merge pro ess is the only sour e of non-determinism,we will say that an expression may be non-deterministi when it ` ontains' anyinstantiation of this pro ess. So we will onsider that a fun tion/pro ess is de-terministi if it does not generate non-deterministi results from deterministi arguments. Then, the interpretation of a fun tion/pro ess is the interpretationof its body when the argument is given a deterministi abstra t value.Su h value is in fa t an adaptation of the basi abstra t value d to the type ofthe argument, see Figure 2. Given a type t, t takes a basi abstra t value b andprodu es an abstra t value in D1t. Its behaviour is the opposite to the atteningoperator: If t is a m-tuple, it repli ates b to obtain the m-tuple (b; : : : ; b). Notethat btbt = b and (bta)t w a.The result of an appli ation is non-deterministi either when the fun tion isnon-deterministi or when the argument is non-deterministi .In the re ursive let expression, the xpoint an be obtained by using theKleene's as ending hain. The number of iterations is linear with the number oftuple omponents in the bindings.We have three dierent kinds of ase expressions (for tuple, algebrai andprimitive types). The more omplex one is the algebrai ase. It is non-determi-nisti if either the dis riminant expression or any of the expressions in the alter-natives is non-deterministi . Note that the abstra t value of the dis riminant e,

Page 273: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

266 R. Pe~na, C. Segura[[v1 1 = 1 v[[k1 1 = d[[(x1; : : : ; xm)1 1 = (bt([[x11 1); : : : ; bt([[xm1 1))[[C x1 : : : xm1 1 = Fi bt([[xi1 1)[[e x1 1 = (bt([[x1 1)) t [[e1 1[[op x1 : : : xm1 1 = (Fi bt([[xi1 1))t where op :: t1 ! (t2 ! : : : (tm ! t))[[p#x1 1 = bt([[x1 1) t [[p1 1[[v:e1 1 = [[e1 1 [v 7! dt where v :: t[[pro ess v ! e1 1 = [[e1 1 [v 7! dt where v :: t[[merge 1 1 = n[[let v = e in e01 1 = [[e01 1 [v 7! [[e1 1[[let re fvi = eig in e01 1 = [[e01 (x (01:1 [vi 7! [[ei1 01))[[ ase e of (v1; : : : ; vm)! e01 1 = [[e01 1 [vi 7! i([[e1 1)ti where vi :: ti[[ ase e of Ci vij ! ei1 1 = b t (Fi [[ei1 1i)where b = [[e1 1 and 1i = 1 [vij 7! btij ; vij :: tij[[ ase e of ki ! ei1 1 = [[e1 1 t (Fi [[ei1 1)[[:e1 1 = [[e1 1[[e t1 1 = ([[e1 1)tinst where (e t) :: tinstFig. 3. Abstra t interpretation of the rst analysislet us all it b, belongs to Basi . That is, when it was interpreted the informa-tion about the omponents was lost. We want now to interpret ea h alternative'sright hand side in an extended environment with abstra t values for the variablesvij :: tij in the left hand side of the alternative. We do not have su h information,but we an safely approximate it by using the adaptation fun tion, see Figure 2.When a type appli ation e t is interpreted, it is ne essary to adapt the ab-stra t value of the type abstra tion to the instantiated type, as new stru turemay arise from the instantiation. If no new stru ture arises (i.e. the domain or-responding to the smallest instan e is already a artesian produ t), then we donot need to make any adaptation. So, by overloading the adaptation fun tionnotation, we ould write (b1; : : : ; bm)(t1;:::;tm) = (b1; : : : ; bm).2.3 The Se ond AnalysisTo over ome the limitations of the rst analysis (see [11 for a thorough dis ussionand an example) we dene a new analysis where interpreting fun tions andpro esses as abstra t fun tions allows us to express several levels of determinismand non-determinism, for instan e z:d v z:z v z:n. It is also an abstra tinterpretation based analysis, in the style of Burn, Hankin and Abramsky [3.In gures 4 and 5 the abstra t domains and the abstra t interpretation forthe se ond analysis are shown. The interpretation of a onstru tor belongs toBasi but, as ea h omponent xi :: ti has an abstra t value belonging to D2ti ,we annot dire tly apply the lub. First the information of ea h omponent must

Page 274: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Comparison between three Non-determinism Analyses in ... 267Basi = fd; ng where d v nD2K = D2T t1:::tm = Basi D2(t1;:::;tm) = D2t1 : : :D2tmD2t1!t2 = D2Pro ess t1 t2 = [D2t1 ! D2t2 Fig. 4. Abstra t domains for the se ond analysis[[v2 2 = 2(v)[[k2 2 = d[[(x1; : : : ; xm)2 2 = ([[x12 2; : : : ; [[xm2 2)[[C x1 : : : xm2 2 = Fi ti([[xi2 2) where xi :: ti[[e x2 2 = ([[e2 2) ([[x2 2)[[op x1 : : : xm2 2 = ( top(d)) ([[x12 2) : : : ([[xm2 2) where op :: top[[p#x2 2 = ([[p2 2) ([[x2 2)[[v:e2 2 = z 2 D2tv :[[e2 2 [v 7! z where v :: tv[[pro ess v ! e2 2 = z 2 D2tv :[[e2 2 [v 7! z[[merge 2 2 = z 2 Basi :n[[let v = e in e02 2 = [[e02 2 [v 7! [[e2 2[[let re fvi = eig in e02 2 = [[e02 (x (02:2 [vi 7! [[ei2 02))[[ ase e of (v1; : : : ; vm)! e02 2 = [[e02 2 [vi 7! i([[e2 2)[[ ase e of Ci vij ! ei2 2 = ( t(n) if [[e2 2 = nFi [[ei2 2i otherwisewhere 2i = 2 [vij 7! tij (d); vij :: tij ; ei :: t[[ ase e of ki ! ei2 2 = ( t(n) if [[e2 2 = nFi [[ei2 2 otherwisewhere ei :: tFig. 5. Abstra t interpretation for the se ond analysisbe attened. The fun tion responsible for this is alled the abstra tion fun tiont : D2t ! Basi , dened in the following se tion.Appli ation and pro ess instantiation are interpreted as fun tions appli a-tions. In a re ursive let expression the xpoint an be al ulated using againKleene's as ending hain. As there are fun tional domains, the number of itera-tions is, in the worst ase, exponential in the number of bindings.In the algebrai ase expression we again nd a safe representative of thedis riminant's abstra t value in the domain of the variables vij , now D2tij . Thisis obtained with a fun tion t : Basi ! D2t, alled the on retisation fun tion.In parti ular, n is mapped to the top of the domain D2t, and d to a value inD2t that re e ts our original idea of determinism: We will see below that t(d)is the biggest value in D2t that has the property of preserving the determinism.Polymorphism will be treated in Se tion 4.2.4 The Third AnalysisThe high ost of [[2 is due to the xpoint al ulation. At ea h iteration, a om-parison between abstra t values is done. Su h omparison is exponential in ase

Page 275: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

268 R. Pe~na, C. Segurafun tional domains are involved. So, a good way of speeding up the al ula-tion of the xpoint is nding a qui kly omparable representation of fun tions.Some dierent te hniques have been developed in this dire tion, su h as fron-tiers algorithms [12 and widening/narrowing operators [4, 7, 14. In this analysis,fun tions are represented by signatures in a way similar to [14 and the xpoint al ulation is speeded up by using a widening operator, see Figure 6.Three (not shown) useful fun tions, nArgs, rType and aTypes an be dened.Given a type t, the rst one returns the number of arguments of t; the se ondone returns the (non-fun tional) type of its result (it is the identity in the restof ases); and the third one returns the list (of length nArgs(t)) of types of thearguments.A signature for a fun tion is obtained by probing su h fun tion with some ex-pli itly hosen ombinations of arguments. We probe a fun tion of m argumentswith m+1 ombinations of arguments: t1(n); t2(d); : : : ; tm(d); t1(d); t2(n);: : : ; tm(d); . . . ; t1(d); t2(d); : : : ; tm(n) and t1(d); t2(d); : : : ; tm(d). The last ombination is very important for us, as we want the analysis to be more pow-erful than [[1, where the fun tions were probed with only this ombination.As we probe only with some arguments, dierent fun tions may have the samesignature and onsequently some information is lost, see [10 for details. Whenwe want to re over the original value, we an only return an upper approximationto it. This leads us to the denition of the operator Wt : D2t ! D2t, in Figure6. This denition is obtained by applying rst the probing pro ess to obtain asignature and then trying to re over the original value. In [10 we prove thatWt w idD2t for ea h type t.The abstra t domains for this third analysis are the same as the domains forthe se ond analysis, see Figure 4. The representation of fun tions by signaturesis only done in the xpoint al ulation and the details an be found in theimplementation algorithm shown in [10. We will use a 3 unders ript to identifyit. The only expression where there are dieren es with respe t to the se ondanalysis is the re ursive let expression:[[let re fvi = eig in e03 3 = [[e03 (x (03:3 [vi 7! Wti([[ei3 03)))where ei :: ti. In [10 it is shown that the ost of xpointing a re ursive fun tiondenition f = v1 : : : vm:e with this analysis, in luding the omplete annotationof the body e, is in O(m2size(e)), being m the number of arguments and size(e)(roughly speaking) the size of the denition body.Noti e that, by modifying the widening operator, we an have several dierentvariants of the analysis. We an express them parameterised by the ( olle tionof) widening operator wopt, [[3wop.3 Abstra tion and Con retisation Fun tionsThe ontributions of this paper begin in this se tion2. In the se ond and thirdanalyses, and for ea h type t, we need two fun tions alled the abstra tion fun -tion, t, and the on retisation fun tion, t, both dened in Figure 7. They are2 All the results obtained in this se tion remain true after in luding polymorphism.

Page 276: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Comparison between three Non-determinism Analyses in ... 269Wt :: D2t ! D2tWK =WT t1:::tm =W = idBasi W(t1;:::;tm)(e1; : : : ; em) = (Wt1(e1); : : : ;Wtm(em))W8:t =WtWt(f) = z1 2 D2t1 : : : : :zm 2 D2tm :8>>>><>>>>:Wtr(f t1(d) : : : tm(d)) if mi=1zi v ti(d)Wtr(f t1(d) : : : ti(n) : : : tm(d)) if ^j=1;j 6=izj v tj (d) ^ zi 6v ti(d) i 2 f1::mg tr (n) otherwise (m > 1)where t = t01 ! t02 or Pro ess t01 t02; m = nArgs(t); tr = rType(t); [t1; : : : ; tm = aTypes(t)Fig. 6. The widening operatort : D2t ! Basi K = T t1:::tm = = idBasi (t1;:::;tm)(e1; : : : ; em) = Fi ti(ei)Pro ess t1 t2(f) = t1!t2(f)t1!t2(f) = t2(f( t1(d)))8:t = t t : Basi ! D2t K = T t1:::tm = = idBasi (t1;:::;tm)(b) = ( t1(b); : : : ; tm(b)) Pro ess t1 t2(b) = t1!t2(b) t1!t2(b) = z 2 D2t1 : t2(n) if b = nz 2 D2t1 : t2(t1(z)) if b = d 8:t = tFig. 7. Abstra tion and on retisation fun tion denitionsmutually re ursive and are respe tively used in onstru tor appli ations and in ase expressions. In [11 they were explained in detail and an example was givento illustrate their denitions. Here we only re all the main ideas. Given a type t,the abstra tion fun tion takes an abstra t value in D2t and attens it to a valuein Basi . The idea is to atten the tuples (by applying the lub operator) andapply the fun tions to deterministi arguments.Given a type t, the on retisation fun tion t un attens a basi abstra t valueand produ es an abstra t value in D2t. The idea of this fun tion is to obtainthe best safe approximation both to d and n in a given domain. The fun tiontype needs explanation, the rest of them being inmediate. We have said that afun tion is deterministi if it produ es deterministi results from deterministi arguments; but if the argument is non-deterministi , the safest we an produ eis a non-deterministi result. So, the un attening of d for a fun tion type is afun tion that takes an argument, attens it to see whether it is deterministi ornot and again applies the on retisation fun tion orresponding to the type ofthe result. The un attening of n for a fun tion type is the fun tion that returnsa non-deterministi result independently of the argument.The rst ontributions of this paper are to prove that t and t are a Galoisinsertion [9, or equivalently a Galois surje tion [6, or an embedding- losure pair3[1 (see Proposition 1), and also that t1!t2(d) faithfully re e ts the notion ofdeterministi fun tion (see Proposition 3).In the following proposition we prove that t and t are monotone and on-tinuous, and that they are a Galois insertion. This fa t guarantees that in the3 Where t is the embedding and t is the losure.

Page 277: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

270 R. Pe~na, C. SeguraD2 = Basi D28:t = D2t i 2 f2; 3g[[:ei i = [[ei i[[e ti i = t0tinst ([[ei i) where e :: 8:t0; tinst = t0[ := tFig. 8. Abstra t domains and abstra t interpretation for polymorphisminterpretation of ase expressions, the information re overed from the dis rimi-nant is not only safe but also the best we an obtain onsidering how its abstra -tion was done (giving a non-deterministi abstra t value to ea h variable in thealternative is also safe, but less a urate). Item 1(d) says that the un atteningof n is the top of the orresponding domain.Proposition 1 For ea h type t:(a) The fun tions t and t are monotone and ontinuous.(b) t t = idBasi ( ) t t w idD2t(d) 8e 2 D2t:e v t(n)As a dire t onsequen e of this proposition, we have the following (quitestandard) one, asserting that all the values below t(d) are attened to d. Thatis, t(d) represents d. But it also says that any other value, bigger that t(d) orin omparable with it, is attened to n. This onrms that t(d) is the biggestvalue representing d.Proposition 2 For ea h type t: 8e 2 D2t:e v t(d), t(e) = dA fun tion/pro ess is onsidered as deterministi if when applied to a de-terministi argument its result is also deterministi . This means that, when afun tion (resp. pro ess) of type t1 ! t2 (resp. Pro ess t1 t2) is applied to a valueless than or equal to t1(d), the result is less than or equal to t2(d). The follow-ing proposition says that a fun tion of type t1 ! t2 is deterministi if and onlyif it is less than or equal to t1!t2(d), i.e. t1!t2(d) is the biggest representativeof the deterministi fun tions of that type. The same happens for pro esses.Proposition 3 Given a fun tion f 2 D2t, where t = t1 ! t2 or t = Pro ess t1 t2:f v t(d), 8e v t1(d):f(e) v t2(d)4 PolymorphismPolymorphism is now in orporated to both se ond and third analyses, see Fig-ure 8. The abstra t interpretation of a polymorphi expression is the abstra tinterpretation of its `smallest instan e', i.e. that instan e where K (the basi type) is substituted for the type variables. This is the reason why the abstra tdomain orresponding to a type variable is Basi , and the abstra t domain orresponding to a polymorphi type is that of the type without qualier. Whenan appli ation to a type t is done, the abstra t value of the appropriate instan e

Page 278: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Comparison between three Non-determinism Analyses in ... 271t0 = K;T t1 : : : tm ( t0tinst ; tinst t0) = (idBasi ; idBasi )t0 = (t1; : : : ; tm) ( t0tinst ; tinst t0) = m(( t1tinst1 ; tinst1 t1); : : : ; ( tmtinstm ; tinstm tm))t0 = t1 ! t2 ( t0tinst ; tinst t0) = ! (( t1tinst1 ; tinst1 t1 ); ( t2tinst2 ; tinst2 t2))t0 = Pro ess t1 t2 ( t0tinst ; tinst t0) = ! (( t1tinst1 ; tinst1 t1 ); ( t2tinst2 ; tinst2 t2))t0 = ( t0tinst ; tinst t0) = ( t; t)t0 = 0 ( 6= ) ( t0tinst ; tinst t0) = (idBasi ; idBasi )t0 = 80:t1 ( t0tinst ; tinst t0) = ( t1tinst1 ; tinst1 t1 )((fe; f ); (ge; g )) = (fe ge; f g )! ((fe; f ); (ge; g )) = (h:ge h f ; h0:g h0 fe)Fig. 9. Polymorphi abstra tion and on retisation fun tions denitionsp 2 Fp tinst1 t1(p) f (tinst1 t1(p)) t2tinst2(f (tinst1 t1(p)))(z 2 Basi :d; z 2 Basi :d) (d; d) d u 2 Basi :u(z 2 Basi :d; z 2 Basi :z) (d; d) d u 2 Basi :u(z 2 Basi :d; z 2 Basi :n) (d; n) d u 2 Basi :u(z 2 Basi :z; z 2 Basi :d) (d; d) d u 2 Basi :u(z 2 Basi :z; z 2 Basi :z) (d; d) d u 2 Basi :u(z 2 Basi :z; z 2 Basi :n) (d; n) d u 2 Basi :u(z 2 Basi :n; z 2 Basi :d) (n; d) n u 2 Basi :n(z 2 Basi :n; z 2 Basi :z) (n; d) n u 2 Basi :n(z 2 Basi :n; z 2 Basi :n) (n; n) n u 2 Basi :nFig. 10. An example of polymorphismmust be obtained. Su h abstra t value is in fa t obtained as an approximation onstru ted from the abstra t value of the smallest instan e. From now on, theinstantiated type t0[ := t will be denoted as tinst. The approximation to theinstan e abstra t value is obtained by using a polymorphi on retisation fun ion t0tinst : D2t0 ! D2tinst , whi h is dened and studied in detail below. Anotherfun tion, tinst t0 : D2tinst ! D2t0 , whi h we will all the polymorphi abstra tionfun tion, will also be dened. They are mutually re ursive and will be shown tobe a Galois insertion. We study also some other properties.Given two types t, t0 and a type variable fun tions t0tinst and tinst t0 areformally dened in Figure 9 (where tinst i denotes ti[ := t). These fun tionsare a generalisation of t and t. In ase t0 = they oin ide with t and t.In [1 the ategory of domains and embedding- losure pairs is presented.Two fun tors, (and m) and !, an be dened in this ategory (see Figure9 bottom). They build a new embedding- losure pair from two (or more in the ase of the artesian produ t) embedding- losure pairs. We dene t0tinst andtinst t0 by means of these fun tors.As an example, let the polymorphi type 8:t0, where t0 = (; ) ! , beapplied to the type t = Int ! Int. Then tinst = t0[t= = (Int ! Int; Int !Int) ! Int ! Int. To abbreviate, we will all Ep to Basi Basi and Fp to[Basi ! Basi [Basi ! Basi . Let f 2 D2t0 be f = p 2 Ep:1(p). Bydenition we have that t0tinst (f) = p 2 Fp: t2tinst2(f (tinst1 t1(p))). Figure 10shows a table for t0tinst (f) and the intermediate steps that have been followedto ompute it. The following proposition is trivially true by denition.

Page 279: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

272 R. Pe~na, C. Segura DtinstDt0 Basi t0 t0 t0tinsttinst t0 tinst tinstFig. 11. Some onmutativity properties

[[2[[3Wb[[3W [[3W[[3Wd [[1Fig. 12. A hierar hy of analysesProposition 4 Given two types t, t0 and a type variable :(a) t0tinst and tinst t0 are monotone and ontinuous.(b) tinst t0 t0tinst = idD2t0( ) t0tinst tinst t0 w idD2tinstIn the following proposition we study the relationship between the abstra -tion/ on retisation fun tions and its polymorphi ounterparts. They have some onmutativity properties, shown in Figure 11.Proposition 5 Given two types t, t0 and a type variable :(a) t0tinst t0 = tinst ( ) tinst t0tinst = t0 (e) tinst t0 w t0tinst(b) t0 tinst t0 = tinst (d) tinst t0 tinst = t0 (f) t0 tinst w tinst t0A generalization of the pair ( t0tinst ; tinst t0) an be dened, where sev-eral type variables are instantiated in sequen e. This orresponds to a type81: : : : :8m:t0 and an instantiation tinst = t0[1 := t1; : : : ; m := tm. Theanalysis domains together with these pairs as morphisms form a ategory (bypropositions 5(a) and 5(b)).5 Relation between the AnalysesIn [10 the relation between the se ond and the third analyses was studied. There,it was shown that all variants of the third analysis produ es less a urate resultsthan the se ond one:Proposition 6 Let W 0t : D2t ! D2t be a widening operator for ea h type t.Given 2 and 3 su h that for ea h variable v :: tv 2(v) v 3(v), then for ea hexpression e :: te, [[e2 2 v [[e3W03.In this se tion the relation between the rst analysis and the other two anal-yses is studied. Grosso modo we will see that the rst analysis is worse thansome variants of the third analysis, but in a safe way, that is, it is a safe ap-proximation to them. In parti ular we will prove that the rst analysis is an

Page 280: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Comparison between three Non-determinism Analyses in ... 273e = let re f = p:x: ase p of(p1; p2)! ase p2 of0! (p1; x)z ! (f (p1 p1; p2 1)) (x p2)in letf1 = (f (q; 3)) 4f2 = (f (1; 2)) qx1 = ase f1 of (f11; f12)! f12x2 = ase f2 of (f21; f22)! f21in (x1; x2)[[e1 [q 7! n = (n; n) = [[e3W [q 7! n = (n; d) = [[e2 [q 7! n = (d; d)Fig. 13. Dieren es in power between the analysesupper aproximation to those variants of the third analysis that fulll a prop-erty (see Theorem 14). We will prove that the parti ular widening operator Wtdened in Figure 6 fullls su h property. In [10 we mentioned other possiblewidening operators that ould be dened (Wb, W and Wd) and their relationwith W . The main dieren e between them lies in their treatment of tuples inthe arguments and/or in the result of fun tions, either as indivisible entities oras omponentwise entities. As all the variants of the third analysis are upperapproximations to the se ond one, it will also happen that the rst analysis isan upper approximation to the se ond analysis. In Figure 12 we illustrate therelation between the rst analysis, the se ond analysis and some variants of thethird analysis. In [10 an example was given to show the dieren es in pre isionbetween [[1, [[2 and [[3W , also shown in Figure 13.In Figure 14 a s heme of the fun tions dened in this se tion and theirdenition domains are shown. Many propositions in this se tion an be easilyvisualized using this gure.In the rst analysis there are neither nested tuples nor abstra t fun tions.However, the abstra t value a of a fun tion in su h analysis represents an abstra tfun tion. It is a fun tion that takes an abstra t value as argument; if that valueis non-deterministi the result is also non-deterministi , and if it is deterministi it gives as result the abstra t value a. This leads us to dene a fun tion t, seeFigure 15 (left), alled the expansion fun tion that expands the abstra t valuesof the rst analysis domains into abstra t values belonging to the se ond andthird analyses abstra t domains. Re all also that in the rst analysis there areno nested tuples, so it will be ne essary to adapt ea h of the basi values to thetypes of the omponents.We an also look at the se ond and third analyses from the point of view ofthe rst one. We just have to atten the tuples up to the rst level and applythe fun tions to t(d), to obtain the behaviour of the fun tion when it is appliedto a deterministi argument. This is represented by the ompression fun tion Ætdened in Figure 15 (right). We prove now that Æt and t are a Galois insertion.

Page 281: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

274 R. Pe~na, C. SeguraD1t D2t D2t

Basi Æt rtbt t

Ættbt tFig. 14. Representative s heme of the fun tions in Se tion 5Proposition 7 For ea h type t:(a) The fun tions Æt and t are monotone and ontinuous.(b) Æt t = idD1t( ) t Æt w idD2tThe following proposition asserts that given an abstra t value in D2t, if weapply Æt to it to obtain a value in D1t and then we apply bt to the result (it ouldbe a tuple of basi abstra t values) we obtain the same basi value as applyingt dire tly to it. This shows a similarity between the abstra tion fun tion tused in onstru tor appli ations and the ompression fun tion Æt. In the end theideas are the same.Proposition 8 For ea h type t: bt Æt = tProposition 7 tells us that t Æt is a widening operator in D2t. This ompositionwill be widely used in the following, so we dene rt = t Æt. We will all it therising fun tion (just to dierentiate it from Wt).It also tells us that for ea h type t, the range of rt is isomorphi to D1t:rt(D2t) ' D1t. This means that the range ofrt is a subdomain of D2t where wehave lost the additional information provided by the se ond and third analyses.For example, we still have nested tuples, but they are maintained in a titiousway, that is, they have been attened up to the rst level and then un attenedagain. So, all the internal tuples will be formed by only n's or only d's. Forexample both ((n; d); d; (d; d)) and ((d; n); d; (d; d)) are transformed by rt into((n; n); d; (d; d)). We also have abstra t fun tions, but only some of them: Thosethat an be represented with an abstra t value in the rst analysis domains.These are the fun tions su h that for all values below t1(d), give the sameresult as the one obtained for t1(d), and for the rest of the values give as resultthe top of the orresponding domain, t2(n).Theorem 14 below asserts the orre tness of the rst analysis with respe t tothe third one, but rst we will see some more properties that are needed to proveit. The following proposition relates the adaptation fun tion of the rst analysisand the on retisation fun tion t. The are made equal through the appli ationof Æt.

Page 282: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Comparison between three Non-determinism Analyses in ... 275t : D1t ! D2tK = T t1:::tm = = idBasi (t1;:::;tm)(b1; : : : ; bm) = ( t1(b1); : : : ; tm(bm))t1!t2(a) = Pro ess t1 t2(a) =z 2 D2t1 : t2(a) if z v t1(d) t2(n) otherwise8:t = tÆt : D2t ! D1tÆT t1:::tm = Æ = idBasi Æ(t1;:::;tm)(e1; : : : ; em) =(t1(e1); : : : ; tm(em))Æt1!t2(f) = ÆPro ess t1 t2(f) =Æt2(f( t1(d)))Æ8:t = ÆtFig. 15. Expansion and ompression fun tionsProposition 9 For ea h type t: 8b 2 Basi : bt = (Æt t)(b)The following proposition relates the rising fun tion rt with the abstra tionand on retisation fun tions t and t. The rst two items tell us that on e wehave gone up in the domain with rt, the fun tions t and t behave in the sameway in the subdomain of D2t that is the range of rt, than in the whole domain.This means that in fa t t and t are moving inside this subdomain. In Figure14 this fa t is represented by two D2t domains en ir led by a dashed line, wheret and t appear between the range of rt and Basi .Proposition 10 For ea h type t: (a) trt = t (b) rt t = t ( ) rt v ttThe following proposition adds some results about the polymorphi fun tions.The rst one tells us that we obtain the same result if we adapt an abstra t valuebelonging to D2t0 to the type tinst and then rise the result than if we rst riseit and then adapt the result. The se ond one tells us that the adaptation ofan abstra t value in D1t0 to obtain an aproximation to the abstra t value ofan instan e tinst , is basi ally equal to the adaptation made with t0tinst in thedomains of the se ond and third analyses.Proposition 11 Given two types t, t0 and a type variable :(a) rtinst t0tinst = t0tinst rt0 (b) 8a 2 D1t0 : atinst = Ætinst ( t0tinst (t0 (a)))A very important and useful property to prove the orre tness is the semi-homomorphi property of Æt with respe t to the appli ation of a fun tion. Butas there are no fun tional domains in the rst analysis, the property holds withrespe t to the pseudoappli ation we use in su h domains, that is, the way inwhi h appli ation of a fun tion is interpreted: f(x) = (btx) t f (see Figure 3).Proposition 12 Let f 2 [D2t1 ! D2t2 , e 2 D2t1 . Then: Æt2(f(e)) v (btÆt1(e))t Æt1!t2(f)To prove the orollary of Theorem 14 we will need the following lemma.Lemma 13 For ea h type t: t(dt) = t(d)The following theorem establishes that the rst analysis is a safe (upper)approximation to the transformation by Æt of those variants of the third analysis[[3wop su h that Æt wopt = Æt

Page 283: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

276 R. Pe~na, C. SeguraTheorem 14 Let W 0t be a widening operator for ea h type t, su h that Æt W 0t =Æt. If for ea h variable v :: tv, 1(v) w Ætv(3(v)) then: 8e :: te: [[e1 1 wÆte([[e3W0 3). Or equivalently, 8e :: te: te([[e1 1) w rte([[e3W0 3)The theorem an be proved by stru tural indu tion on e and by propositions1(a), 1( ), 4(a), 7(a), 8, 9, 11 and 12.As a orollary, and by Lemma 13 and Proposition 7( ), we obtain the or-re tness of the rst analysis with respe t to these variants: If the rst analysistells us that an expression is deterministi then the orresponding variant ofthe third analysis also tell us that it is deterministi , probably with some addi-tional detail as the independen e of the output with respe t to the input in afun tion/pro ess.Corollary 15 LetW 0t be a widening operator for ea h type t, su h that Æt W 0t =Æt. If for ea h variable v :: tv, 1(v) w Ætv (3(v)) then: 8e :: te: [[e1 1 = dte )[[e3W0 3 v te(d)Proposition 16 asserts that the parti ular widening operator dened in Figure6 has this property (the widening operator Wb mentioned in [10 also fullls it)Proposition 16 For ea h type t, Æt Wt = Æt.The orre tness of the rst analysis with respe t to the se ond one is triviallyobtained from Theorem 14, as the se ond analysis is in fa t a variant of the thirdanalysis where the widening operator is the identity fun tion.6 Con lusionsWe have presented and formally ompared three non-determinism analyses fora fun tional language with se ond-order polymorphism and non-deterministi expressions. All of them are based on abstra t interpretation. We have provedinteresting properties of some attening and un attening fun tions whi h ap-pear when polymorphism is formally treated, and also have shown that the rstanalysis is a safe approximation to the se ond and the third ones.Although the main motivation for this work has been the orre t ompilationof our language Eden, everything presented here an be applied to any other non-deterministi polymorphi fun tional language. Related work on erning otherabstra t interpretation and type based analyses was already reported in previouspapers [11, 10. We have not found any previous analyses for this problem in theliterature.The rst paper on this subje t [11 presented our preliminary ideas in theform of two not ompletely satisfa tory analyses. The rst one was eÆ ient butnot powerful enough, while the se ond one was powerful but not pra ti al interms of eÆ ien y. The se ond paper [10 developed a third analysis that wasboth powerful enough and pra ti al in implementation terms. This paper haspresented the theoreti al results supporting the orre tness of that implemen-tation. For our purposes, this loses the initial problem. A proof of orre tness

Page 284: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Comparison between three Non-determinism Analyses in ... 277of the se ond analysis with respe t to the standard semanti s of the languageremains to be done. Unfortunately there is still no su h semanti s available forEden. Nevertheless, a simplied form of semanti s ould be used to prove partof the analysis orre tness.Referen es1. G. Baraki. Abstra t Interpretation of Polymorphi Higher-Order Fun tions. PhDthesis, University of Glasgow, Feb. 1993.2. S. Breitinger, R. Loogen, Y. Ortega Mallen, and R. Pe~na. Eden: Language Deni-tion and Operational Semanti s. Te hni al Report, Beri ht 96-10. Revised version1.998, Philipps-Universitat Marburg, Germany, 1998.3. G. L. Burn, C. L. Hankin, and S. Abramsky. The Theory of Stri tness Analysisfor Higher Order Fun tions. In Programs as Data Obje ts, volume 217 of LNCS,pages 4262. Springer-Verlag, O t. 1986.4. P. Cousot and R. Cousot. Abstra t interpretation: A unied latti e model forstati analysis of programs by onstru tion of approximation of xed points. InPro eedings of the 4th ACM Symposium on Prin iples of Programming Languages,pages 238252. ACM, 1977.5. P. Cousot and R. Cousot. Systemati design of program analysis frameworks. InConferen e Re ord of the 6th Annual ACM Symposium on Prin iples on Program-ming Languages, pages 269282. ACM, 1979.6. P. Cousot and R. Cousot. Abstra t interpretation frameworks. Journal of Logi and Computation, 2(4):511547, Aug. 1992.7. C. Hankin and S. Hunt. Approximate xed points in abstra t interpretation. InB. Krieg-Bru kner, editor, ESOP '92, 4th European Symposium on Programming,volume 582 of LNCS, pages 219232. Springer, Berlin, 1992.8. R. J. M. Hughes and J. O'Donnell. Expressing and Reasoning About Non-Deterministi Fun tional Programs. In Fun tional Programming: Pro eedings ofthe 1989 Glasgow Workshop, pages 308328. Springer-Verlag, 1990.9. F. Nielson, H. R. Nielson, and C. Hankin. Prin iples of Program Analysis. Springer-Verlag, 1999.10. R. Pe~na and C. Segura. Three Non-determinism Analyses in a Parallel-Fun tionalLanguage. Te hni al Report 117-01 (SIP). Universidad Complutense de Madrid,Spain, 2001. (http://dalila.sip.u m.es/miembros/ lara/publi ations.html).11. R. Pe~na and C. Segura. Non-Determinism Analysis in a Parallel-Fun tional Lan-guage. In 12th International Workshop on Implementation of Fun tional Lan-guages, IFL00, volume 2011 of LNCS, pages 118. Springer-Verlag, 2001.12. S. L. Peyton Jones and C. Cla k. Finding xpoints in abstra t interpretation.In S. Abramsky and C. Hankin, editors, Abstra t Interpretation of De larativeLanguages, hapter 11, pages 246265. Ellis-Horwood, 1987.13. S. L. Peyton Jones, C. V. Hall, K. Hammond, W. D. Partain, and P. L. Wadler.The Glasgow Haskell Compiler: A Te hni al Overview. In Joint Framework forInf. Te hnology, Keele, DTI/SERC, pages 249257, 1993.14. S. L. Peyton Jones and W. Partain. Measuring the ee tiveness of a simple stri t-ness analyser. In Glasgow Workshop on Fun tional Programming 1993, Workshopsin Computing, pages 201220. Springer-Verlag, 1993.15. S. L. Peyton Jones and A. L. M. Santos. A Transformation-based Optimiser forHaskell. S ien e of Computer Programming 32(1-3):3-47, September 1998.16. H. Sndergaard and P. Sestoft. Referential Transparen y, Deniteness and Unfold-ability. A ta Informati a, 27(6):505517, May 1990.

Page 285: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 286: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Sin roniza ion Multipro eso en ProgramasCon urrentes.Sele ion Completamente kjusta de Intera iones ?David Ruiz, Rafael Cor huelo, Jose A. Perez y Miguel ToroUniversidad de SevillaDepartamento de Lenguajes y Sistemas Informati osAvenida de la Reina Mer edes s/n, Sevilla, 41.012e-mail: druizlsi.us.esResumen La sele ion ompletamente justa surge en el ontexto de losprogramas no deterministas y sirve para garantizar que todos los elemen-tos que se habilitan innitamente a menudo se sele ionan innitamentea menudo. Esta no ion de sele ion presenta dos anomalas: la nitudjusta y las onspira iones. Este art ulo se entra en la sele ion justade intera iones y presenta una nueva no ion llamada sele ion omple-tamente kjusta uya prin ipal ventaja sobre otras propuestas es que dasolu ion a las dos anomalas de forma simultanea y que el valor de k sepuede estable er a priori para ara terizar su bondad. Para ello, hemosdes rito un modelo abstra to de intera ion que ha e independiente el riterio de sele ion del lenguaje de programa ion y que se puede a omo-dar a gran variedad de modelos de intera ion. Tambien presentamos unalgoritmo general para implementar la sele ion ompletamente kjustade intera iones que no requiere a eder al estado lo al de los pro esosdel sistema.Palabras lave: programa ion on urrente y distribuida, modelo abs-tra to de intera ion, a iones onjuntas, eventos ompartidos, ex lusionmutua, sele ion justa, onspira iones.1 Introdu ionLa sele ion justa surge en el ontexto de los programas uya eje u ion no esdeterminista para poder garantizar propiedades de integridad y de viveza [7en sus eje u iones. Este fa tor no determinista puede ser introdu ido por (i)lenguajes de programa ion no deterministas, por (ii) el entrelazado de odigo enlos programas on urrentes o por (iii) la ongura ion de la red en el aso deprogramas distribuidos.En la bibliografa no hemos en ontrado ninguna deni ion de justi ia queprevalez a sobre las otras, pero en el ontexto de los lenguajes de programa ion? Este trabajo esta subven ionado por la Comision Interministerial de Cien ia y Te -nologa: proye to GEOZOCO (TIC2000-1106-C02-01)

Page 287: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

280 D. Ruiz, R. Cor huelo, J. A. Perez, M. Toro

Page 288: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Sin roniza ion Multipro eso en Programas Con urrentes ... 281F1.fCoger1g, F2.fCoger2g,( T5.fCoger5 , Coger1g, T2.fCoger2 , Coger3g, T1.fCoger1 ,Coger2g, Coger1[,F1.fSoltar1g, T1.fSoltar1, Soltar2g, T5.fSoltar5, Soltar1g, Soltar1[, F1.fCoger1g )n(a)F1.fCoger1g, F2. fCoger2gF3.fCoger3g,( T5.fCoger5 , Coger1g, T3.fCoger3 , Coger4g, T1.fCoger1 , Coger2g, Coger1[,T2.fCoger2 , Coger3g, Coger3[, F1.fSoltar1g, T1.fSoltar1, Soltar2g,T5.fSoltar5, Soltar1g, Soltar1[, F3.fSoltar3g, T2.fSoltar2, Soltar3g,T3.fSoltar3, Soltar4g, Soltar3[, F1.fCoger1g,F3.fCoger3g )!(b)Figura 2. Anomalas de la sele ion ompletamente justa de intera iones.Estas anomalas han sido estudiadas por varios autores dando lugar a nuevos riterios de sele ion mas restri tivos. Entre ellos desta aremos: la sele ion justanita [1 y la sele ion hiperjusta [2.La sele ion justa nita intenta paliar el primer problema. Para ello lo queha e es sustituir el termino \innitamente a menudo" de la deni ion por \almenos una vez ada k ve es" siendo k un natural des ono ido a priori. Lasprin ipales desventajas de esta propuesta es que (i) el valor de k se ono e aposteriori, (ii) que no resuelve el problema de la nitud y las onspira iones, (iii)no hemos en ontrado ningun algoritmo para implementarla2.La sele ion hiperjusta surge omo respuesta al problema de las onspira- iones. Se di e que una eje u ion hiperjusta uando es nita o toda intera ionque puede habilitarse innitamente a menudo lo ha e innitamente a menudo.Con esta no ion se pretende garantizar la habilita ion de las intera iones y nola sele ion de las mismas, por lo que se ha e ne esario ombinarla on otrano ion de sele ion de intera iones. Sus prin ipales desventajas son que (i) noresuelve el problema de la nitud y (ii) no se ono e ningun algoritmo generalpara implementarla3.Nosotros proponemos una nueva no ion para resolver simultaneamente lasdos anomalas presentadas: la sele ion ompletamente kjusta. Una eje u ionsera ompletamente kjusta uando ninguna intera ion se eje uta mas de kve es sin ono er el estado denitivo de las intera iones on las que tiene queobtener la ex lusion mutua y ademas uando se sele iona es la intera ion masantigua del grupo (este on epto lo deniremos mas adelante).Nuestra no ion esta denida sobre un modelo de intera ion abstra to ba-sado en el on epto de a ion onjunta que abar a a modelos de intera ion dealto nivel ( omo el de multiples parti ipantes) hasta modelos de intera ion mas2 Los autores proponen un esquema de transforma ion que puede ser apli ado a pro-gramas expresados on automatas de Bu hi [10,5.3 Los autores proponen un esquema de transforma ion de programas IP que impli amodi a ion del odigo de los pro esos y la existen ia de gestores a medida para ada programa.

Page 289: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

282 D. Ruiz, R. Cor huelo, J. A. Perez, M. Toroprimitivos omo el paso de mensajes o el rendezvous [8. Con este modelo deintera ion onseguimos ha er independiente el lenguaje de programa ion del riterio de sele ion que se adopte. Por ultimo, presentamos un algoritmo ge-neral para implementar nuestra no ion que no ne esita a eder al estado de lospro esos.2 Modelo abstra to de intera ionEntenderemos que nuestros programas on urrentes y/o distribuidos estaran for-mado por un onjunto jo no va o de pro esos y un onjunto jo no va ode a iones onjuntas (en adelante intera iones) entre di hos pro esos. Todopro eso puede parti ipar durante su eje u ion en un onjunto jo no va o deintera iones.Los pro esos se eje utaran de forma on urrente (real o simulada) y en adainstante de tiempo solo podran eje utar una intera ion, es de ir, suponemosque los pro esos solo tienen un uni o hilo de eje u ion. El uni o me anismo quese propor iona para sin ronizar pro esos distintos son las intera iones, es de ir,los pro esos no omparten variables ni se envan mensajes entre ellos.Los pro esos se pueden en ontrar en tres estados distintos:Realizando al ulos lo ales: Cuando un pro eso se en uentra en di ho esta-do solo podra eje utar a iones sobre su estado lo al, es de ir, a iones queno requieren intera tuar on otros pro esos para llevar a abo ninguna tarea.Esperando intera tuar on otros pro esos: Cuando un pro eso se en uen-tra en este estado diremos que esta ofre iendo un onjunto de intera ionesy que se en uentra bloqueado a la espera de que alguna ellas se habilite yresulte sele ionada para ser eje utada.Finalizado: Un pro eso se en uentra en este estado uando termina su eje u- ion. En realidad lo que a nosotros nos interesa es que un pro eso que seen uentra en este estado no puede ofre er (ni eje utar) ninguna intera ionen el futuro ni tampo o efe tuar al ulos lo ales.La vida de un pro eso puede des ribirse on la siguiente expresion regular:p :: (p:jp:; x); p:; (1)Donde p: representa la eje u ion de al ulos lo ales, p: el ofre imiento de un onjunto 6= ; de intera iones, x la sin roniza ion a traves de una intera ionx 2 y p:; el evento de termina ion de p.Las intera iones (a iones onjuntas sn ronas entre un numero arbitrarioy jo de pro esos) solo se eje utan uando todos los pro esos que pueden ofre- erla lo han he ho. Cuando dos o mas intera iones pueden ser ofre idas porlos mismos pro esos, es de ir, tienen algun parti ipante en omun diremos queson poten ialmente on i tivas. Cuando dos o mas intera iones que son poten- ialmente on i tivas se en uentran habilitadas el mismo tiempo diremos quese ha produ ido un on i to y se tendra que de idir que intera ion eje utar y

Page 290: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Sin roniza ion Multipro eso en Programas Con urrentes ... 283re hazar el resto, ya que omo hemos di ho los pro esos solo tienen un uni o hilode eje u ion.De esta forma, entenderemos que la eje u ion de un programa es la se uen iade ofre imiento de intera ion/eje u ion de intera ion que provo a el ambiode estado en el mismo. Es de ir, asumimos que los al ulos lo ales que realizanlos pro esos no son visibles durante la eje u ion.2.1 Des rip ion detalladaA ontinua ion haremos algunas deni iones para introdu ir todos estos on- eptos de forma pre isa. Tomaremos omo ejemplo para poder ilustrar estasdeni iones el ejemplo de los losofos omensales visto en la gura 1.Modelo de los sistemasSistema: Un sistema se dene omo la la tupla (P ; I). P 6= ; es un onjunto nito de pro esos ( on un uni o hilo de eje u ion y un estado lo alindependiente) e I 6= ; es un onjunto nito de intera iones que permitensin ronizar y omuni ar a un numero arbitrario y jo de pro esos de P .Parti ipantes de una intera ion: Dada intera ion x 2 I se dene un onjunto estati o de pro esos P(x) P que estara formado por todos lospro esos a los que x puede sin ronizar.Intera iones de un pro eso: Todo pro eso p 2 P dene un onjunto tam-bien estati o de intera iones I(p) I de forma que solo se podra sin ro-nizar y omuni ar on otros pro esos a traves de estas intera iones.Congura ion: Una ongura ion es una estru tura matemati a que denotael estado en el que se en uentra la eje u ion un programa en un instan-te determinado. Generalmente las ongura iones in luyen el estado de lospro esos y alguna informa ion de ontrol adi ional. Las denotaremos onC;C 0; C1; C2; et .Eventos: Las transi iones entre ongura iones de un sistema vienen dadas poreventos. Nuestro modelo dene tres eventos: p: uando el pro eso p eje utauna instru ion lo al, p: uando el pro eso p ofre e intera ion en algunaintera ion x 2 y x uando el sistema eje uta la intera ion x.Eje u ion: Se dene una eje u ion de un sistema omo la tupla (C0; ; ),donde C0 es la ongura ion ini ial, = [C1; C2; : : : es una se uen ia ma-ximal (nita o innita) de ongura iones y = [e1; e2; : : : tambien es unase uen ia maximal (nita o innita) de eventos, donde ei ara teriza la tran-si ion entre las ongura iones Ci1 y Ci (i 1).Traza: Sea = (C0; ; ) una eje u ion de un programa . Denotaremos omo (traza de ongura iones) y omo (traza de eventos).Semanti a: Asumiremos que nuestros programas han sido es ritos en un len-guaje L uya semanti a operativa esta denida por la regla de transi ione L , donde e es un evento del sistema. Dada una eje u ion = (C0; ; )tambien la es ribiremos de la siguiente forma:C0 e1L C1 e2L C2 e3L (2)

Page 291: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

284 D. Ruiz, R. Cor huelo, J. A. Perez, M. ToroModelo de los pro esosOfre imiento de intera ion: Un pro eso p estara ofre iendo la intera ionx en la ongura ion iesima de su eje u ion si o solo si llega a un punto enel que la eje u ion de la intera ion x se una posible ontinua ion.Readies(; p; x; i) sii91 k i ((k) = p: ^ x 2 ^ k < j i (j) = z ^ z 2 ) (3)Esperando intera tuar: Un pro eso p estara esterando intera tuar en la on-gura ion iesima de una eje u ion si y solo si esta ofre iendo algunaintera ion. Waiting(; p; i) sii 9x 2 I Readies(; p; x; i) (4)Pro eso nalizado: Un pro eso p habra nalizado su eje u ion en la ongu-ra ion iesima de su eje u ion si y solo si ya no puede volver a eje utar ni al ulos lo ales ni intera ion.Finished(; p; i) sii 91 k i (k) = p:; (5)Modelo de las intera ionesIntera iones enlazadas: El onjunto de intera ion enlazadas a la intera - ion x en la ongura ion iesima de la eje u ion estara formado poraquellas intera iones que han sido ofre idas por pro esos omunes.Linked(; x; i) =fy 2 I j y 6= x ^ 9p 2 P (Readies(; p; x; i) ^Readies(; p; y; i))g (6)Intera iones habilitadas: Una intera ion x estara habilitada en la ongu-ra ion iesima de la eje u ion si y solo si todos los pro esos de P(x) laestan ofre iendo.Enabled(; x; i) sii 8p 2 P(x) Readies(; p; x; i) (7)Intera iones deshabilitadas: Una intera ion x estara deshabilitada en la ongura ion iesima de la eje u ion si y solo si no esta habilitada y todoslos pro esos de P(x) estan esperando intera tuar o nalizados.Disabled(; x; i) sii:Enabled(; x; i) ^ 8p 2 P(x) (Waiting(; p; i) _ Finished(; p; i)) (8)Intera iones semihabilitadas: Una intera ion x estara semihabilitada enla ongura ion iesima de la eje u ion si y solo si no esta habilitada y hasido ofre ida por al menos un pro eso.SemiEnabled(; x; i) sii :Enabled(; x; i) ^ 9p 2 P(x) Readies(; x; i) (9)Intera iones onsolidadas: Una intera ion x estara onsolidada en la on-gura ion iesima de la eje u ion si y solo si esta habilitada o deshabilitada.Stable(; x; i) sii Enabled(; x; i) _Disabled(; x; i) (10)

Page 292: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Sin roniza ion Multipro eso en Programas Con urrentes ... 285

Page 293: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

286 D. Ruiz, R. Cor huelo, J. A. Perez, M. ToroHay que desta ar que este modelo abstra to de intera ion solo muestra elaspe to que deben tener las reglas de inferen ia que lo des riben, y que paravalores on retos de L y S tendremos distintos asos de modelos deintera ion.La gura 4 muestra dos reglas de inferen ia que ara terizan (desde un puntode vista abstra to) a nuestros programas. La regla 13 des ribe la semanti a de unofre imiento por parte de un pro eso p. El onse uente solo exige que la transi ionvenga dada por un evento de ofre imiento. Por otro lado, el ante edente obligaa que para que un pro eso p pueda ofre er intera ion primero llegue a un puntode su eje u ion en la que ya no puede eje utar al ulos lo ales, y ademas, parapoder volver a ofre er intera ion o eje utar al ulos lo ales (! 2 fp:; p:g) esne esario que el programa eje ute una intera ion en la que p sea parti ipante.La regla 14 aptura la semanti a de la termina ion de un pro eso p. La transi ionL del onse uente esta ara terizada por el evento de termina ion. Con elante edente expresamos que uando un pro eso p termina su eje u ion ya novolvera a eje utar ni al ulos lo ales ni a ofre er intera iones (! 2 fp:; p:g). I(p) ^ 6= ; ^ (C0 C1 p:L C0) ^9C0; C00; C000; C3 (C2 *L C0 !L C3 ) C2 *L C00 xL C000 *L C3 ^ x 2 )C1 p:L C2 (13)C0; C00 C2 *L C0 !L C00C1 p:;L C2 (14)Figura 4. Modelo abstra to de intera ion entre pro esos de un programaEn el aso del riterio de sele ion podemos en ontrar en la bibliografa va-rios propuestas de sele ion de intera iones. De forma abstra ta, todos ellos se omportan segun el modelo de la gura 3, lo uni o que ambia entre ellos es la ondi ion de sele ion que ada uno adopta. Por ejemplo, en [3 se re iben losofre imientos y tan pronto omo una intera ion habilitada onsigue la ex lu-sion mutua se sele iona (no tiene en uenta la sele ion justa). En [4 se tratael problema de la sele ion justa de alternativas en instru iones de sele ionmultiple no deterministas sele ionando aquella alternativa que ha e mas tiem-po que no se eje uta ha iendo uso de ontadores de sele ion. En [9 se re ibenofre imientos aleatorios y se sele iona aquella intera ion que se habilita prime-ro (se apoya en la Teora de los Grandes Numeros para garantizar la sele ionjusta de intera iones). En [6 se espera a re ibir todos los ofre imientos y sele - iona aquella intera ion que puede ser re hazada en menor numero de o asionesha iendo uso de ontadores de re hazo.

Page 294: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Sin roniza ion Multipro eso en Programas Con urrentes ... 2873 Sele ion ompletamente kjusta de intera ionesDe forma intuitiva entenderemos por eje u ion ompletamente kjusta aquellaque garantiza que ninguna intera ion se eje uta mas de k ve es sin que las inte-ra iones on las que esta enlazada en ese momento esten onsolidadas, ademas,en aso de on i to debe sele ionarse la intera ion de mayor edad. Formal-mente la denimos de la siguiente forma:Deni ion 1 (Sele ion Completamente kJusta) Sea una eje u ion =(C0; ; ) y k un natural no nulo. Diremos que es una eje u ion ompletamentekjusta si el predi ado SKF(; k) se satisfa e.SKF(; k) sii8x 2 I ; i 2 ExeSet(; x;1) Enabled(; x; i) ^(LStable(; x; i) ^ LOldest(; x; i) _ :LStable(; x; i) ^(; x; i) k) (15)Esta deni ion ha e uso de varias fun iones y predi ados auxiliares que de-tallaremos a ontinua ion. LStable(; x; i) es un predi ado que utilizamos parasaber si las intera iones enlazadas on x en la ongura ion iesima estan enun estado onsolidado.LStable(; x; i) sii 8y 2 Linked(; x; i) Stable(; y; i) (16)LOldest(; x; i) es un predi ado que se satisfa e uando la intera ion x es lade mayor edad en la ongura ion iesima de la eje u ion de entre todas lasintera iones que estan enlazadas on ella.LOldest(; x; i) sii 8y 2 Linked(; x; i) Age(; x; i) Age(; y; i) (17)(; x; i) es una fun ion que devuelve el numero de ve es que la intera ion xse ha eje utado en presen ia de intera iones enlazadas no onsolidadas desde laultima ongura ion que se eje uto hasta la ongura ion i.(; x; i) = Xk<i((k) = x ^ Linked(; x; k) 6= ; ^ :LStable(; x; k)) (18)donde Pa2A P (a) , jfa 2 A j P (a)gj), y se dene de la siguiente forma(observe que el maximo de un onjunto va o es ?): , j if j = maxfk 2 ExeSet(; x; i) j LStable(; x; k)g ^ j 6=?1 en otro aso (19)De la deni ion se dedu e que toda eje u ion que ontenga menos de k eje u io-nes de intera ion es ompletamente kjusta (ya que ninguna intera ion se hapodido eje utar mas de k ve es) y que ademas k debe ser ono ido a priori4 ydebe veri ar que: k maxfj I(p) \ I(q)j p; q 2 P ^ p 6= qg (20)4 Observe que k ara teriza a la no ion de sele ion ompletamente kjusta, es de ir,es un dato de partida. En la no ion de sele ion justa nita el valor de k se al ulaa posteriori sobre la propia eje u ion.

Page 295: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

288 D. Ruiz, R. Cor huelo, J. A. Perez, M. ToroEsto es as porque en un grupo de N intera iones enlazadas tenemos que ga-rantizar que, en el peor de los asos ( uando el grupo se onsolida y todas sehabilitan), al menos toda intera ion se eje uta 1 vez ada N eje u iones deintera iones enlazadas, es de ir k = N . Para poder garantizar esto en todoslos grupos de intera iones enlazadas lo que tenemos que ha er es dar a k unvalor mayor o igual que el maximo de intera iones enlazadas, lo que se obtiene al ulando el numero maximo de intera iones omunes que tienen los pro esosdel sistema dos a dos.El valor de k puede verse omo un umbral de semihabilita iones en nuestraseje u iones. Es de ir, podemos entender que k es el numero maximo de ve esque una intera ion se puede sele ionar en presen ia de intera iones enlazadasque se en uentran semihabilitadas.Por otro lado, las eje u iones ompletamente kjustas de un programa pue-den verse omo un sub onjunto de las eje u iones ompletamente justa a lasque en el riterio de sele ion se les ha a~nadido una ondi ion en fun ion de k.As si k es mnimo tenemos que el riterio de sele ion de intera iones es muyexigente de forma el onjunto de intera iones que lo umplen es mnimo, porlo que el sub onjunto de las posibles eje u iones ompletamente kjusta tam-bien es mnimo. Por el ontrario, si k tiende a innito el riterio de sele ion esmuy relajado (de he ho solo se exige que las intera iones se en uentren habili-tadas), por lo que el onjunto de posibles eje u iones es maximo (igual al de laseje u iones ompletamente justa).Para ver omo on la sele ion ompletamente kjusta de intera iones dete -tamos y resolvemos las anomalas de la sele ion ompletamente justa anali emoslas eje u iones de las guras 2.a. En la primera se observa omo di ha eje u ionno seria ompletamente kjusta para ualquier k menor que n ya que Get1 se eje- uta n ve es uando Get2 se en uentra semihabilitada. En la segunda eje u ion(gura 2.b) tambien tenemos que no seria ompletamente kjusta para ualquierk menor que n por el mismo motivo on la diferen ia de que en la ongura ionk+1 la intera ion Get1 no umplira el riterio de sele ion permitiendo de estaforma que Get2 se habilite y sea sele ionada.4 Algoritmo de sele ion de intera iones ompletamentekjustoA ontinua ion vamos a des ribir en detalle un algoritmo que a partir de ual-quier programa uyo modelo abstra to de intera ion sea el des rito en la se ion2 obtenga eje u iones que sean ompletamente kjustas para un valor de k dado.Primero haremos una des rip ion informal a grandes rasgos del algoritmo.Despues haremos una des rip ion mas detallada ha iendo uso de reglas de in-feren ia para des ribir el ambio de estado ( ongura ion) que provo an losdistintos eventos.

Page 296: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Sin roniza ion Multipro eso en Programas Con urrentes ... 2894.1 Des rip ion informalLa idea del algoritmo onsiste en ordenar todas las intera iones en una ola ()de forma que las intera iones que estan al nal son las que se han eje utadomas re ientemente (sele ionar la primera intera ion habilitada de una olaordenada garantiza que nuestras eje u iones sean ompletamente justas [6).Ademas a ada intera ion x se le aso ia un ontador (Æ(x)) que sirve parallevar la uenta del numero de ve es que otras intera iones enlazadas on x sehan eje utado uando el grupo no estaba onsolidado.Para ono er el estado de los pro esos y las intera iones utilizaremos unmapa de ofre imientos ('), de forma que ada intera ion tiene aso iado entiempo de eje u ion uales son los pro esos que la han ofre ido. Para ello adavez que se produ e una transi ion de ofre imiento/intera ion se a tualiza di homapa de la forma ade uada.As, nuestro algoritmo siempre sele ionara para su eje u ion aquella inte-ra ion habilitada que se en uentre primero en la ola y que omparta pro esos on un onjunto de intera iones onsolidado o que el valor de Æ de ninguna deellas haya superado el valor de k.4.2 Des rip ion detalladaVamos a des ribir la semanti a operativa de nuestro algoritmo de sele ion om-pletamente kjusto ha iendo uso de la regla de transi ion SKF sobre on-gura iones que denotaremos omo D;D0; D1; : : : Di has ongura iones estaran ompuestas por la ongura ion C del programa mas las estru turas de datosne esarias para llevar a abo la sele ion.A ontinua ion deniremos las estru turas de datos ne esarias as omo lasfun iones que las a tualizan.Estru turas de datosMapa de ofre imientos: Denimos el mapa ' de forma que a ada intera ionx 2 I se le aso ia un onjunto de pro esos '(x).' 2 ff : I ! 2P ^ dom f = Ig (21)Este mapa sirve para disponer en tiempo de eje u ion de uales son lospro esos que han ofre ido ada intera ion. De esta forma, podremos saber uando una intera ion se habilita o uando omparte pro esos on otrasintera iones.Pro esos que nalizados: Se dene un onjunto de pro esos # P que on-tendra a todos los pro esos que han nalizado su eje u ion. En este onjuntomantendremos todos los pro esos que han terminado su eje u ion de formaque se podra dete tar uando un pro eso ha terminado su eje u ion o uandouna intera ion no volvera jamas a habilitarse.

Page 297: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

290 D. Ruiz, R. Cor huelo, J. A. Perez, M. ToroMapa de semihabilita iones: Denimos un mapa Æ de forma que a ada in-tera ion se le aso ia un numero natural.Æ 2 ff : I ! N ^ domf = Ig (22)En este mapa mantendremos informa ion a er a del numero de ve es queuna intera ion ha sido re hazada en presen ia de otras intera iones on lasque omparta algun pro eso. De esta forma podremos saber uando dentrode un grupo de intera iones que omparten pro esos alguna intera ionpuede estar siendo marginada.Cola de intera iones: Se dene la se uen ia de intera iones de forma quelas intera iones que se en uentran en las primeras posi iones son aquellasque ha e mas tiempo que no se eje utan. = [x1; : : : ; xn ^ n = jI j ^ img = I (23)Congura ion extendida: La ongura ion extendida del algoritmo en uninstante i viene dada por la tupla (Ci; i; 'i; Æi; #i), donde Ci es la ongura- ion del programa en el instante i, i es la ola de intera iones, 'i es el mapade ofre imientos, Æi es el mapa de semihabilita iones y #i es el onjunto depro esos nalizados.La ongura ion ini ial del algoritmo viene determinada por la ongura ionini ial del programa, ualquier ola de intera iones (no importa el orden),un mapa de ofre imientos '0 de forma que 8x 2 dom I '0(x) = ;, un mapade semihabilita iones Æ0 de forma que 8x 2 I Æ0(x) = 0 y una se uen iade pro esos nalizados #0 = ;.Fun iones de onsulta y a tualiza ion de las estru turas de datosA tualiza ion de ' y #: Cuando un pro eso p de ide intera tuar a traves de onjunto de intera iones I utilizaremos la fun ion AddOer('; p; )para rear un nuevo mapa de ofre imientos a tualizado de la siguiente forma:AddOer('; p; ) =fx 7! '(x) x 2 dom' ^ x 62 g [fx 7! '(x) [ fpg x 2 dom' ^ x 2 g (24)Cuando una intera ion x se sele iona para ser eje utada sera la fun ionRemoveOer('; x) la que se en argue de rear un nuevo mapa de ofre imien-tos de la siguiente manera:RemoveOer('; x) = fx 7! '(x) n P(x) x 2 dom'g (25)Cuando un pro eso p naliza su eje u ion y ofre e el onjunto de intera - iones va o (p:;) la fun ion AddFinished(#; p) rea un nuevo onjunto depro esos nalizados en el que in luye a p.AddFinished(#; p) = # [ fpg si 6= ;# si = ; (26)

Page 298: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Sin roniza ion Multipro eso en Programas Con urrentes ... 291A tualiza ion de : Cuando una intera ion x resulta sele ionada para sereje utada usaremos la fun ion Order para retrasar la posi ion de x en .Order(; Æ) = 0 si dom = dom 0 ^ ran = ran 0 ^8x1; x2 2 ran 01(x1) 01(x2)) Æ(x1) Æ(x2) (27)Intera iones habilitadas disyuntas: Dada una ola de intera iones y unmapa de ofre imientos ' se dene el onjunto de todas las intera ioneshabilitadas disyuntas Ready(; ') de la siguiente forma:Ready(; ') = fx 2 dom' P(x) = '(x)^y 2 S P(y) = '(y)^ 1(y) < 1(x)g(28)Siendo S = fz 2 dom' '(z) \ '(x) 6= ;g.Intera iones onsolidadas: Dado un onjunto de intera iones , un ma-pa de ofre imientos ' y un onjunto de pro esos nalizados # denimos elpredi ado Consolidated(; '; #) que se veri a uando todos los pro esos detodas las intera iones de han ofre ido intera ion5.Consolidated(; '; #) sii 8x 2 8p 2 P(x) p 2 ran' _ p 2 # (29)A tualiza ion de Æ: Cuando una intera ion x es sele ionada para su eje u- ion utilizaremos la fun ion Update('; Æ:x) para rear un nuevo mapa desemihabilita iones de la siguiente forma:Update('; Æ:x) = Æfx 7! 0gfy 7! Æ(y)+1y 2 Snfxg^:Oered(S; '; #)g (30)Deniendose S igual que en la fun ion Ready(; ').Hemos des rito el algoritmo de sele ion ompletamente kjusto de intera - ion ha iendo uso de las dos reglas de inferen ia que se muestran en la gura 5.En la regla 31 des ribimos omo ambian las estru turas de datos uando seprodu e una transi ion de ofre imiento, es de ir, ada vez que un pro eso p ofre eel onjunto de intera iones nuestro algoritmo a~nade di ho ofre imiento en elmapa de ofre imientos. En el aso de que un pro eso p nali e lo que ha emoses a~nadir di ho pro eso al onjunto de pro esos nalizados.En la regla 32 se des ribe que intera ion debe sele ionar para que la eje- u ion que se genere sea ompletamente kjusta (observese que C1 xL C2apare e en el onse uente). El ante edente de esta regla asume que x es la pri-mera intera ion habilitada de la ola , de forma que el riterio de sele ion sesatisfa e si se da alguna de las siguiente ondi iones:1. Si x no es on i tiva on ninguna intera ion, es de ir, S = fxg.2. Las intera iones on las que x esta enlazada estan onsolidadas.3. El ontador de semihabilita iones aso iado de todas las intera iones enla-zadas on x es menor que k.5 Fjese en que onsolida ion no impli a habilita ion pero en ambio habilita ion siimpli a onsolida ion.

Page 299: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

292 D. Ruiz, R. Cor huelo, J. A. Perez, M. ToroC p:L C0 ^'0 = AddOer('; p; ) ^ #0 = AddFinished(#; p)(C; ; '; Æ; #) p:SKF (C0; ; '0Æ; #0) (31)x 2 Ready(; ') ^ S = fz 2 dom' ('(z) \ '(x) 6= ;)g ^ 0 = Order(; Æ0) ^ '0 = RemoveOer('; x) ^ Æ0 = Update('; Æ:x) ^(S = fxg _Oered(S; '; #) _ (S 6= fxg ^ maxy2SnfxgÆ(y) < k))(C; ; '; Æ; #) xSKF (C0; 0; '0; Æ0; #) ^ C x L C0 (32)Figura 5. Algoritmo de sele ion SKF .5 Con lusionesEn este art ulo hemos presentamos un nuevo riterio de sele ion de intera io-nes para poder garantizar propiedades fundamentales en programas uyo om-portamiento es no determinista que on otros riterios resultan imposibles. Este riterio de sele ion de intera iones resuelve las anomalas de la sele ion om-pletamente justa mostradas en la gura 2.a y 2.b y sus prin ipales ventajas son: No asume que ualquier eje u ion nita sea justa por deni ion, lo que nospuede llevar a eje u iones omo las mostradas en 2.a. El valor de k se ajusta empri amente a priori para ada programa. Di hovalor ara teriza las eje u iones que umplen el riterio de sele ion. Garantiza la eje u ion de todas las intera iones que pueden habilitarse enun tiempo nito y a otado superiormente (el valor de di ha ota vara enfun ion de k). Resuelve el problema de las onspira iones on una bondad que aumenta onforme disminuye el valor de k. Propor ionamos un algoritmo para implementarla que no requiere a ederal estado lo al de los pro esos.Una de las aporta iones mas importantes es el on epto de umbral de se-mihabilita iones k, que utilizamos para dete tar las posibles situa iones de ons-pira ion y resolverlas a tiempo. Este umbral ara teriza la eje u ion de nuestrosprogramas de forma que nos sirve para regular la velo idad a la que se eje utaranlas intera iones que omparten pro esos en tiempo de eje u ion. Si k es mnimoenton es las intera iones enlazadas se eje utaran a la velo idad del parti ipantemas lento, ya que en este aso ninguna intera ion se sele iona hasta ono erel estado nal de todas las intera iones on las que omparte ofre imientos.En este ontexto nuestro algoritmo es similar a [4 resolviendo el problema delas onspira iones a osta de ralentizar los pro esos que omponen un programa on urrente. Si k es maximo (tiende a innito) enton es las intera iones enla-zadas se eje utan a la velo idad del parti ipante mas rapido, ya que en este aso

Page 300: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Sin roniza ion Multipro eso en Programas Con urrentes ... 293toda intera ion se sele iona tan pronto omo obtiene la ex lusion mutua onlas que es on i tiva. En este ontexto nuestro algoritmo se pare e a [3 y [11,en los que no se tiene en uenta el problema de la sele ion justa de intera ionespero se onsigue eje utar un gran numero de intera iones por segundo.Referen ias1. R. Alur and T. A. Henzinger. Finitary fairness. ACM Transa tions on Program-ming Languages and Systems, 20(6):11711194, November 1998.2. P.C. Attie, N. Fran ez, and O. Grumberg. Fairness and hyperfairness in multipartyintera tions. Distributed Computing, 6(4):245254, 1993.3. R.L. Bagrodia. Pro ess syn hronization: Design and performan e evaluation ofdistributed algorithms. IEEE Transa tions on Software Engineering, 15(9):10531065, September 1989.4. E. Best. Fairness and onspira ies. Information Pro essing Letters, 18(4):215220,1984.5. J. R. Bu hi. On a de ision method in restri ted se ond order arithmeti . InPro eedings of the International Congress on Logi , Method, and Philosophy ofS ien e, pages 112, Stanford, CA, USA, 1962. Stanford University Press.6. R. Cor huelo, D. Ruiz, M. Toro, and A. Ruiz. Implementing multiparty intera -tions on a network omputer. In Pro eedings of the XXVth Euromi ro Conferen e(Workshop on Network Computing), Milan (Italy), September 1999. IEEE Press.7. N. Fran ez. Fairness. SpringerVerlag, 1986.8. N. Fran ez and I. Forman. Intera ting pro esses: A multiparty approa h to oordi-nated distributed programming. AddisonWesley, 1996.9. Y.J. Joung. Two de entralized algorithms for strong intera tion fairness for systemswith unbounded speed variability. Theoreti al Computer S ien e, 243(12):307338, 2000.10. E. Olderog and K.R. Apt. Fairness in parallel programs: The transformationalapproa h. ACM Transa tions on Programming Languages and Systems, 10(3):420455, July 1988.11. J.A. Perez, R. Cor huelo, D. Ruiz, and M. Toro. A framework for aspe torientedmultiparty oordination. In Kluwer, editor, Pro eedings of the Third IFIP WG 6.1International Working Conferen e on Distributed Appli ations and InteroperableSystems, Krakow, Poland, September 2001. To appear soon.

Page 301: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 302: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Compatibility of Linda InterfacesAntonio Brogi1, Ernesto Pimentel2, and Ana M. Roldan31 Dipartimento di Informatica, Universita di Pisa, Italy2 Dpto. de Lenguajes y Ciencias de la Computacion, Universidad de Malaga, Spain3 Dpto. de Ingenieria Electronica, Sistemas Informaticos y Automatica, Universidadde Huelva, SpainAbstract. Linda is a coordination language, originally presented as aset of inter-agent communication primitives which can virtually be addedto any programming language.In this paper, we analyse the use of Linda to specify the interactive be-haviour of software components. We rst introduce a process algebra forLinda and a we dene a notion of process compatibility that ensures thesafe composition of components. In particular, we proof that compati-bility implies successful computation.We also argue that Linda features some advantages with respect to sim-ilar proposals in the context of dynamic compatibility checking. In thisperspective, we propose an alternative denition of compatibility thattakes into account the state of a global store, which gives some relevantinformation about the current execution of the system.The results presented in this paper correspond to the preliminary stepstowards a depth exploration of dierent formalisms to model interactionin open distributed systems, always oriented to their practical applicationby means of automatic checking tools.Keywords: Coordination languages, components, compatibility, interac-tion, process algebras.1 IntroductionComponent-Based Software Engineering (CBSE) is an emergent disciplinegrowing up in the eld of Software Engineering. Although it appearedrecently, there is a lot of people working on this eld. The reason is thenecessity for developing open systems and plug-and-play reusable applica-tions which lead to the concept of \commercial o-the-self" (COTS) com-ponent. Historically, the most important previous platforms were CORBAand DCE which were developed by OSF (Open Software Foundation) andOMG (Object Management Group). The following step was formed byseveral platforms, like COM/DCOM, CCM, EJB, and recently .NET,developed by Microsoft.

Page 303: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

296 A. Brogi, E. Pimentel, A. M. RoldanIt is worth observing, however, that traditional IDLs were denedfor describing the services that objects oer, rather than the servicesthey need from other objects or the relative order in which they expecttheir methods will be called. It is therefore necessary to add protocolinformation to object interfaces.The objective of this work is to explore the usability of the coordi-nation language Linda as a language to express protocol information ofcomponents. This has been already dealt with in previous works, fromdierent perspectives. Thus, in the eld of Software Architecture, severalattempts have been made to express, at certain level of detail, the be-havior of components involved in a software system architecture. In fact,some formal approaches (e.g. CSP, -calculus, etc.) have been used todescribe protocols governing the interaction of a component with its envi-ronment [1, 9]. Other similar works have been developed in the context ofcomponent-based software engineering, where also process algebras havebeen applied [4, 10] to give a more practical view, where both feasibilityof automatic tools and the application to real component platforms arethe main motivations.In this work, we explore a dierent approach based on the coordinationmodel Linda [11], trying to exploit the specic features which characterizeit. Linda can be presented as a set of interaction primitives which allowagents to read, delete and add tuples in a tuple space, which is shared byall interacting agents. This way, we dene a compatibility relation amongagents which takes into account the situation of the store, so making thecompatibility checking easier during the system's execution, and ensur-ing the safe composition of components. We are interested in using Lindaas a specication language for describing component protocols, that is,we do not worry about component computation, but about its interactionbehavior. Thus, a component would be dened by two orthogonal descrip-tions, its execution code (providing the computation), and its Linda-basedspecication (giving an abstraction of the interaction behavior). In orderto have a process calculus semantically equivalent to Linda, we have con-sidered an algebraic view of its communication primitives [8].The rest of the paper is organized as follows. Section 2 presents aLinda-based process calculus, and we illustrate by means of a simpleexample how it can be used to specify component protocols. Next sectionis devoted to introduce the notion of safe composition of components,giving several conditions to ensure it. In this section, we dene a notionof compatibility, which is rstly presented in an intuitive way, and thenwe give an alternative denition which is store sensitive. We also prove

Page 304: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Compatibility of Linda Interfa es 297the equivalence between both compatibility presentations. Finally, we givesome concluding remarks.2 Specifying component protocols in Linda2.1 A Linda calculusLinda [11] was the rst coordination language [12], originally presentedas a set of inter-agent communication primitives which can virtually beadded to any programming language. Linda's communication primitivesallow processes to add, delete and test for the presence/absence of tuplesin a shared tuple space. The tuple space is a multiset of data (tuples),shared by concurrently running processes. Delete and test operations areblocking and follow an associative naming scheme that operates like selectin relational databases.In this paper, following [8], we shall consider a process algebra Lcontaining the communication primitives of Linda. These primitives per-mit to add a tuple (out), to remove a tuple (in), and to test the pres-ence/absence of a tuple (rd, nrd) in the shared dataspace. The languageL includes also the standard prex, choice and parallel composition op-erators in the style of CCS [13].The syntax of L is formally dened as follows:P ::= 0 j A:P j P + P j P k P j recX:PA ::= rd(t) j nrd(t) j in(t) j out(t)where 0 denotes the empty process and t denotes a tuple.Following [8], the operational semantics of L can be modeled by alabelled transition system dened by the rules of Table 1. Notice that thecongurations of the transition system extend the syntax of processes byallowing parallel composition of tuples. Formally, the transition systemof Table 1 refers to the extended language L0 dened as:P 0 ::= P j P 0 jj htiRule (1) states that the output operation consists of an internal movewhich creates the tuple hti. Rule (2) shows that a tuple hti is ready tooer itself to the environment by performing an action labelled t. Rules(3), (4) and (5) describe the behaviour of the prexes in(t), rd(t) andnrd(t) whose labels are t, t and :t, respectively. Rule (6) is the standardrule for choice composition. Rule (7) is the standard rule for the syn-chronization between the complementary actions t and t: It models the

Page 305: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

298 A. Brogi, E. Pimentel, A. M. Roldan(1) out(t):P ! hti k P (6) P ! P 0P +Q ! P 0 +Q(2) hti t! 0 (7) P t! P 0 Q t! Q0P k Q ! P 0 k Q0(3) in(t):P t! P (8) P t! P 0 Q t! Q0P k Q ! P 0 k Q(4) rd(t):P t! P (9) P ! P 0 6= :tP k Q ! P 0 k Q(5) nrd(t):P :t! P (10) P :t! P 0 Q 6 t!P k Q :t! P 0 k QTable 1. Transition system for L.eective execution of an in(t) operation. Rule (8) denes the synchro-nization between two processes performing a transition labelled t and t,respectively. Notice that the process performing t is left unchanged, sincethe read operation rd(t) does not modify the dataspace. The usual rule(9) for the parallel operator can be applied only to labels dierent from:t. Indeed a process P can execute a nrd(t) action in parallel with Q onlyif Q is not able to oer the tuple hti, as stated by rule (10). Notice that,following [8], there are no rules for recursion since its semantics is denedby structural axiom recX:P P [recX:P=X ] which applies an unfoldingstep to a recursively dened process.The rules of Table 1 are used to dene the set of derivations for aLinda system. Following [8], both reductions labelled and reductionslabelled :t are considered. Formally, this corresponds to introducing thefollowing derivation relation:P 7! P 0 i (P ! P 0 or P :t! P 0):Notice that the above operational characterization of L employs the so-called ordered semantics of the output operation [7]. Namely, when asequence of outputs is executed, the tuples are rendered in the same orderas they are emitted. It is also worth noting that also the store can be seenas a process which is the parallel composition of a number of tuples.Let us nally introduce another derivation relation that will be usedas a shorthand in the rest of the paper:P =) P 0 i (P 7! ! P 0)where 2 ft; t; tg.

Page 306: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Compatibility of Linda Interfa es 2992.2 Component protocols in LindaWe now describe how the Linda language can be eectively used to specifythe interactive behaviour of components. To exemplify the appropriate-ness of Linda for specifying component protocols, we will illustrate itsapplication to the standard client/server interaction model.The typical basic behaviour of a server can be described by the fol-lowing protocol:SERVER = in(c,tos,qry).out(c,ans).SERVERThe server repeatedly exhibits the same interactive behaviour: It rst in-puts a request and then outputs the answer it computed for the receivedrequest. The input operation has three parameters which denote the name(c) of the client who produced the request, the type of service required(some constant tos), and the actual request (qry). The server then re-turns its answer to the query by placing a tuple of the form <c,ans> inthe shared dataspace.The typical basic behaviour of a client is instead described by thefollowing protocol:CLIENT = out(#me,tos,qry).in(#me,ans).CLIENTwhere #me is the identier of the client process [11].Notice that, in the above specication, the client request does notrefer to the name of a specic server. Most importantly, a client does notneed to be aware of which servers are currently available. Notably, theabove specication allows several clients and servers to be dynamicallyand transparently plugged in an open system.The above specication describes the basic behaviour of clients andservers. A more rened specication may include for instance the broker-age of the servers currently available for a given type of service. Indeed,the server protocol may be rewritten so that the rst operation a serverperforms is to inform the system that she is a server featuring a certaintype of service. This can be done by outputing a tuple that associatesthe process identier with a certain type of service, as specied in thefollowing protocol:SERVER = out(tos,#me).CYCLECYCLE = in(c,#me,qry).out(#me,c,ans).CYCLEwhere CYCLE is a process name. Notice also that the SERVER protocolemploys the tuple format <sender,receiver,message> for the messageexchanged between clients and servers on the shared dataspace.

Page 307: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

300 A. Brogi, E. Pimentel, A. M. RoldanServer brokerage can be then easily included in the client protocol asfollows:CLIENT = (rd(tos,srv).out(#me,srv,qry).in(srv,#me,ans).CLIENT)+(nrd(tos,srv).EXCEPTION)Namely the client determines the name of a server oering the desiredtype of service by means of the rd(tos,srv) operation. If there is noserver available for such type of service (nrd(tos,srv)), then the clientwill have to handle the unexpected situation by means of some processEXCEPTION.3 Correct composition of components3.1 Components compatibilityWe now introduce a notion of compatibility among processes in orderto determine whether two processes | specied as two Linda agents |conform one another.Let us rst dene the notion of successful computation which, intu-itively speaking, denotes the absence of deadlock in all possible alternativeexecutions of a process.Denition 1 (Successful computation). A process P is a possible fail-ure if there exists an agent P 0 such that P 7! P 0 67! and P 0 is notstructurally equivalent to a store (i.e., a parallel composition of tuples).On the contrary, a process P is successful if P is not a possible failure.Before dening the notion of compatibility among processes, we in-troduce the notion of synchronizable processes. This notion is needed fortechnical reason, and its need will be better claried later.Denition 2 (Synchronizable processes). A process P provides aninput a for an agent Q if there exist two processes P 0 and Q0, such thatP a=) P 0 and Q =) Q0, where 2 fa; ag. Two processes P and Q aresynchronizable if P provides an input for Q or Q provides an input for P .Denition 3 (Compatible processes). A process P is semi-compatiblewith a process Q, written P C Q (and the relation C is called a semi-compatibility), i:1. If P is not successful then P and Q are synchronizable

Page 308: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Compatibility of Linda Interfa es 3012. If P only can proceed by :t transition then Q 7! 6 t!3. If P ! P 0 then P 0 C Q4. If P t! P 0 and Q t! Q0 then P 0 C Q05. If P t! P 0 and Q t! then P 0 C Q6. If P : t! P 0 and Q 6 t! then P 0 C QA relation C is a compatibility if both C and C1 are semi-compatibilities.We say that two processes P and Q are compatible, and we denote it byP Q, if there exists a compatibility relation C , such that P C Q.Intuitively speaking, two Linda processes are compatible if for eachpossible action oered by one of them there is a corresponding answerfrom the other one, and vice-versa. Notice that condition (i) has a tech-nical justication as it avoids considering two unrelated processes (viz.,two processes that do not share any action) compatible.If we consider the notion of bisimilarity dened in other process cal-culi [14], we can observe that compatibility provides a dierent way ofcomparing processes. In fact, whereas two bisimilar processes present the\same" behavior, two compatible processes describe two \complemen-tary" behaviors.When processes are dened with a nite number of states (even if theypresent an innite behavior), it is worth observing that it is possible toimplement a tool capable of automatically checking the compatibility oftwo processes. Obviously, depending on the structural complexity of theprocesses, the cost of checking might be very high. In any case, even wheninnite behavior is dealt with, the usefulness of a tool is clear. Thus, anegative answer showing the non-compatibility of two components couldprevent from wrong compositions. Obviously, the compatibility of twogeneric processes is not always decidible. However, from a practical pointof view, it is usual to complement the description of a component withstate nite processes. We can, for instance, verify that the processes:CLIENT = out(#me,tos,qry).in(#me,ans).CLIENTand:SERVER = in(c,tos,qry).out(c,ans).SERVERare compatible. Since CLIENT ! qry! CLIENT' and SERVER qry!SERVER',we check the compatibility of the two new processesCLIENT'=in(#me,ans).CLIENTandSERVER'=out(c,ans).SERVER.Now, CLIENT' ans!CLIENT and SERVER' ! ans!SERVER. Then, both pro-

Page 309: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

302 A. Brogi, E. Pimentel, A. M. Roldancesses belon to a compatibility relation, and then, we can conclude thatCLIENT and SERVER are compatible.On the other hand, we can observe that an \eager" server (that mayterminate if there are now pending queries) such as:SERVER2 = in(c,tos,qry).out(c,ans).SERVER2 + nrd(c,tos,qry).0is not compatible with CLIENT.We now prove that the compatibility of two processes implies thesuccess of their parallel composition.Theorem 4. If P Q then P k Q is successful.Proof. Suppose that P Q but P k Q is not successful.Then, there existsF (a possible failure) such that P k Q 7! F, F is not a set of tuples andF 67!. We will prove that it is not possible by induction on the numbern of -transitions leading to F.1. Base Case. Suppose n = 0. Then P k Q = F 67!, therefore P 6 ! andQ 6 !. If P or Q is a stuck process, then, by the rst condition of com-patibility, we infer that P and Q are synchronizable (it means that aexists such that P a=) P 0 and Q =) Q0, where 2 fa; ag). And then,we have P k Q =) P 0 k Q0 !, which is a contradiction. Anotherpossibility is that P :t! and Q t! for some action t (or viceversa);but this is contradictory with the second condition of compatibility.2. Inductive hypothesis. 8P 0; Q0: P 0 Q0, if P 0 k Q0 7!k F with k < n,then either F 7! or F is structurally equivalent to a store (i.e. aparallel composition of tuples).3. General Case. Suppose that (P k Q) 7! (P 0 k Q0) 7!n1 F. Thenthe initial transition is due to one of the following situations:(a) P ! P 0. Then, since Q = Q0 we have that P 0 Q0(b) P t! P 0 and Q t! Q0. Then, we have that P 0 Q0(c) P t! P 0 and Q t!. Then, we have P 0 Q0(d) P :t! P 0 and Q 6 t!. Then, we have P 0 Q0(e) Or the symmetrical situations for Q.Because of P Q in every situation, we can apply the inductive hy-pothesis and deduce that either F ! or F is a parallel compositionof tuples, again obtaining a contradiction. For instance, the previously described processes CLIENT and SERVERare compatible, and Theorem 4 ensures that their parallel composition isa success.

Page 310: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Compatibility of Linda Interfa es 3033.2 Store sensitive compatibilityIn Linda inter-process communication occurs only via a shared store (ordataspace) which is a (multi)set of tuples inserted, extracted or deletedby the concurrent processes.In order to have an explicit treatment of the store, we now dene acompatibility relation that takes into account the situation of the store.As we will see, we can obtain a similar result concerning successful com-putation in the presence of compatibility. An advantage of having anexplicit reference to the store is the possibility of establishing dynamiccompatibility checking. Indeed, a Linda-based computation is character-ized by the store's evolution, so that the set of tuples included into thestore governs each computation step. This way, the aim of the followingdenition is to enable run-time, store-sensitive compatibility checking.Denition 5 (Compatible processes with respect to a store). A pro-cess P is semi-compatible with a process Q w.r.t a store Store, writtenP CStore Q, i:1. If P is not successful then a partition of Store, StoreP k StoreQ,exists such that P k StoreP and Q k StoreQ are synchronizable.2. If P ! P 0 then P 0 CStore Q.3. If P t! P 0 and Store t! Store0 then P 0 CStore0 Q.4. If P t! P 0 and Q t! then P 0 CStore Q5. If P t! P 0 and Store t! Store0 then P 0 CStore0 Q.6. If P t! P 0 and Q t! Q0 then P 0 CStore0 Q0.7. If P : t! P 0 , Q 6 t! and Store 6 t! then P 0 CStore Q.A relation CStore is a compatibility w.r.t. the store Store if both CStoreand C1Store are semi-compatibilities w.r.t. the same Store. We say thattwo processes P and Q are compatible w.r.t. Store, and we denote itby P Store Q, if there exists a compatibility relation CStore, such thatPCStoreQ.As in Denition 3, condition (i) is introduced for technical reasons toavoid two unrelated processes to be considered compatible. In this case,since the compatibility relation is relative to a certain store, we allowto have unrelated (without sharing complementary actions) compatibleprocesses, whenever they might be related through the store. That is,when two processes do not present any common (complementary) behav-ior, but one of them, after consuming a tuple from the store, synchronizes

Page 311: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

304 A. Brogi, E. Pimentel, A. M. Roldanwith the other process, then they may present a compatible behavior. Inanother case, these processes should not be considered compatible.Notice that two processes which are not compatible in the sense ofDenition 5 can be compatible with respect to a convenient store. Forexample, if we consider the process CLIENT2=in(#me,srv,ans).CLIENT,it is not compatible with the process SERVER, but they are compatiblew.r.t. a store containing the tuple <c,tos,qry>. Here, we can see how thenew introduced notion makes more exible the compatibility between twoprocesses. In fact, the compatibility of a client and a server could dependon the actions already made by a third component already created (theone which has put the convenient tuple into the store.)The result of Theorem 4 can be extended to Store , obtaining thefollowing theorem.Theorem 6. If P Store Q then P k Q k Store is successful.Proof. Analogous to the proof of Theorem 4. Theorem 6 ensures the success of the computation of a pair of pro-cesses in presence of a suitable store. In practice, Theorem 6 can be used: both for checking the compatibility of a component and of a runningsystem w.r.t. the current store (characterizing the current state of theexecution), and for conditioning the acceptance of a given component into an openrunning system so as to wait for a suitable state of the store in orderto ensure the success of the overall system.It is worth observing that the two relations and Store are closelyrelated. Although we have not fully proved the relationship between bothnotions, we conjecture the following result: \if P Store Q then (P kStoreP ) (Q k StoreQ) for some partition Store = StoreP k StoreQ".This is rather natural, because the notion of compatibility w.r.t. a store isdened in terms of the complementary behavior of a process with respectto another one (as it is made in the notion of compatibility), and withrespect to the store, which is dealt with as one more process (a parallelcomposition of tuples). Informally, can be seen as a dierent presen-tation of Store . What we mean with this is that the compatibility withrespect to a store could be dened in terms of the compatibility relation,where the store can be seen as one more process: a parallel composi-tion of tuples. The advantage of using the presentation given by Store isits usefulness from the automatic checking perspective. Although the new

Page 312: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Compatibility of Linda Interfa es 305compatibility relation is relevant per se (because the store plays an impor-tant role in the interaction of components, and it is explicitly considered),a more interesting point is the possibility of building an automatic check-ing tool capable of determining which is the store (if any) that makes twogiven processes compatible.4 Concluding remarksLinda is a coordination language where inter-process communication canonly occur through a set of tuples, and the main novelty of our proposalconsists of dening a compatibility relation taking into account the situ-ation of the store. The advantage of this is the possibility of establishingdynamic compatibility checking. That is, when a component has to beincorporated into an already executing system (seen as another compo-nent), the compatibility has to be analyzed dynamically, and the \static"specication is not enough because it presents the behavior of a compo-nent from its instantiation. Indeed, the advantage of using a Linda-basedformalism is that a Linda computation is characterized by the store's evo-lution, in such a way that the set of tuples included into the store governseach computation step. This is not made in other proposal, where otherformalisms, like CSP or -calculus, are used. We believe that this Lin-da's feature can be potentially be used to establish the compatibility ofexecuting components, by using the store to have information about thecurrent state of the component.Indeed, some of the issues covered in this paper have also been dealtwith in other proposals. In the context of software architecture Allenand Garlan [1] use the process algebra CSP to describe synchronizationof components and connectors, while having some limitations concerningthe dynamic change of congurations. Another proposal improving the ex-pressiveness of interaction descriptions by using -calculus was presentedby Canal [9]. Some of the ideas proposed in [9] have already been appliedto CORBA in [10]. In this case, dynamic interaction among components(dynamic change of topology) can be better expressed than in CSP. Otherworks, like [4], propose the use of (a subset of) -calculus to describe in-teraction patterns for components so as to reduce the cost of verifyingcorrectness properties in dynamic, open systems. Our proposal somehowcombines these two last lines by dening a notion of process compatibilityin the style of [9, 10], while focussing on the automatic, run-time checkingof properties in dynamic, open systems in the style of [4].

Page 313: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

306 A. Brogi, E. Pimentel, A. M. RoldanOur future work will be devoted to dene an inheritance relation overprocesses in order to promote the reusability and substitutability of in-teraction descriptions, and to study how this aects compatibility andsuccessful computations. We are also planning to develop an automatictool (by applying model checking techniques) to check compatibility inorder to explore the practical application of our proposal and to ana-lyze and experiment the cost of checking properties in practical real-wordcases.New generation component-based platforms (e.g., .NET) will allowprotocol information to be directly included in the metalanguage descrip-tion (e.g., in XML) of a component. In this perspective, our future workwill be devoted to develop a methodology for coding protocol informationas metalanguage descriptions and for checking composition properties byanalyzing their metalanguage descriptions.References1. R. Allen and D. Garlan. A Formal Basis for Architectural Connection. ACM Trans-actions on Software Engineering and Methodology,6(3):213-49,19972. E. Astesiano and G. Reggio. UML-SPACES: A UML Prole for Distributed SystemsCoordinated Via Tuple Spaces.2000 .3. F. de Boer and C. Palamidessi. A Process Algebra for Concurrent Constraint Pro-gramming. Joint International Conference and Symposium on Logic Programming,pp.463-477. MIT Press.19924. A. Bracciali and A. Brogi and F. Turini. Coordinating Interaction Patterns. SAC2001. Las Vegas, Nevada. NV.5. A. Brogi and J.M. Jacquet. On the Expressiveness of Linda-like Concurrent Lan-guages Electric Notes in Theoretical Computer Science, 16. 1998.6. A. Brogi and J.M. Jacquet. On the expressiveness of Coordination Models Coor-dination Languajes and Models: 3rd InternationalConference, num. 1594 de LNCS.pp.134-149 Springer Verlag.19997. N. Busi and R. Gorrieri and G. Zavattaro. Comparing Three Semantics for Linda-like Languages Theoretical Computer Science 19988. N. Busi and R. Gorrieri and G. Zavattaro. A process algebraic view of Linda coor-dination primitives. Electronic Theoretical Computer Science, 192:167-199, 1998.9. C. Canal. Un Lenguaje para la Especicacion y Validacion de Arquitecturas deSoftware. Tesis Doctoral, Universidad de Malaga. Dpto de Lenguajes y Ciencias dela Computacion. 2001.10. C. Canal and L. Fuentes and E. Pimentel and J.M. Troya and A. Vallecillo. Ex-tending CORBA interfaces with protocols. To appear in The Computer Journal,2001.11. N. Carriero and D. Gelernter. Linda in Context. Communications of the ACM,32(4):444-458, 1989.12. D. Gelernter and N. Carriero. Coordination Languages and Their Signicance.Communications of the ACM, 35(2):97107, 1992.13. R. Milner. A Calculus of communicating systems. Springer-Verlag, 1989.

Page 314: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Compatibility of Linda Interfa es 30714. R. Milner and J. Parrow and D. Walker. A Calculus of Mobile Processes. Journalof Information and Computation, 100:1-77, 1992.

Page 315: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 316: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Pattern-based Language to Coordinate HPFTasks?Manuel Daz, Bartolome Rubio, Enrique Soler, and Jose M. TroyaDpto. Lenguajes y Cien ias de la Computa ion. Malaga University.29071 Malaga, SPAINfmdr, tolo, es , troyagl .uma.esAbstra t. This paper des ribes how to use a pattern-based approa hto integrate task and data parallelism. Coordination patterns are used toexpress task parallelism among a olle tion of data parallel HPF tasks.Patterns spe ify the intera tion among domains involved in the appli- ation along with the pro essor and data layouts. The use of domains,i.e. regions together with some intera tion information, improves pat-tern reusability. Data distribution belonging to the dierent HPF tasksis known at the oordination level. This is the key for both omputa-tional ode reutilization and an eÆ ient implementation of the ommu-ni ation among tasks. Besides that, our system implementation requiresno hange to the runtime system support of the HPF ompiler used.In addition, a set of dierent implementation templates are provided inorder to ease the programmer task. The suitability, expressiveness andeÆ ien y of the language are shown by means of some examples.Keywords: Coordination patterns, Task and data parallelism integration, Pattern and omputational ode reusability.1 Introdu tionThere has been a tenden y in the parallel programming paradigm to ignore highlevel issues, parti ularly in the area of programming model and language design.This may be reasonable sin e performan e is the main purpose of parallel pro-gramming. Currently, an important eort is being arried out in order to applystru tured programming prin iples to parallel programming. This is justied bythe experien e, as real parallel programs rarely onsist of random olle tions ofpro esses intera ting in an unpredi table way, but these intera tions are usuallywell stru tured and t a set of patterns. In this sense, in [15 a methodologyfor stru tured development of parallel software is proposed. This methodologyis based on the establishment of a xed set of patterns or onstru tors of paral-lelism, whi h are the only way to express the parallel stru ture of the program.In the same way, the oordination paradigm [6 provides parallel omputingwith a high level way of fa ing the development of parallel software. It is based on? This work was supported by the Spanish proje t CICYT TIC-99-0754-C03-03

Page 317: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

310 M. Daz, B. Rubio, E. Soler, J. M. Troyathe separation of oordination and omputational aspe ts. Coordination modelsand languages oer a good solution to the problem of managing the intera -tions among on urrent pro esses. The purpose of a oordination model and theasso iated language is to provide a mean of integrating a number of possiblyheterogeneous omponents in su h a way that the olle tive set forms a singleappli ation that an exe ute on and take advantage of parallel and distributedsystems.A resear h area that an take advantage of both stru tured parallel program-ming and oordination models and languages is the integration of task and dataparallelism. This area tries to over ome the onstrain that arises when using apure data parallel language su h as High Performan e Fortran (HPF) [12. It iswidely a epted that many important parallel appli ations annot be eÆ ientlyimplemented following a pure data parallel paradigm. For these appli ations,rather than having a single data parallel program, it is more appropriate to sub-divide the whole omputation into several data parallel pie es, where these run on urrently and o-operate, thus exploiting task parallelism. Although severalapproa hes have been proposed [10[11[19, integrating the two forms of par-allelism leanly and within a oherent programming model is diÆ ult [4. Theuse of oordination languages and stru tured parallel programming is proving tobe a good alternative, providing high level me hanisms and supporting dierentforms of task parallelism stru tures in a lear and elegant way [3[7[17.In this paper we des ribe DIP (Domain Intera tion Patterns), a new ap-proa h to integrate task and data parallelism using patterns. DIP is a high level oordination language to express task parallelism among a olle tion of dataparallel HPF tasks, whi h intera t a ording to stati and predi table patterns.Patterns spe ify the intera tion among domains involved in the appli ation, therelationship between domains and tasks, and the mapping of pro essors and datadistribution. In order to ease the programmer task, a set of dierent implemen-tation templates are provided. This way, the programmer uses a higher level ofabstra tion to manage ommuni ation and syn hronization aspe ts, and someother low level details an also be avoided in the omputational part.On the one hand, the use of domains, whi h are regions together with someintera tion information, makes the language suitable for the solution of numeri alproblems, espe ially those with an irregular surfa e that an be de omposed intoregular, blo k stru tured domains. Moreover, other kinds of problems that takeadvantage of integrating task and data parallelism and have a ommuni ationpattern based on (sub)array inter hange may also be dened and solved in aneasy and lear way. The use of domains also avoids that some omputationalaspe ts involved in the appli ation, su h as data types, have to appear at the oordination level, as it o urs in other approa hes [7[17. This improves patternreusability.On the other hand, the knowledge at the oordination level of data distri-bution belonging to the dierent HPF tasks is the key for both omputational ode reutilization and an eÆ ient implementation of the ommuni ation and

Page 318: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Pattern-based Language to Coordinate HPF Tasks 311syn hronization among them. In DIP, the inter-task ommuni ation s hedule isestablished at ompilation time.DIP implementation is based on BCL [8[9, a Border-based CoordinationLanguage fo used on the solution of numeri al problems. BCL provides a sim-ple parallelism model where oordination and omputational aspe ts are learlyseparated. The former are established using the oordination language and thelatter are oded using HPF (together with only a few extensions related to o-ordination). This way, there is a oordinator pro ess that is in harge of both reating the dierent HPF tasks and establishing the ommuni ation and syn- hronization s heme among them. In the oordination part, pro essor and datalayouts are also spe ied. BCL is implemented on top of the MPI ommuni ationlayer, but no hange to the underlying HPF ompiler has been needed.The rest of the paper is stru tured as follows. Se tion 1.1 dis usses relatedwork. DIP is des ribed in se tion 2. Se tion 3 dis usses the implementation issuesand preliminary results and, nally, in se tion 4, some on lusions are sket hed.1.1 Related workIn re ent years, several proposals have addressed the integration of task and dataparallelism. We shall state a few of them and dis uss the relative ontributionsof our approa h.In HPF/MPI [10, the message-passing library MPI has been added to HPF.In an HPF/MPI program, ea h task onstitutes an independent HPF program inwhi h one logi al thread of ontrol operates on arrays distributed a ross a stat-i ally dened set of pro essors. At the same time, ea h task is also one logi alpro ess in an MPI omputation. In our opinion, the adoption of a message-passing paradigm to dire tly express task parallelism is too low-level. Moreover,in our approa h, the inter-task ommuni ation s hedule is established at om-pilation time from the information provided at the oordination level related tothe inter-domain onne tions and data distribution. In this ase, expressivenessand good performan e are our relative ontributions.The SkIE [3 environment is also fo used on heterogeneous and multidis i-plinary appli ations and uses another oordination language (SkIECL) but, inthis ase, a pattern-based approa h is adopted. The basi idea of this integratedheterogeneous environment is to allow the rapid prototyping and developmentof omplex appli ations on several platforms. This work evolves from P3L [2,a stru tured parallel programming language that embeds a set of parallel on-stru ts expressing basi parallel paradigms into C. In SkIE, dierent sequentiallanguages for omputational tasks have been onsidered (e.g., C, C++, F77, F90,Java, ...). The user an also en apsulate parallel ode using MPI and spe ializedlibraries.Another work that evolves from P3L is taskHPF [7. It is a high level oordi-nation language to dene the intera tion patterns among HPF tasks in a de lar-ative way. Considered appli ations are stru tured as ensembles of independentdata parallel HPF modules, whi h intera t a ording to stati and predi table

Page 319: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

312 M. Daz, B. Rubio, E. Soler, J. M. Troyapatterns. taskHPH is possibly the losest proposal to DIP. However, the dier-en es are substan ial: a) we work with domains, without onsidering data typesat the oordination level, improving pattern reusability; b) our pattern pro-vides information about the future data distribution together with the pro essorlayout, whi h allows s heduling the inter-task ommuni ation pattern at ompi-lation time. On the other hand, DIP provides a multi-blo k pattern that makesthe language suitable for the solution of domain de omposition-based problemsand multi-blo k odes. Both proposals provide implementation templates. How-ever, DIP improves omputational ode reutilization as the data distribution isspe ied in the pattern instead of the task.The implementation of taskHPF is based on COLTHPF [14, a runtime sup-port spe i ally designed for the oordination of on urrent and ommuni atingHPF tasks. It is implemented on top of MPI (there is a new version using PVM)and requires small hanges to the runtime support of the HPF ompiler used.2 The DIP oordination languageDIP is a high level oordination language whi h allows the denition of a networkof ooperating HPF tasks. Tasks intera t a ording to stati and predi tablepatterns and an be omposed using predened stru tures, alled patterns. Wehave established two patterns in DIP. The multi-blo k pattern is fo used onthe solution of multi-blo k and domain de omposition-based problems, whi h onform an important kind of problems in the high performan e omputingarea. The other pattern provided by DIP is the pipeline pattern, whi h pipelinessequen es of tasks in a primitive way.DIP is based on the use of domains. HPF tasks re eive the domains theyneed and use them to establish the ne essary variables for omputation. Lo al omputations are a hieved by means of HPF senten es while the ommuni ationand syn hronization among tasks are arried out through some predened DIPprimitives. The programmer an also use a higher level of abstra tion to man-age ommuni ation and syn hronization aspe ts, by means of implementationtemplates.2.1 The MULTIBLOCK patternDomain de omposition methods are su essfully being used for the solution oflinear and non-linear algebrai equations that arise upon the dis retization ofpartial dierential equations (PDEs) [18. Programming su h appli ations is adiÆ ult task be ause we have to take into a ount many dierent aspe ts, su has: the physi s of ea h domain; the dierent numeri al methods applied; the onditions imposed at the borders; the equations used to solve them; overlappingor non-overlapping te hniques; the problem geometry, whi h may be omplex andirregular and, nally, the possible integration of task and data parallelism.In order to express this kind of problems in an easy, elegant and de larativeway, the MULTIBLOCK pattern has been dened. The following ode shows thegeneral s heme of this pattern:

Page 320: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Pattern-based Language to Coordinate HPF Tasks 313MULTIBLOCK pattern_name domain definitionstask1(domain1:(data distribution)) pro essor layout.....taskm(domainm:(data distribution)) pro essor layoutWITH BORDERSborder definitionsENDA domain denition is a hieved by means of an assignment of Cartesianpoints, i.e. the region of the domain is established. For example, in the following ode:MULTIBLOCK example u/1,1,Nxu,Nyu/, v/1,1,Nxv,Nyv/solve(u:(BLOCK,BLOCK)) ON PROCS(4,4)solve(v:(*,BLOCK)) ON PROCS(2)WITH BORDERSu(Nxu,Ny1,Nxu,Ny2) <- v(2,1,2,Nyv)v(1,1,1,Nyv) <- u(Nxu-1,Ny1,Nxu-1,Ny2)ENDthe expression u/1,1,Nxu,Nyu/ assigns to the two-dimensional domain u theregion of the plane that extends from the point (1,1) to the point (Nxu,Nyu).In general, a region will onsist of 2x numbers, where x is the problem dimen-sionality (1 x 4).Dierent borders an be dened among the spe ied domains. In the previousexample, the expression u(Nxu,Ny1,Nxu,Ny2) <- v(2,1,2,Nyv) indi ates thatthe zone of u delimited by points (Nxu,Ny1) and (Nxu,Ny2) will be updated bythe values belonging to the zone of v delimited by points (2,1) and (2,Nyv)(see Figure 1). A border denition an be optionally labeled with a numberthat indi ates the onne tion type in order to ommuni ate dierent borders indierent phases of the algorithm.In the task all spe i ation, the name of the domain to be solved by thetask and the data distribution are spe ied (optionally, an arbitrary numberof additional arguments needed by the task an also be passed). The pro essor(1,1)

u

(Nxu,Nyu)

(1,1)

(Nxv,Nyv)

v

(Nxu,Ny1)

(Nxu,Ny2)

Fig. 1. Communi ation between two HPF tasks

Page 321: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

314 M. Daz, B. Rubio, E. Soler, J. M. Troyalayout where the task is going to be exe uted is also indi ated. Ea h task is solvedby a disjoint set of pro essors. In the example above, the rst task is exe utedon a 4 4 mesh of pro essors while the se ond one, on an array of 2 pro essors.The distribution types orrespond to those of HPF. In Figure 1, dotted linesrepresent data distribution, and it shows a (BLOCK,BLOCK) distribution for uand a (*,BLOCK) for v. This de laration indi ates the future distribution ofthe data asso iated to the spe ied domain (see se tion 2.3). A task knows thedistribution of its domain and the distribution of every domain with a border in ommon with its domain by means of the information de lared in the pattern.So, the part of the border that needs to be sent to whi h pro essor of other task an be dedu ed. This is a hieved at ompilation time.2.2 The PIPE patternThe PIPE pattern pipelines sequen es of HPF tasks. The stru ture of a generaln-stage pipeline orresponding to the PIPE pattern is shown in the following ode:PIPE pattern_name domain definitionsstage1.....stagenENDEa h stage in the pipeline onsumes and produ es a data stream, ex ept therst and the last stages that only produ es and onsumes, respe tively. The datastream onsists of a number of elements. This number, i.e. the stream length,may or may not be stati ally known. Sin e our approa h is based on the useof domains, the a tual data type of the input/output hannels onne ting ea hpair of intera ting tasks, i.e. the element type, is not spe ied. This improvesthe reusability of the oordination part of the appli ation.A stage of the pipeline an be one of the following: A task all, whi h has a similar form to the task all spe i ation in theMULTIBLOCK pattern. A pipeline all, i.e. the name of a nested PIPE pattern together with thedomains it needs. A REPLICATE dire tive that is used to repli ate a non-s alable stage, whi h an be a task all or a pipeline all. This improves the pipeline throughput asdierent data sets an be omputed in parallel on dierent sets of pro essors.We use the following example to explain the dierent hara teristi s of ourPIPE pattern:PIPE nested_pipe f/1,1,N,N/task2(f:(*,BLOCK)) ON PROCS(4)task3(f:(BLOCK,*)) ON PROCS(4)

Page 322: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Pattern-based Language to Coordinate HPF Tasks 315ENDPIPE main_pipe d/1,1,N,N/, e/1,1,M,M/task1(d:(*,BLOCK)) ON PROCS(2)nested_pipe(d)task4(d:(BLOCK,*),e:(BLOCK,BLOCK)) ON PROCS(4)REPLICATE (2) task5(e:(BLOCK,*)) ON PROCS(2)task6(e:(BLOCK,*)) ON PROCS(2)ENDFigure 2 shows the graphi al s heme of the previous example. The domainsinvolved in ea h pipe are dened after the pipe name. In our example, the mainpipe uses two domains, d and e and the nested one only requires a domain f.Unlike in the MULTIBLOCK pattern, the ommuni ation between two pipe stagesis spe ied by using the same domain as argument in both stages. The stagewhere this domain rst appears is onsidered the one that generates the dataasso iated to the domain. If the same domain appears in several stages, it meansthat the intermediate stages, i.e. those dierent from the rst and the last, notonly re eive data from the previous stage but also send them (usually after some omputation) to the following stage. In the example above, task4 generatesthe data asso iated to e, task5 re eives and sends them to task6. The datadistribution of a domain must be spe ied in every stage it appears.task 1 task 2

task 5

task 3

task 5

task 6task 4d f d

e

e

e

e

f f

Fig. 2. Stru ture of the nested pipelineIn the example above, task5 is repli ated in su h a way that two instan esof this task are exe uted on two pro essors ea h. This way, task4 and task6must arry out some spe ial work due to the presen e of the repli ate stru ture.Thus, task4must dispat h the dierent elements of its output stream to the twoinstan es of task5, and task6 has to olle t the elements re eived from bothinstan es. Dierent dispat h methods an be arried out, e.g. round-robin, ondemand, et .Note that PIPE patterns allow us a high level des ription of an appli ationstru ture. A programmer an ompletely hange this stru ture by only modi-fying this on ise, simple and high level des ription, so that several alternativeimplementations an be tested and evaluated. Unlike in other proposals [7, the

Page 323: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

316 M. Daz, B. Rubio, E. Soler, J. M. Troyaabsen e of input/output dire tives improves the reutilization of simple, nestedand repli ated stages.2.3 Computational tasksA task a hieves lo al omputations by means of HPF senten es while the om-muni ation and syn hronization among tasks are arried out through some in- orporated primitives. A new type and a new attribute have also been in luded.The following ode shows the general s heme of a task:subroutine task_name(list_of_domains)domain de larationsgrid de larationsgrid distributiongrid initializationbody odeend subroutineBy means of the type DOMAINxD (1 x 4), a task de lares variables forthe re eived domains. For example, in the following task:subroutine solve(d)DOMAIN2D ddouble pre ision,GRID(d)::g,g_old!hpf$ distribute(BLOCK,BLOCK)::g,g_old all initGrid(g)do i=1,nitersg_old = gUPDATE_DATA(g) all omputeLo al(g,g_old)error = omputeNorm(g,g_old)REDUCE(error,maxim)Print *, Max norm: , errorenddoend subroutinethe expression DOMAIN2D d de lares the two-dimensional domain variable d. Weuse the attribute GRID(d) to de lare array variables asso iated to the domaind. In the previous example double pre ision,GRID(d)::g,g old de lares two-dimensional arrays of real numbers, whi h are dynami ally reated with the sizeof the domain region.The a tual data distribution is a hieved by means of the orresponding HPFdire tive. The task body of the example onsists of a loop where besides lo al omputations, ommuni ation and syn hronization aspe ts are arried out bymeans of two primitives: UPDATE DATA(g) and REDUCE. The data belonging toone task that are needed by another (as dened in the orresponding oordi-nation pattern) are inter hanged by means of the instru tion UPDATE DATA(g)

Page 324: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Pattern-based Language to Coordinate HPF Tasks 317where g is a variable with GRID attribute. This instru tion a tually alls sequen-tially PUT DATA(g) and GET DATA(g), two other primitives provided by the modelin order to send and re eive data, respe tively. The use of these two instru tionsseparately an take advantage of both the implementation of omplex ommuni- ation patterns and the overlapping of ommuni ation and omputation, whi his the key for the eÆ ien y of some appli ations. PUT DATA(g), GET DATA(g) andUPDATE DATA(g) instru tions may optionally have a se ond argument, an integernumber that represents the kind of border that is desired to be "sent" and/or"re eived" (see the MULTIBLOCK pattern).When the MULTIBLOCK pattern is used, it may be ne essary to establish er-tain ommuni ation among tasks in order to determine whether the onver-gen e riteria of a method have been rea hed. The instru tion REDUCE(vble,Pro Name) is in harge of this aspe t. vble is a s alar variable of any type andPro Name is a subroutine name. This instru tion produ es a redu tion of thes alar value used as rst argument by means of the subroutine Pro Name.Implementation templates Besides this dire t way of odifying the ompu-tational tasks, we provide a set of dierent implementation templates in order toease the programmer task. A template is a ode skeleton of an HPF task ooper-ating with other tasks a ording to a xed intera tion pattern. In order to obtainthe a tual implementation of the tasks, the templates must be instantiated byin luding programmer-provided ode. Templates are parameterized by means ofarguments to re eive this ode. In addition to Fortran predened types, we haveestablished two new argument types: HPF DECL and HPF CODE for variablede larations and HPF ode, respe tively. The system ompiler is in harge ofautomati ally arrying out this instatiation. The template argument types aidthe ompiler to dete t possible errors in the programmer spe i ation.The next two se tions des ribe the dierent templates we have initially es-tablished. A programmer an add new templates appropriated to the kinds ofappli ations he/she is dealing with.Multiblo k templatesWe have dened two implementation templates in order to generate HPFtasks for the MULTIBLOCK pattern: the Ellipti and the Paraboli templates.Both t the problem of solving PDEs by means of nite dieren e methods usingdomain-de omposition, whi h has been used in order to evaluate our approa h.Obviously, these templates are not the only ones that an be dened for thiskind of problems and more omplex templates an be established.Figure 3 shows the DIP spe i ation of the MULTIBLOCK pattern together witha task " alled" from it that solves a paraboli equation. The programmer will llthe dierent ne essary ode se tions of the task using HPF ode. The gure alsodepi ts the instantiation of the orresponding template. The template we showis organized as two nested loops. The outermost is used to evolve in the timevariable, the innermost iterates until the onvergen e onditions among domainsare a hieved. Inside this onvergen e loop, the borders among tasks are updatedby means of the UPDATE DATA instru tion. The instantiation is arried out by the

Page 325: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

318 M. Daz, B. Rubio, E. Soler, J. M. TroyaParabolic taski(domain)

#decl

variable declarations

#init

initialization code

#termination

termination condition

#preconverge

code before conv. loop

#convergence

convergence condition

#postconverge

code after conv. loop

#preupdate

code before communication

#postupdate

code after communication

#results

code to show results

end

TEMPLATE Parabolic(HPF_DECL decl;

HPF_CODE init,preupdate,postupdate,

preconverge,postconverge,

results;

LOGICAL termination

LOGICAL convergence)

decl

init

do while (.not. termination)

preconverge

do while (.not. convergence)

preupdate

UPDATE_DATA(grid)

postupdate

enddo

postconverge

enddo

results

end

provided variable declarations

variable and distribution

declarations added by the compiler

MULTIBLOCK pattern_name domain definitions

task1(domain1:(data distribution)) processor layout

.....

taski(domaini:(data distribution)) processor layout

.....

taskm(domainm:(data distribution)) processor layout

WITH BORDERS

border definitions

END

Programmer Specification

initialization code added

by the compiler

provided initialization code

Implementation TemplateFig. 3. The Paraboli template and its instantiation from DIP spe i ationDIP ompiler. The ompiler adds some ne essary information to the program-mer variable de larations and initializations before instantiating the template.From a domain denition, its distribution spe ied in the MULTIBLOCK patternand the variables de lared in the task spe i ation, the ompiler generates: a)The domain dimensionality; b) The dimensionality of the grid asso iated to thedomain; ) The distribution of the grid; d) The dynami allo ation of the grid.The rest of the programmer ode se tions are dire tly used for the templateinstantiation.Note that if the same task is alled from the MULTIBLOCK pattern but us-ing dierent data distributions, the task spe i ation will be the same and the ompiler will generate dierent instan es from the template. This way, the om-putational ode reusability is improved. On the other hand, a template may be

Page 326: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Pattern-based Language to Coordinate HPF Tasks 319independent of the problem dimensionality (1D, 2D, et .). The templates for thePIPE pattern take advantage of both hara teristi s as well.The Ellipti template we have dened only requires a loop sin e, in this ase, no time variable is taken into a ount. In this way, the programmer doesnot have to provide the termination, pre onverge and post onverge odese tions. The instantiation pro ess is similar to that shown in Figure 3.Pipeline templatesThe PIPE pattern establishes a hain of data- ow stages, whi h onsume andprodu e an input and output data stream, respe tively. Thus, the implemen-tation template of a generi stage has to be organized as a loop that re eiveselements from the input stream, exe utes some ode and sends the resulting datato the output stream.We have onsidered two dierent ases to deal with the stream length. Therst one assumes that all the stages know the stream length by means of the num-ber of iterations established by the programmer. In the se ond one, the stagesdo not know it, so that a distributed termination proto ol has been establishedasso iating a termination mark with ea h element of the stream.Figure 4 shows the implementation template where the rst approa h hasbeen onsidered. Note that we do not need spe ial templates for the rst andlast stages of the pipeline, sin e the ompiler will dedu e how many PUT DATAand GET DATA instru tions have to be introdu ed in the instantiation pro essfrom the information des ribed in the pattern and task spe i ation.When the stream length is not known by the stages, the task spe i ationdoes not need the number of iterations se tion. The loop is repeated until theend of streammark is re eived. However, with this approa h, we need a spe ialtemplate for the rst stage of the pipeline, whi h is in harge of generating themark. A logi al expression must be provided in the task spe i ation in orderto ontrol the loop of this rst stage.Finally, when the REPLICATE dire tive is used, the round-robin poli y hasbeen onsidered. Thus, when the number of iterations is provided, the ompilerautomati ally de ides how many iterations have to be done by ea h instan e ofthe repli ated stage. On the other hand, when the stream length is unknown, theTEMPLATE Stage_it(HPF_DECL decl;

HPF_CODE init,computation;

INTEGER number_of_iterations)

decl

init

do iteration=1,number_of_iterations

GET_DATA(grids)

computation

PUT_DATA(grids)

enddo

end Fig. 4. The Stage template. The stream length is known

Page 327: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

320 M. Daz, B. Rubio, E. Soler, J. M. Troya ompiler introdu es spe ial ode for the stages before (emitter) and after ( ol-le tor) the repli ated stage. Thus, when the emitter sends the end of streammark at the end of its exe ution, it must a tually send as many marks as in-stan es in the repli ated stage. In the same way, the olle tor must re eive theend of stream marks from all the instan es before sending its own mark.3 Implementation issues and resultsIn order to evaluate the performan e of DIP, a prototype has been developed ona luster of 4 DEC AlphaServer 4100 nodes inter onne ted by means of MemoryChannel. Ea h node has 4 pro essors Alpha 22164 (300 MHz) sharing a 256 MBRAM memory. The operating system is Digital Unix V4.0D (Rev. 878).The implementation is based on sour e-to-sour e transformations togetherwith the ne essary libraries and it has been realized on top of the MPI ommu-ni ation layer and the publi domain HPF ompilation system ADAPTOR [5.The DIP ompiler translates DIP ode into BCL ode. As mentioned in se tion 1,BCL is a previous work and it has inspired dierent aspe ts of DIP.If it is required, the DIP ompiler will use the implementation templates togenerate the BCL ode. The BCL ompiler translates the ode into an SPMDprogram that takes advantage of the task region HPF 2.0 fa ility, so that theworker pro esses an be exe uted on dierent pro essor subsets. Communi a-tion among worker pro esses are a hieved by means of alls to the BCL library(BCLIB), whi h is implemented on top of MPI. The resulting HPF program is ompiled by the ADAPTOR ompiler.Several examples have been used to test the prototype and the obtainedpreliminary results have su essfully proved the eÆ ien y of the proposal. Ta-ble 1 shows the results obtained for a system of two non-linear rea tion-diusionequations. A detailed explanation of this problem and the employed numeri almethod an be found in [16. The equations are solved for an irregular domainde omposed in three regular subdomains. Dierent grid sizes have been onsid-ered (for example, in the rst row, the grid sizes of ea h subdomain are 64 64,32 32 and 64 64, respe tively). For both HPF and DIP implementations, 5,9 and 16 pro essors have been onsidered. In the ase of HPF, all the pro essorsexe ute ea h domain. In the ase of DIP, when 5 pro essors are used, 2 of themexe ute the rst subdomain, 1 the se ond and 2 the last one; for 9 pro essors, themapping is 4/1/4 and for 16 pro essors it is 7/2/7. Note that when 5 pro essorsare used, the one exe uting the se ond subdomain is idle most of the time sin eits total number of grid points is 1/4 of the other two domains. However, DIPoers a better performan e than HPF ex ept when the problem size be omeslarger. In the rest of tested ases, DIP is better than HPF.Table 2 shows the exe ution time per input array for HPF and DIP imple-mentations of the 2-D FFT appli ation. Given an NN array of omplex values,a 2-D FFT entails performing N independent 1-D FFTs on the olumns of theinput array, followed by N independent 1-D FFTs on its rows. In order to in-

Page 328: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Pattern-based Language to Coordinate HPF Tasks 321Table 1. Computational time (in hours) for the non-linear rea tion-diusion equationsGrid Sizes Sequential HPF vs. DIP5 Pro essors 9 Pro essors 16 Pro essors64/32/64 0.21 0.28/0.16 0.31/0.14 0.29/0.13128/64/128 2.07 1.34/1.05 1.16/0.67 1.05/0.54256/128/256 21.12 11.14/11.88 8.88/7.14 6.87/4.31Table 2. Computational time (in millise onds) and HPF/DIP ratio for the 2-D FFTproblem Array Size Sequential HPF vs. DIP4 Pro essors 8 Pro essors 16 Pro essors32 32 1.507 0.947/0.595 0.987/0.475 1.601/0.92164 64 5.165 2.189/1.995 1.778/1.082 2.003/1.095128 128 20.536 7.238/7.010 5.056/4.081 4.565/2.905 rease the solution performan e and s alability, a pipeline solution s heme ispreferred as proved in [10 and [7.Results are given for dierent problem sizes. Again, the performan e of DIPis generally better. However, HPF performan e is near DIP as the problem sizebe omes larger and the number of pro essors de reases, as it also happens inother approa hes [10. In this situation HPF performan e is quite good and so,the integration of task parallelism does not ontribute so mu h.The third example has been taken from the NAS Parallel Ben hmark [13. Itis the Fourier Transform (FT) to solve a 3-D diusion equation. As in the previ-ous example, a pipeline s heme is preferred [1 in order to improve the solutionperforman e by means of the overlapping of ommuni ation and omputation.In addition, our solution takes advantage of another level of parallelism as thetime step iterations are independent sin e the result of one iteration is not usedfor the next one. We a hieve this by means of the REPLICATE dire tive. Tables 3and 4 show the results onsidering dierent number of instan es in the repli atedstage (R) and data sizes. Sin e ea h stage is exe uted on at least one pro essor,the version with R=4 an not be exe uted on 4 pro essors as there are two stagesper repli a. We an observe in table 3 that for small data sizes, DIP is betterthan HPF. As in the previous examples, the better results are generally for thegreater number of pro essors. On the other hand, as the number of instan esgrows, the performan e improves ex ept in the ase where the repli ation avoidsthe integration of task and data parallelism (e.g. 8 pro essors and R=4). As thedata size grows (table 4), HPF performan e is better that DIP in the ases wherefew pro essors are used or only task parallelism is arried out.

Page 329: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

322 M. Daz, B. Rubio, E. Soler, J. M. TroyaTable 3. Computational time (in millise onds) for the NPB-FT problemNPB-FT 32x32x32. Sequential 94.7Pro essors HPF DIP R=1 DIP R=2 DIP R=44 37.5 35.4 35.38 33.4 23.8 20.7 22.616 43.5 37.3 19.8 15.0Table 4. Computational time (in millise onds) for the NPB-FT problemNPB-FT 64x64x64. Sequential 999Pro essors HPF DIP R=1 DIP R=2 DIP R=44 339 388 4808 239 207 211 27816 213 118 113 1484 Con lusionsA new pattern-based approa h to integrate task and data parallelism has beenproposed. The main advantage of this approa h is to supply programmers witha on ise, pattern-based, high level de larative way to des ribe the intera tionamong HPF tasks. The use of domains and the establishment of data and pro- essor layouts at the oordination level allow pattern reusability and eÆ ientimplementations, respe tively. Patterns allow a high level des ription of an ap-pli ation stru ture and the programmer an modify it by means of simple hangesin the patterns. The approa h also provides the programmer with implementa-tion templates, so that a higher level of abstra tion to manage ommuni ationand syn hronization aspe ts and omputational ode reusability an be a hieved.By means of some examples we have shown the expressiveness and suitabilityof the model. The evaluation of a prototype has also shown the eÆ ien y of theapproa h.Referen es1. Agarwal, R.C., Gustavson, F.G., Zubair, M., An EÆ ient Parallel Algorithm forthe 3-d FFT NAS Parallel Ben hmark, Pro eedings of SHPCC'94 (1994) 129133.2. Ba i, B., Danelutto, M., Pelagatti, S., Vannes hi, M., P3L: A Stru tured HighLevel Programming Language and its Stru tured Support, Con urren y: Pra ti eand Experien e, 7 (1995) 225255.3. Ba i, B., Danelutto, M., Pelagatti, S., Vannes hi, M., SkIE: A HeterogeneousEnvironment for HPC Appli ations, Parallel Computing, 25(13-14) (1999) 18271852.4. Bal, H.E., Haines, M., Approa hes for Integrating Task and Data Parallelism, IEEECon urren y, 6(3) (1998) 7484.

Page 330: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

A Pattern-based Language to Coordinate HPF Tasks 3235. Brandes, T., ADAPTOR Programmer's Guide, Te hni al do umentation, GMD-SCAI, Germany (1999).6. Carriero, N., Gelernter, D., Coordination Languages and their Signi an e, Com-muni ations of the ACM, 35(2) (1992) 97107.7. Ciarpaglini, S., Fol hi, L., Orlando, S., Pelagatti, S., Perego, R., Integrating Taskand Data Parallelism with taskHPF, Pro eedings of the International Conferen eon Parallel and Distributed Pro essing Te hniques and Appli ations (PDPTA'2000)(CSREA Press, Las Vegas, Nevada, 2000) 24852492.8. Daz, M., Rubio, B., Soler, E., Troya, J.M., BCL: A Border-based CoordinationLanguage, Pro eedings of the International Conferen e on Parallel and DistributedPro essing Te hniques and Appli ations (PDPTA'2000) (CSREA Press, Las Vegas,Nevada, 2000) 753760.9. Daz, M., Rubio, B., Soler, E., Troya, J.M., Integration of Task and Data Par-allelism: A Coordination-based Approa h, Pro eedings of the International Con-feren e on High Performan e Computing (HiPC'2000) (Bangalore, India, 2000),volume 1970 of LNCS, Springer-Verlag 173182.10. Foster, I., Kohr, D., Krishnaiyer, R., Choudhary, A., A library-based approa h totask parallelism in a data-parallel language, J. of Parallel and Distributed Com-puting, 45(2) (1997) 148158.11. High Performan e Fortran Forum, High Performan e Fortran Language Spe i a-tion version 2.0 (1997).12. Koelbel, C., Loveman, D., S hreiber, R., Steele, G., Zosel, M., The High Perfor-man e Fortran Handbook (MIT Press, 1994).13. Numeri al Aerodynami Simulation. NAS Parallel Ben hmark, NPB version 2.3.NASA Ames Resear h Center. Moett Field, California (2000).14. Orlando S., Perego, R., COLTHPF A Run-Time Support for the High-Level Co-ordination of HPF Tasks, Con urren y: Pra ti e and experien e, 11(8) (1999)407434.15. Pelagatti, S., Stru tured Development of Parallel Programs (Taylor&Fran is, Lon-don, 1997).16. Ramos, J.I., Soler, E., Domain De omposition Te hniques for Rea tion DiusionEquations in Two-Dimensional Regions with Re-entrant Corners, Applied Mathe-mati s and Computation, 118(2-3) (2001) 189221.17. Rauber, T., Runger, G., A Coordination Language for Mixed Task and Data Par-allel Programs, Pro eedings of the 14th Annual ACM Symposium on Applied Com-puting (SAC'99), Spe ial Tra k on Coordination Models (ACM Press, San Antonio,Texas, 1999) 146155.18. Smith, B., Bjrstard, P., Gropp, W., Domain De omposition. Parallel MultilevelMethods for Ellipti P.D.E.'s (Cambridge University Press, 1996).19. Subhlok, J., Yang, B., A New Model for Integrated Nested Task and Data ParallelProgramming Pro eedings of the 6th ACM SIGPLAN Symposium on Prin iplesand Pra ti e of Parallel Programming (PPoPP'97) (Las Vegas, Nevada, 1997) 112.

Page 331: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci
Page 332: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Reasoning about Probabilisti andNondeterministi Pro esses ?Diego Cazorla, Fernando Cuartero, Valentn Valero, Fernando L. PelayoEs uela Polite ni a Superior de Alba eteUniversidad de Castilla-La Man ha02071 Alba ete, Spainfd azorla, fernando, valentin, fpelayoginfo-ab.u lm.esAbstra t. In this paper we present an algebrai language for the spe -i ation of probabilisti and nondeterministi pro esses, PNAL , whi his a probabilisti extension of nite EPL (EPLf) that maintains nonde-terminism.We have dened both an operational and a testing semanti s for PNAL,as well as a denotational semanti s and a proof system. We show thatthe equivalen e between nondeterministi pro esses in EPLf is preserved,and we also prove that the testing semanti s, the denotational semanti sand the proof system are fully abstra t.1 Introdu tionThe fundamentals of pro ess algebras were established in the eighties but onlyqualitative aspe ts of on urrent systems were onsidered in these pioneeringworks. Subsequently quantitative aspe ts have been proposed, and several ex-tensions to lassi al pro ess algebra models have been developed in luding time,priorities and probabilities.Severeal models for probabilisti pro esses have been presented in [18, 7, 12,3, 4, 15. Nevertheless, the main idea in all these models onsists of substitut-ing a nondeterministi behaviour by a probabilisti one in whi h the dierenttypes of behaviours are quantied with probabilities. A pre ise knowledge ofthe probabilities asso iated with ea h behaviour is therefore required to dene apro ess. However, in pra ti e, this probability distribution ould be ompletelyor partially unknown.It is also ne essary therefore to provide operators that allow us to deal withnondeterminism, but, at the same time, taking into a ount the probabilisti aspe ts. In the pro ess of modelling a on urrent system we sometimes nd non-deterministi behaviours that an be quantied (for instan e, the probability of afaulty ommuni ation hannel failing), whereas on other o asions these nonde-terministi behaviours annot be quantied (for instan e, relative speed between? This work has been partially supported by the CICYT proje t \Performan e Eval-uation of Distributed Systems", TIC2000-0701- 02-02.

Page 333: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

326 D. Cazorla, F. Cuartero, V. Valero, F.L. Pelayotwo pro esses). This is why we need a language that allows us to model nonde-terministi systems with or without quanti ation, depending on the nature ofthe system in question.In line with these ideas, in [21 a probabilisti extension of CCS is presented.The language adds a probabilisti hoi e operator (p) indexed with a prob-ability p 2 (0; 1), whi h models the probabilisti internal hoi e, whereas theoriginal CCS hoi e (+) is maintained for representing nondeterminism. A test-ing semanti s, based on De Ni ola and Hennessy testing, is presented. This workis taken further in [10, 11, where these preorders are redened and denotationals hara terization for maytesting and musttesting are presented.In [13 a probabilisti extension of CSP (PCSP) that maintains nondeter-minism is introdu ed. The model is provided with an operational semanti s, andseveral denotational semanti s are given, based on dierent kinds of observations(tra e, broom and barb semanti s), where semanti obje ts are trees with threekinds of nodes: probabilisti , nondeterministi and a tion nodes.Another probabilisti extension of CSP is presented in [14, where a deno-tational semanti s of CSP is dened by applying the probabilisti powerdomain onstru tion of Jones and Plotkin [9 over a dire ted omplete partial order.Probabilisti pro esses are onsidered to be probability distributions over pro- esses of CSP.Based on ACP, we an ite [1. In that paper, a probabilisti version of ACP ispresented leading to a language that ombines probability and nondeterminism.An operational semanti s is dened based on the alternating model [7. In the onstru tion of the term models they use a probabilisti bisimulation showingsoundness and ompleteness of the term model with respe t to the proposedaxiom systems.Dierent approa hes, in the eld of probabilisti automaton and Markovde ision pro esses, are onsidered in [17, 16, 19 where the separation betweennondeterministi and probabilisti behaviour is a hieved by means of adversaries,s hedulers or poli ies, whi h resolve the nondeterminism.The spe i aim of this paper is to add probabilisti hoi e to Hennessy'sEPLf [8, to show how the semanti s of that an be dened, and to investigatethe resulting pro ess algebra.The paper is stru tured as follows. Se tion 2 introdu es our language. InSe tions 3 and 4 an operational semanti s and a testing semanti s are presented.In Se tion 5 a denotational semanti s is given by means of nite probabilisti a eptan e trees and we prove that the denotational semanti s is fully abstra twith respe t to the testing semanti s. In se tion 6 a sound and omplete proofsystem is presented. Finally, in se tion 7 we evaluate the work and ompare itwith other approa hes.2 PNAL languageThe syntax of the language we present, PNAL, is based on EPLf (EPL withoutre ursion) [8 and provides three kinds of hoi e: lassi al internal hoi e, denoted

Page 334: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Reasoning about Probabilisti and Nondeterministi Pro esses 327by , lassi al external hoi e, denoted by + , and a probabilisti hoi e labelledby a probability p: p.Let be a set of input a tions, = fa j a 2 g their orresponding outputa tions, and A t = [. Furthermore we assume a set of pro ess variables Idranged over by X and Y . Terms of PNAL are dened by:P ::=0 j X j a:P j P P j P + P j P p P j P jP j PnAwhere a 2 A t; p 2 (0; 1), X 2 Id, and A .The lassi al operators are interpreted in the usual fashion and the proba-bilisti hoi e has a generative interpretation, i.e., P p Q behaves like P withprobability p, and like Q with probability 1 p, this de ision been made inter-nally.In order to deal with probabilities and nondeterminism we have to de idehow to solve a situation where both hoi es appear. In the literature availablewe have, basi ally, two alternatives: in [1, 14, 21 probabilisti hoi es are solvedrst, whereas in [13 the opposite approa h is taken. Note that this de isionis not at all meaningless, be ause, depending on the approa h adopted, someproperties of lassi al pro ess algebras will be preserved or not. For example,idempoten y of internal hoi e is only maintained when internal hoi e is resolvedrst. Idempoten y of external hoi e is never maintained, be ause if we takeP = a 0:5 b, we nd that P P in rements the probability of a, for any modelwe onsider.In all these models we an identify two kinds of nondeterminism: nonde-terminism introdu ed by internal hoi e (synta ti nondeterminism), and non-determinism introdu ed by external hoi e and parallel omposition betweenpro esses prexed by the same a tion. Let us onsider the following example(using PNAL syntax): (a:P j (a:Q p b)) RIf we onsider Lowe's approa h [13, we rst resolve internal hoi e and later( onsidering the left hand side pro ess) probabilisti hoi e; at this point wend a nondeterministi behaviour introdu ed by the pro ess a:P ja:Q, and theresolution of this nondeterminism is delayed after the exe ution of a tion a.But, in Lowe's words (si ) \it is not enough to resolve all nondeterminism ina given state before the probabilisti hoi es; we have to resolve all nondeter-minism before any probabilisti hoi e ... an we nd a model that is (faithfulto our intuition)?.Su h a model would need to ensure that all nondeterministi bran hing o urs before any other bran hing, but it is far from obvious how towrite down the semanti equations so as to a hieve this". This is still, indeed,an open problem.If we onsider the approa h taken by Morgan et al. [14, probabilisti hoi eis resolved rst, and later on both kinds of nondeterminism an be resolved.Moreover, in that model we nd the opposite behaviour, i.e., every probabilisti hoi e must be resolved before any internal hoi e. But, in the model in question,probabilisti hoi e is distributed through all the other operators, so this aim an be a hieved easily.

Page 335: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

328 D. Cazorla, F. Cuartero, V. Valero, F.L. PelayoTaking into a ount both models [13, 14, and the study of asyn hronousprobabilisti parallel omposition introdu ed in [5 (where \bundle probabilisti transition systems" are introdu ed), we onsider that the more suitable approa his to resolve probabilisti hoi e rst, and then resolve any kind of nondetermin-ism later on. As we will see in the following se tions, this de ision leads us to amodel that shares some hara teristi s with the Morgan et al. [14 model (e.g.,distribution properties of probabilisti hoi e).3 Operational semanti sThe operational semanti s is dened in the usual way, by using a labelled tran-sition system. In order to understand these rules we require a preliminary de-nition:Denition 1 (Probabilisti stability)We dene in an indu tive way the probabilisti stability predi atei) 0 and a:P are probabilisti ally stable.ii) P Q, P + Q, P jQ are probabilisti ally stable i both P and Q are.iii) PnA is probabilisti ally stable i P is.We use P # to denote that P is probabilisti ally stable.Transition rules are divided into 3 tables. Table 1 denes the probabilisti hoi eoperator behaviour, by using probabilisti transitions, like P !p Q, whi hmeans that P may evolve to Q with probability p immediately. Rules P1a andP1b indi ate that pro ess P p Q behaves like P with probability p and likeQ with probability 1 p. The remaining rules establish the pre eden e of theprobabilisti hoi e with respe t to the other operators. Pro esses P and Q aresupposed to be probabilisti ally independent pro esses in rules P2 , P3 , andP4 , like in [1, 7, 21.The behaviour of the remaining operators is presented in Tables 2 and 3,where we assume that pro esses are now probabilisti ally stable. The se ond ta-ble denes the rules for unlabelled transitions, i.e., those representing an internalevolution, P ! Q, with the usual meaning that P may evolve internally to Qwithout performing any visible a tion. Rules I1a and I1b show how the internal hoi e operator behaves. Rules I2a, I2b, I3a and I3b indi ate that internal hoi edistributes over the external hoi e and parallel omposition. Rule I3 indi atesthat an unbarred a tion may syn hronize with its homologous barred a tion andthe obtained pro ess evolves internally. Finally, rule I4 shows the operationalbehaviour for the restri tion operator.The third table denes the inferen e rules for transitions labelled with a tionsin A t, P a! Q, with the usual meaning that P an perform and a and moveto Q.Denition 2 The operational semanti s of PNAL is dened as the multiset oftransitions we an derive by using the rules in Tables 13.Throughout the paper we will use instead of !p, ! and a! in orderto represent any of these transitions.

Page 336: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Reasoning about Probabilisti and Nondeterministi Pro esses 329P1a P p Q !p P P1b P p Q !1p Q P2a P !p P 0; Q#P Q !p P 0 QP2b P #; Q !q Q0P Q !q P Q0 P2 P !p P 0; Q !q Q0P Q !pq P 0 Q0 P3a P !p P 0; Q#P + Q !p P 0 + QP3b P #; Q !q Q0P + Q !q P + Q0 P3 P !p P 0; Q !q Q0P + Q !pq P 0 + Q0 P4a P !p P 0; Q#P jQ !p P 0jQP4b P #; Q !q Q0P jQ !q P jQ0 P4 P !p P 0; Q !q Q0P jQ !pq P 0jQ0 P5 P !p P 0PnA !p P 0nATable 1. Probabilisti transitionsI1a P Q ! P I1b P Q ! Q I2a P ! P 0P + Q ! P 0 + QI2b Q ! Q0P + Q ! P + Q0 I3a P ! P 0P jQ ! P 0jQ I3b Q ! Q0P jQ ! P jQ0I3 P a! P 0; Q a! Q0P jQ ! P 0jQ0 I4 P ! P 0PnA ! P 0nATable 2. Unlabelled transitionsA1 a:P a! P A2a P a! P 0P + Q a! P 0 A2b Q a! Q0P + Q a! Q0A3a P a! P 0P jQ a! P 0jQ A3b Q a! Q0P jQ a! P jQ0 A4 P a! P 0PnA a! P 0nA (a; a 62 A)Table 3. Transitions labelled with a tions4 Testing semanti sA test is just a pro ess whi h additionally may perform a spe ial a tion w toreport a su essful state. A purely probabilisti pro ess P will pass a test T witha ertain probability p. But, when dealing with nondeterministi pro esses, i.e.,in luding internal hoi es, we will have to ompute a set of probabilities to passea h test, in order to apture all the possibilities to do that.As usual, in order to relate two pro esses using the testing semanti s, wetake one of them as a spe i ation and the other one as its implementation. Wewill say that a pro ess is a good implementation of a spe i ation if the rangeof probabilities with whi h the implementation passes every test is in luded inthe range of probabilities with whi h the spe i ation passes the same test.

Page 337: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

330 D. Cazorla, F. Cuartero, V. Valero, F.L. PelayoWe use PkT to stand for (P jT )nA t. PkT is a pro ess that an only performprobabilisti transitions !p, unlabelled transitions ! or wtransitions w!.These pro esses are alled test pro esses and will be represented by S, S0, et .Given a pro ess P and a test T , (P;T ) will represent the set of probabilitiesfor a epting T onsidering ea h possible evolution of PkT . In order to dene(P;T ) we need some preliminary denitions, following similar ideas to thosepresented in [21.Denition 3 A resolution R of PkT is a maximal subtree of PkT su h that,whenever S ,! S1, S ,! S2, we have S1 = S2, where ,! represents either !or w!.Therefore, every nondeterministi node in a resolution has a unique output ar .Denition 4 A omputation C of a test pro ess S is a maximal sequen e oftransitions, S S1 : : : Si1 Si : : : where represents either !p, ! orw!.We will use the following notation:R(S) denotes the set of resolutions of S, C(R)denotes the set of omputations of resolution R, Pr(C) denotes the probabilityto rea h a su essful state along the omputation C, and Pr (R) denotes theprobability to rea h a su essful state in the resolution R.Denition 5 A omputation C = S S1 Si1 Si : : : Sn is a su ess-ful omputation if Sn w! and Sk w6! for all k < n. We use bC(R) to denote theset of su essful omputations of R. We may ompute the probability for C to bea su essful omputation as follows:Pr (Sn w! Sn+1) = 1 (su ess)Pr (Si ! C) = Pr(C)Pr (Si !p C) = p Pr(C)And the probability to get a su ess in a resolution: Pr (R) = XC2bC(R)Pr(C)Denition 6 Given a pro ess P and a test T , we say that P may pass T withthe set of probabilities (P;T ) = fPr(R) j R 2 R(PkT )g.Now we may introdu e the test preorder over pro esses, by using (P;T ).Denition 7 We dene the test preorder as follows:P vtest Q if 8T s.t. (P;T ) 6= f0g; then (Q;T ) 6= f0g;supf(P;T )g supf(Q;T )g; and inff(P;T )g inff(Q;T )gThis preorder impose that whenever Q annot a ept a test T , P annot a eptit either. This has been introdu ed be ause, a ording to the denition of testpreorder given in [10, the pro esses P = a and Q = a are related under the

Page 338: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Reasoning about Probabilisti and Nondeterministi Pro esses 331test preorder, i.e., P vtest Q. On the ontrary in Hennessy's testing P may :wbut Q may= :w so P 6vmay Q. A ording to our denition both situations are aptured.The test relation has the following interpretation: P vtest Q if Q is a goodimplementation of the spe i ation P . The orresponding equivalen e is denedas follows:Denition 8 P test Q if and only if P vtest Q and Q vtest P5 Denotational semanti sThe aim of this se tion is to provide our language with a fully abstra t deno-tational semanti s with respe t to the testing semanti s. Our domain will be aset of nite probabilisti a eptan e trees, fPAT. Let us informally des ribe thestru ture of these trees: We will onsider trees with two kinds of nodes: probabilisti (), and non-deterministi (). The root node is a probabilisti one and probabilisti and nondeterministi nodes appear in an alternative way. Nondeterministi nodes are labelled with an a eptan e set (as dened in[8), while probabilisti nodes are unlabelled. Bran hes leaving a probabilisti node are labelled with probabilities pi, withPi pi = 1. Every bran h leaving a nondeterministi node is labelled withone a tion in the a eptan e set, but there are not two bran hes labelledwith the same a tion. Terminal nodes are always nondeterministi , and are labelled with the a - eptan e set f;g.We an see that these trees are quite similar to those used in [8, but nowwe have to extend these trees in order to in lude the probabilisti informationasso iated with every rea hable state. Let us introdu e now a eptan e sets andprobabilisti a eptan e sets.Denition 9 An a eptan e set A is a subset of P(A t). Let D(A) be the do-main of a eptan e sets for a given set of a tions A t .We say that (p;A) is a\probabilitya eptan e set pair" if (p;A) 2 (0; 1D(A).Let A be an a eptan e set. We dene A(A), the set of a tions belonging toA, as follows: A(A) = fa 2 A t j 9B 2 A s.t. a 2 BgDenition 10 A probabilisti a eptan e set, PA, is dened as follows:PA = f(pi;Ai) 2 (0; 1D(A) jXi pi = 1 ^Ai 6= Aj if i 6= jgThe domain of probabilisti a eptan e sets is represented by D(PA).

Page 339: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

332 D. Cazorla, F. Cuartero, V. Valero, F.L. PelayoDenition 11 We dene the probability distribution, indu ed by a probabilisti a eptan e set, as the fun tion : D(A)D(PA) ! [0; 1 given by(A;PA) = p if (p;A) 2 PA0 otherwiseDenition 12 Let PA be a probabilisti a eptan e set. We dene the set ofa eptan e sets belonging to PA as follows:A ept(PA) = fA 2 D(A) j 9p s.t. (p;A) 2 PAgWe will use the following notation:C = fa j a 2 Cg and AnC = fB (C [ C) j B 2 Ag.Besides the denitions above, we will need two additional operators borrowedfrom [8: operators and u. Due to the la k of spa e, we will not give here theirformal denitions. Instead, we will remember their informal meaning: is the onvex losure of a set, and u is the pointwise union of sets of sets.We may now dene (see Table 4) the probabilisti a eptan e set of ea hpro ess at the top level, PA(P ). Parallel omposition will be studied separatelybe ause extra explanation is needed.PA(0) = f(1; f;g)g PA(a:t) = f(1; ffagg)gPA(t1 q t2) = f(p;A) j A 2 A ept(PA(t1)) _ A 2 A ept(PA(t2));p = q (A;PA(t1)) + (1 q) (A;PA(t2))gPA(t1 t2) = f(p;A) j 9B 2 A ept(PA(t1)); 9C 2 A ept(PA(t2)) s.t. A = (B [ C);p = XA= (B[C)(B;PA(t1)) (C;PA(t2))gPA(t1 + t2) = f(p;A) j 9B 2 A ept(PA(t1)); 9C 2 A ept(PA(t2)) s.t. A = B u C;p = XA=B u C (B;PA(t1)) (C;PA(t2))gPA(tnC) = f(p;A) j A = BnC ^ p = XA=BnC (t;B)gTable 4. Probabilisti a eptan e set of a semanti pro essThe probabilisti a eptan e set dened allows us to distinguish between thedierent rea hable states, and also provides us with the probability asso iatedwith every state.Let us now introdu e the semanti pro ess t=(A; a), whi h models the be-haviour of t, on e it has exe uted the a tion a at the state given by A. We denet=(A; a) as follows:

Page 340: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Reasoning about Probabilisti and Nondeterministi Pro esses 333 If t is a pro ess su h that either a 62 A(A) or A 62 A ept(PA(t)) thent=(A; a) is not dened. If t = a:t1, the only rea hable state is fag with probability 1. Thent=(fag; a) = t1. t = t1 q t2. We must distinguish several sub ases: A 2 A ept(PA(t1)) and A 62 A ept(PA(t2)). In this ase only t1 anexe ute the a tion a, so t=(A; a) = t1=(A; a). A 62 A ept(PA(t1)) and A 2 A ept(PA(t2)). It is the symmetri ase:t=(A; a) = t2=(A; a). A 2 A ept(PA(t1)) and A 2 A ept(PA(t2)). Now a an be made eitherby t1 or t2, then: t=(A; a) = t1=(A; a) q t2=(A; a) t = t1 t2. We have that, a ording to the denition of PA for the internal hoi e operator, ea h one of its states, A, is obtained as the onvex losureof a union of states, A = (B [ C), where B 2 A ept(PA(t1)) and C 2A ept(PA(t2)). Then, we an distinguish the following ases: a 2 A(B) and a 62 A(C). Then, it is t1 whi h exe utes a, and thus:t=(A; a) = t1=(B; a). a 62 A(B) and a 2 A(C). Symmetri ase: t=(A; a) = t2=(C; a). a 2 A(B) and a 2 A(C). Either t1 or t2 exe ute the a tion, then:t=(A; a) = t1=(B; a) t2=(C; a)Therefore, as A may be obtained from several dierent sets B and C, wehave: t=(A; a) = MB;C; (B[C)=Aa2A(B)^a62A(C) t1=(B; a) MB;C; (B[C)=Aa62A(B)^a2A(C) t2=(C; a)MB;C; (B[C)=Aa2A(B)^a2A(C) t1=(B; a) t2=(C; a) t = t1 + t2. We have that every state A is built as A = B u C, whereB 2 A ept(PA(t1)) and C 2 A ept(PA(t2)), and we an repeat the same ase distin tion as in the internal hoi e, thus obtaining exa tly the sameexpression for t=(A; a). tnC. If a 2 C then (tnC)=(A; a) is not dened. If a 62 C then:(tnC)=(A; a) = OA=BnC (t;B)(tnC;A) (t=(B; a))nCOn e we have dened the probabilisti a eptan e sets of a pro ess, not onlyfor its rst a tion, but all over its possible exe utions, we are interested in allthe possible sequen es of a tions it an perform. Let us now introdu e somenotation for that. As ea h probabilisti node in the tree representing t an berea hed by following a sequen e of pairs (a eptan e set, a tion), due to thealternating nature of these trees, we may identify these nodes by t(s), where

Page 341: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

334 D. Cazorla, F. Cuartero, V. Valero, F.L. Pelayos = hA1; a1; : : : ;Ak; aki is the sequen e leading us to the node. We an usea similar notation for synta ti al terms. Then, (P=(A; a)) =(B; b) will be repre-sented shortly by P=(hA; a;B; bi)Parallel omposition.The denition of the fun tion over fPAT orrespond-ing to j is quite diÆ ult, and a onsiderable amount of notation is needed. Wewill introdu e intuitively the on epts related to this operator. Its formal de-nition is in luded in the extended version of this paper [2, available via worldwide web.Let us onsider the pro esses P1 = a:( 0:4e)0:3b, P2 = a:d and P = P1jP2.In gure 1 we an see the fPAT of P1, P2 and the rst level of P1jP2.fag 0:3af g0:4 ;1feg0:6e;1

fbg0:7b;1fag1afdg1d;1 (ff ; dgg [ ffa; a; ; dgg)0:12 (ffe; dgg [ ffa; a; e; dgg)0:18 ffa; bgg0:7Fig. 1. fPAT of P1, P2 and rst level of P1jP2In the rst level, P may perform the a tions that P1 or P2 may performat their rst level. Besides, in ase of ommuni ation between P1 and P2, somea tions of the following level in P1 and P2 are promoted to the rst one inP . We have to onsider all the possibilities, i.e., every a tion may or may not ommuni ate with its homologous barred a tion, and this introdu ed some kindof nondeterminism.In this example, a tions a and a may ommuni ate, so se ond level a tion,like , e and d may be performed at the rst level. Let us onsider that a anda ommuni ate, and the probabilisti hoi e after a tion a in P1 is resolvedfollowing the bran h labelled with probability 0:4. In this ase, with probability0:3 0:4 = 0:12, the semanti pro ess P rea hes a nondeterministi a eptan eset A su h that A(A) = fa; a; ; dg. In ase of ommuni ation, only a tions and d may be performed. Nondeterminism is introdu ed in A onsidering the onvex losure of the union of sets f ; dg and fa; a; ; dg.

Page 342: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Reasoning about Probabilisti and Nondeterministi Pro esses 335Denition 13 We dene the sequen es of P , denoted by Seq(P ), as the setof all the sequen es of pairs (a eptan e set,a tion) that we may obtain from[[P fPAT.Denition 14 We say that two pro esses are equivalent a ording to the deno-tational semanti s, whi h will be denoted by [[P fPAT = [[QfPAT, i: Seq(P ) = Seq(Q), and For every sequen e s, PA(P=(s)) = PA(Q=(s)).We now state that this equivalen e relation between probabilisti pro esses is anextension of that presented in [8 for nondeterministi pro esses.Theorem 1 Let P;Q 2 EPLf be two pro esses.[[P fAT = [[QfAT if and only if [[P fPAT = [[QfPATAlso, we have that both the testing semanti s and the denotational semanti sidentify the same pro esses, i.e., the denotational semanti s is fully abstra t withrespe t to the testing semanti s.Theorem 2 Let P;Q 2 PNALf be two pro esses, then[[P fPAT = [[QfPAT if and only if P test Q6 Proof systemIn this se tion we present a proof system, whi h is sound and omplete withrespe t to the denotational semanti s. This proof system is based on that ofEPLf, by in luding the axioms related with the probabilisti hoi e operator.Nevertheless, some of the axioms of EPLf are not preserved in the general ase.For instan e, the internal and the external hoi e now fail to beidempotent, and distributivity of the internal over the external hoi e (andvi e versa) is not maintained. However, these axioms an be used when we areworking with a spe ial kind of pro esses (probabilisti ally stable pro esses) andthey are very useful when proving ompleteness.Table 5, ontains the set of axioms related to the following operators: 0,prex and the three hoi es. Axioms in Table 5 show that probabilisti hoi eis ommutative (P1), asso iative in a probabilisti way (P2), and idempotent(P3). These axioms allow us to generalize probabilisti hoi e to an arbitrarynumber of arguments. Thus we an write Ni[piPi to denote a probabilisti hoi e among n pro esses, ea h one with probability pi > 0. Other rules say thatprobabilisti hoi e is propagated to the following level when both pro esses areprexed by the same a tion (P4), and that the probabilisti hoi e distributesover the internal and the external hoi e (PI1, PE1).Let us observe that the axioms maintained from EPLf are: the internal andthe external hoi e are ommutative and asso iative (I1,I2,E1,E2), the external

Page 343: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

336 D. Cazorla, F. Cuartero, V. Valero, F.L. Pelayo hoi e has a zero (E3), and, nally, the internal and the external hoi e betweenpro esses prexed with the same a tion are propagated to the following level(I3,IE1). The rest of axioms (those with the symbol #), do not hold in the gen-eral ase, but if we restri t P , Q and R to a kind of pro esses, whi h we allprobabilisti ally stable pro esses, they be ome true. These axioms are: idempo-ten y of the internal and the external hoi e (I4#, E4#) , and distributivity of theinternal hoi e over the external hoi e and vi e versa (IE3#, IE4#).P1 P p Q Q 1p PP2 (P p Q) q R P pq (Q (1p)q1pq R)P3 P p P PP4 a:P p a:Q a(P p Q)PI1 P (Q p R) (P Q) p (P R)PE1 P + (Q p R) (P + Q) p (P + R)I1 P Q Q PI2 P (Q R) (P Q) RI3 a:P a:Q a(P Q)E1 P + Q Q + PE2 P + (Q + R) (P + Q) + RE3 P + 0 PIE1 a:P + a:Q a:P a:QI4# P P PE4# P + P PIE3# P + (Q R) (P + Q) (P + R)IE4# P (Q + R) (P Q) + (P R)Table 5. Axioms for 0, prex and hoi e operatorsWe may also apply, over probabilisti ally stable pro esses, the derived equa-tions given in [8, whi h are useful to prove ompleteness. Finally, in Table 6 we an see the axioms for restri tion and parallel omposition, whi h, as usual, arederived operators. In rule PaE1, the fun tion omm(P;Q) (dened in [8) is falseif there is not any possibility of ommuni ation between P and Q.Note that axioms PaI1 and PaE1, whi h are introdu ed in [8, hold onlyfor pro esses in EPLf. Applying repeatedly P4, PI1, PE1, ReP1, and PaP1(distribution axioms) every pro ess in the form P jQ may be transformed intoNi;j [pi qj PijQj , where Pi; Qj 2 EPLf.ReE1 (P + Q)nC = PnC + QnC ReI1 (P Q)nC = PnC QnCRe1 a:PnC = a:(PnC) if a 62 C _ a 62 C0 otherwise Re01 0nC = 0ReP1 (P q Q)nC = PnC q QnC PaP1 P j(Q q R) = (P jQ) q (P jR)Pa01 0jP = P PaI1 (P Q)jR = P jR QjR; P;Q;R 2 EPLfPaE1if P;Q are PfaiPi; i 2 Ig, PfbjQj ; j 2 JgthenP jQ = 8<: ext(P;Q) if omm(P;Q) is false(ext(P;Q) + int(P;Q)) int(P;Q)otherwise where int(P;Q) =LfPijQj ; ai = bjgext(P;Q) =Pfai(PijQ); i 2 Ig+Pfbj(P jQj); j 2 Jg,and P;Q 2 EPLfTable 6. Axioms for restri tion and parallel ompositionTheorem 3 Axioms are sound with respe t to the denotational semanti s.

Page 344: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Reasoning about Probabilisti and Nondeterministi Pro esses 337As usual, to prove the ompleteness, we look for the adequate normal forms.Essentially, these normal forms represent the dierent ways a pro ess has to omplete its exe ution. This leads us to a generalized probabilisti hoi e at thetop, followed by a generalized internal hoi e among a set of states, whi h isfollowed by a generalized prexed external hoi e among the a tions in this set,whose ontinuations are also in normal form.Denition 15 (Normal forms) Pro ess 0 is in normal form. if Ai is a onvex set and for every a 2 A(Ai) there is a normal form n(Ai; a),then Oi [qi MA2AiXa2A a:n(Ai; a)is a normal form.These normal forms share some hara teristi s of lassi al models (CSP, EPL),as well as some hara teristi s of other probabilisti models [4. Thus, the on-tinuations after performing the same a tion in dierent probabilisti bran hesdo not need to be identi al (usual in probabilisti models), and the a eptan esets Ai must be onvex as usual in lassi al models.Lemma 1 Every term in PNAL an be transformed, by using the given proofsystem, into another equivalent term in normal form.Theorem 4 Let P;Q 2 PNAL be two pro esses, then [[P fPAT = [[QfPAT ifand only if P QFinally, by using theorems 2 and 4, we an relate the proof system with thetesting semanti s as follows:Corollary 1 Let P;Q 2 PNAL be two pro esses, thenP test Q if and only if P Q7 Con lusions and omparisonsIn this paper we have presented an algebrai theory of probabilisti and non-deterministi pro esses whi h is a probabilisti extension of Hennessy's theorypresented in [8. An operational and a testing semanti s have been introdu ed,as well as a denotational semanti s and a proof system. The testing semanti s,the denotational semanti s and the proof system are shown to be fully abstra t.To our knowledge, this paper is the rst that presents a general framework ofprobabilisti and nondeterministi pro esses based on Hennessy's model. Similarapproa hes have been presented, based on dierent lassi al pro ess algebras.Thus, in [1 an operational semanti s, a probabilisti bisimulation and a proofsystem are introdu ed for a probabilisti extension of ACP. In [14, a denotational

Page 345: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

338 D. Cazorla, F. Cuartero, V. Valero, F.L. Pelayosemanti s and a proof system are introdu ed for a probabilisti extension of CSP.In [13, only an operational and a denotational semanti s are dened for anotherprobabilisti version of CSP whi h does not in lude a hiding operator. Finally,in [21, 10 a probabilisti extension of CCS is presented, and an operationalsemanti s, a testing semanti s and a denotational semanti s are dened.In order to deal with probabilism and nondeterminism we have hosen anapproa h that onsiders that a probabilisti hoi e is resolved before an internal hoi e. Thus, the transition system we obtain is very similar to \bundle prob-abilisti transition systems" (BPTS) presented in [5, whi h are the onverseof the simple model of [17, 16. In our ase (as in BPTS), a set of nondeter-ministi alternatives is hosen with a ertain probability, while in [17, 16, ana tion is hosen nondeterministi ally and then, for ea h a tion, a distribution ofprobabilities over the su essor states is given (rea tive probabilisti hoi e).A similar operational semanti s is dened in [21, but in this ase some ofthe premises of the rules in lude negative onditions over transitions, whi h isproblemati (see [6). In our model we have avoided this problem by introdu ingthe \probabilisti stable" predi ate, whi h is dened synta ti ally.The de ision of resolving probabilisti hoi es rst leads us to a model inwhi h some of the properties of lassi al pro ess algebras are not maintained.For instan e, the internal hoi e now fails to be idempotent, as the followingexample shows. Let P be the pro ess a:0 0:5 b:0, we then have:PA(P ) =f(0:5; ffagg); (0:5; ffbgg)gPA(P P ) =f(0:25; ffagg); (0:25; ffbgg); (0:5; ffag; fbg; fa; bgg)gThis is, however, a known onsequen e of introdu ing probabilities and nonde-terminism by taking the approa h of rst resolving the probabilisti hoi es. Ween ounter the same problem in some of the aforementioned papers [1, 14, 21,and also in [20, where a probabilisti extension of CCS is presented by intro-du ing intervals of probabilities that allow us to spe ify pro esses with un ertaininformation.The normal forms are dened in a very natural way. They onsist in a gen-eralized probabilisti hoi e at the top, followed by a generalized internal hoi ebetween a set of states, whi h is followed by a generalized prexed external hoi e between the a tions in this set, whose ontinuations are also in normalform. But, as we ould see in Se tion 6, distribution axioms allow us to denean alternative normal form that onsists in a probabilisti hoi e followed by anonprobabilisti pro ess in EPLf's normal form, i.e., ea h probabilisti hoi emust be resolved before any internal hoi e. The same on lusion is obtained in[14 for a probabilisti extension of CSP.Finally, the proof system we have obtained is very similar to Andova's proofsystem [1. One noteworthy feature is that, in her ase, the proof system is soundand omplete with respe t to probabilisti bisimulation, while in our ase it issound and omplete with respe t to the testing semanti s.

Page 346: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci

Reasoning about Probabilisti and Nondeterministi Pro esses 339Referen es1. S. Andova. Pro ess algebra with probabilisti hoi e. In Pro eedings of ARTS'99,LNCS 1601, 1999.2. D. Cazorla, F. Cuartero, V. Valero, and F.L. Pelayo. A pro ess algebra for proba-bilisti and nondeterministi pro esses. Te hni al Report DIAB-00-01-11, UCLM,2000. http://www.info-ab.u lm.es/se -ab/Te rep/diab000111.ps.3. F. Cuartero, D. de Frutos, and V. Valero. PCSP: A denotational model for prob-abilisti pro esses. In Pro eedings of Third AMAST Workshop on Real-Time Sys-tems, 1996.4. F. Cuartero, D. de Frutos, and V. Valero. A sound and omplete proof system forprobabilisti pro esses. In ARTS'96, LNCS 1231, 1997.5. P.R. D'Argenio, H. Hermanns, and J.-P. Katoen. On generative parallel omposi-tion. Ele troni Notes in Theoreti al Computer S ien e, 22:25, 1999.6. J.F. Groote. Transition system spe i ations with negative premises. Theoreti alComputer S ien e, 118:263299, 1993.7. H. Hansson and B. Jonsson. A al ulus for ommuni ating systems with time andprobabilities. In Pro eedings Real-Time Systems Symposium, Orlando, Florida,1990.8. M. Hennessy. Algebrai Theory of Pro esses. MIT Press, 1988.9. C. Jones and G.D. Plotkin. A probabilisti powerdomain of evaluations. In Pro- eedings of 4th Annual Symposium on Logi in Computer S ien e, 1989.10. B. Jonsson and W. Yi. Compositional testing preorders for probabilisti pro esses.In 10th IEEE Symposium on Logi in Computer S ien e, pages 431443, San Diego,Ca., 1995.11. B. Jonsson and W. Yi. Fully abstra t hara terization of probabilisti may testing.In 5th Int. AMAST Workshop on Real-Time and Probabilisti Systems, ARTS'99,1999.12. K.G. Larsen and A. Skou. Bisimulation through probabilisti testing. Informationand Computation, 94(1):128, 1991.13. G. Lowe. Representing nondeterministi and probabilisti behaviour in rea tivepro esses. Te hni al Report PRG-TR-11-93, Oxford university omputing labora-tory, 1993.14. C. Morgan, A. M Iver, K. Seidel, and J.W. Sanders. Renement-oriented proba-bility for CSP. Formal Aspe ts of Computing, 8(6):617647, 1996.15. M. Nu~nez, D. de Frutos, and L. Llana. A eptan e trees for probabilisti pro esses.In CONCUR'95, LNCS 962, pages 249263, 1995.16. R. Segala. A ompositional tra e-based semanti s for probabilisti automata. InPro eedings of CONCUR'95, LNCS 962, 1995.17. R. Segala and N. Lyn h. Probabilisti simulations for probabilisti pro esses. InPro eedings of CONCUR'94, LNCS 836, 1994.18. R. van Glabbeek, S.A. Smolka, and B.U. Steen. Rea tive, generative ans stratiedmodels of probabilisti pro esses. Information and Computation, 121(1):5980,1995.19. M.Y. Vardi. Automati veri ation of probabilisti on urrent nite-state pro-grams. In Pro eedings of 26th FOCS, pages 327338, 1985.20. W. Yi. Algebrai reasoning for real-time probabilisti pro esses with un ertainty in-formation. In Formal Te hniques in Real-Time and Fault-Tolerant Systems, LNCS863, pages 680693, Kiel, Germany, 1994.21. W. Yi and K.G. Larsen. Testing probabilisti and nondeterministi pro esses. InProto ol Spe i ation, Testing and Veri ation XII, pages 4761, 1992.

Page 347: I JORNADAS SOBRE PROGRAMACIÓN Y LENGUAJES · Jornadas sobre Programaci on y Lengua jes (PR OLE 2001) celebradas en Almagro los d as 23 y 24 de No viem bre 2001, ba jo la organizaci