attribute grammar paradigms--a high-level methodology in language implem...

Attribute Grammar Paradigms — A High-Level Methodology inLanguage Implementation

JUKKA PAAKKI

Department of Computer Science and Information Systems, University of Jyvashyla,

P. O. Box 35, SF-40.351 Jyvaskyla, Fudand

Attribute grammars are a formalism for specifying programming languages. They have

been applied to a great number of systems automatically producing language

implementations from their specifications. The systems and them specification

languages can be evaluated and classified according to their level of application

support, linguistic characteristics, and degree of automation,

A survey of attribute grammar-based specification languages is given. The modern

advanced spemtlcation languages extend the core attribute grammar model with

concepts and primitives from established programming paradigms. The main ideas

behind the developed attribute grammar paradigms are discussed, and representative

specification languages are presented with a common example grammar. The

presentation M founded on mappmg elements of attribute grammars to their

counterparts in programming languages. This methodology of integrating two

problem-solving disciplines together is explored with a classification of the paradigms

into structured, modular, object-oriented, logic, and functional attribute grammars.

The taxonomy is complemented by introducing approaches based on an implicit parallel

or incremental attribute evaluation paradigm.

Categories and Subject Descriptors: D. 1.1 [Programming Techniques]: Applicative

(Functional) Programming; D. 1.3 [Programming Techniques]: Concurrent

Programming; D. 1.4 [Programming Techniques]: Sequential Programming; D.1 5

[Programming Techniques]: Object-Oriented Programming; D.1.6 [Programming

Techniques]: Logic Programming; D.2.2 [Software Engineering]: Tools and

Techniques—modules and Interfaces; programmer workbench; structured

progrczmmmg; D.3.1 [Programming Languages]: Formal Definitions and Theory:D.3.3 [Programming Languages]: Language Constructs and Feature s—a&~i-act data

types; concurrent programming structures; modules, packages; procedures, functtons,

subroutines, and recurszon; D.3.4 [Programming Languages]: Processors—compilers;

interpreters; translator wrztmg systems and compiler generators; F.4.2 [MathematicalLogic and Formal Languages]: Grammars and Other Rewriting Systems; K.2[History of Computing]: Software

General Terms: Design, Languages, Theory

Additional Key Words and Phrases: Attribute grammars, blocks, classes, compiler

wrltmg systems, functional dependencies, recomplete data, mcrementality, inheritance,

language processing, language processor generators, lazy evaluation, logical variables,

objects, parallelism, processes, programming paradigms, semantic functions, symbol

tables, unification

Permission to make di~tal\hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that copies are not made or dmtrlbuted for profit or commercial advantage, thecopyright notice, the title of the publication and its date appear, and notice is given that copying is bypermission of ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists,requires prior specific permission and/or a fee.

@ 1995 0360-0300/95/0600-0196 $03.50

ACM Computmg Surveys, Vol. 27, No, 2, June 1995

Attribute Grammar Paradigms ● 197

CONTENTS

INTRODUCTION

1 ATTRIBUTE GRAMMARS

1.1 Hlstorlcal Remarks

12 Deflmtion and Basic Notations

1.3 Characteristic Graphs

2. ORGANIZATIONAL PARADIGMS

21 Attribution Paradigms

22 Structured Attribute Grammars

23 Modular Attribute Grammars

2.4 Object-Oriented Attribute Grammars

3. EVALUATION PARADIGMS

3.1 Logic Attribute Grammars

3.2 Functional Attribute Grammars

3.3 Impluut Paradigms

4. CONCLUSIONS

ACKNOWLEDGMENTS

REFERENCES

INTRODUCTION

The evolutionary development of thecomputing discipline has createdmethodologies and systems to solve prob-lems effectively in many different specialareas. The value of such application-specific methods has proved to be great-est in areas that are mature enough forbeing systematically engineered.

Often the methods designed for a cer-tain application area are useful in otherareas (after some adaptation), or differ-ent techniques can be combined withinthe same area. To integrate differenttechniques into a seamless whole, it isnecessary to foresee the effects of theircombination. Hence, full understandingof the concepts and mechanisms of thecomponents is the prerequisite for a sen-sible integration. One example of thisapproach is the current interest inmultiparadigm programming languages.The foundation for designing and imple-menting such languages is provided bywell-established single programmingparadigms; for an overview, see ACMComputing Surveys [1989], Sethi [1989],and Watt [1990].

Compiler construction is often men-tioned as one of the few really systemati-cally managed disciplines, e.g., Shaw[1990]. This stems from the relatively

long tradition of producig compilers, frompractical underlying theories, and from alarge selection of textbooks on the topic,such as Aho et al. [1986] and Fischer andLeBlanc [1988]. Today, producing compil-ers (or at least their analysis phase, the“front-end”) is routine work with auto-matic tools.

Context-free grammars are the stan-dard tool used in reference manualsfor defining the syntax of programminglanguages. The accompanying lexical def-inition of the language is usually givenusing regular expressions, another popu-lar specification formalism. The practicalsignificance of these formalisms is greatlyenhanced by the fact that they can beautomatically implemented as efficientlanguage processors, context-free gram-mars as parsers, and regular expressionsas lexical analyzers.

Attribute grammars were defined inthe late 1960’s by Knuth for specifyingand implementing the (static) semanticaspects of programming languages[Knuth 1968]. Since then, attributegrammars have been a subject of inten-sive research, both from a conceptual andfrom a practical point of view. The con-ceptual work has produced several sub-classes of attribute grammars withadvanced implementation algorithms.The closely coupled pragmatic effortshave created a large number of auto-mated systems based on attribute gram-mars. These systems, usually calledcompiler-compilers, compiler writing sys-tems, or translator writing systems, gen-erate different kinds of language proces-sors from their high-level specifications.In their early years the systems wereused to generate compilers only, but latergenerators of interpreters, debuggers, ed-itors, etc. have shown that the attributegrammar model provides a basis for anumber of alternative language process-ing schemes as well.

Research on attribute grammars hasrefined their somewhat primitive origi-nal notion into a mature formalism. Thematurity can be seen from fairly efficientimplementation algorithms of attributegrammars, and also from the large num-

ACM Computmg Surveys, Vol 27, No 2, June 1995

198 “ Jukka Paakki

ber of systems produced. Each systemhas its own specification language, in asense a special dialect of attribute gram-mars. Like programming languages,these dialects can be classified accordingto their fundamental ideas and primi-tives. In this survey we systematicallyinvestigate conceptual attribute gram-mar classes that can be characterizedwith the term attribute ~rammarparadigm, giving rise to a ta~onomy oflanguage specification styles all based onthe attribute grammar model.

Extensive reviews of attribute mam-mar theory, implementation, systems,and applications are given in, e.g.,Deransart et al. [1988], Deransart andJourdan [1990], and Alblas andMelichar [1991]. This survey does notthoroughly discuss such issues, nor themethodology of applying attribute gram-mars in the specification and implemen-tation of programming languages.Rather, we focus on the paradigms, mo-tivating and presenting the main ideasbehind them. The conceptual presenta-tion is comdemented with examdes ofthe differen~ paradigms in terms ~f somespecific systems that support theseparadigms in their specification lan-guage. We hope that the examples alsodemonstrate the attribute grammarmethodology for an uninitiated reader.

An attribute grammar-based specifica-tion language is also a language itself, aspecial-purpose programming languagein the application area of language pro-cessing. Therefore, an attribute grammarparadigm must involve issues both fromthe attribute grammar model and fromthe programming language discipline.Thus, an attribute grammar paradigmis a good example of integrating two dif-ferent problem-solving methodologies,specification and programming, into acoherent combination. We believe thatthis explicit case of integration also showsthe power of establishing new practicaland rigorous methods by assembling twoexisting mature disciplines together.

We start in Section 1 by presentingattribute grammars in their standardform. The merits and drawbacks of thebasic concept are discussed; the draw-

backs motivate paradigmatic improve-ments presented in the subsequentsections.

In our taxonomy, attribute grammarstyles are classified into paradigms ac-cording to the particular linguisticframework they promote. These frame-works either aid in structuring an at-tribute grammar into integrated units orimprove the semantic expressiveness ofattribute grammars by employing somepowerful attribute evaluation machinery.Respectively, the survey presents organi-zational paradigms in Section 2 andevaluation paradigms in Section 3. Theclass of organizational paradigms is fur-ther refined into attribution paradigms,structured attribute grammars, modularattribute grammars, and object-orientedattribute grammars in Sections 2.1 to 2.4,respectively. The evaluation paradigm iselaborated by presenting logic attributegrammars, functional attribute gram-mars, and implicit evaluation paradigmsin Sections 3.1 to 3.3, respectively. Weconclude in Section 4 by summarizingand relating the merits of the differentparadigms, and by envisaging future di-rections.

The contributions of the differentparadigms vary according to their mainemphasis and characteristics. In essence,the organizational paradigms raise thesoftware engineering level of the meta-languages based on attribute grammars.The evaluation paradigms, on the otherhand, stress the semantic expressivenessof attribute grammars. Finally, efficiencyof the generated language processors isthe main concern of the special implicitparadigms.

1. ATTRIBUTE GRAMMARS

Here we present the basic characteristicsof attribute grammars. Some historicalmilestones and central application areasare mentioned in Section 1.1. Section 1.2gives the definition of attribute gram-mars. Section 1.3 presents the fundamen-tal concept of characteristic (dependency)graphs that lay the foundation for bothanalyzing and implementing attributegrammars. An example grammar is given


Attribute Grammar Paradigms 0 199

as well to illustrate the formalism and toserve as a common basis for presentingthe paradigmatic variations of the stan-dard model.

1.1 Historical Remarks

Designing a programming language is anintellectual challenge of considerablecomplexity (for an overview, see Wasser-man [1980]). One of the most importantconsiderations is the description of thelanguage. The description must be illus-trative enough for a language user, andprecise enough for a langaage implemen-tor. Several language definition for-malisms have been developed. The mostsuccessful has been the Backus-NaurForm, sometimes also referred to as theBackus-NormaI Form (BNF).

BNF was originally presented fordefining the programming languageAlgol 60 [Naur 1960] and is based on thenotion of context-free grammars, whichhave been generally accepted as thestandard formalism for defining the syn-tax of programming languages. Regularexpressions are another standard formal-ism, used for specifying the lexical struc-ture of programming languages.Context-free grammars and regular ex-pressions were presented already in the1950’s in connection with the seminallinguistic work of Chomsky [ 1959].

The scope of regular expressions andcontext-free grammars soon extendedfrom theoretical language definition intopractical compiler generation. Subclassesof context-free grammars were definedfor automatic generation of efficient syn-tax analyzers from syntax definitions, themost notable examples being LR gram-mars [Knuth 1965] and LL grammars[Lewis and Stearns 1968]. Additionally,mapping regular expressions into finiteautomata made it feasible to generatelexical analyzers automatically.

While a consensus on the definitionand generation formalisms has beenreached with respect to the first twophases of a typical language implementa-tion (lexical analysis, syntactic analysis),the subject is more controversial whenconsidering the remaining phases

(semantic analysis, code generation, in-terpretation). Hence, a variety of differ-ent formalisms has been proposed for thedefinition of the semantics of program-ming languages and for the automaticgeneration of complete language imple-mentations from such definitions.

The most formal methods have a math-ematical foundation providing conceptsfor writing unambiguous and consistentdefinitions. Denotational semantics andaxiomatic semantics are two well-knownexamples of this kind. The former is basedon the use of functions mapping the con-structs of a language directly to theirmathematical meanings, while the latteremploys logical axioms and deductionrules for specifying the language. Tech-niques labeled commonly as operationalsemantics define a language by mappingits constructs into instructions of a sim-ple abstract interpreter whose semanticsis well defined. An introductory survey oflanguage definition formalisms is givenin, e.g., Watt [1991].

Attribute grammars are probably themost widely applied semantic formalism.This method is founded upon the idea ofa “syntax-directed translation scheme”where a context-free grammar is aug-mented with attributes and semanticrules. Because attribute grammars are aproper extension of context-free gram-mars, an efficient implementation is eas-ier to obtain from a language definitiongiven as an attribute grammar than onefrom one of the more mathematically bi-ased formalisms mentioned above. On theother hand, attribute grammars are lessformal and less expressive than themathematical models because the func-tions applied in the semantic rules arenot precisely defined.

Attribute grammars have graduallydeveloped from a theoretical concept intoan advanced computational paradigm.The definition of the formalism was givenin Knuth [1968]; the evolution of ideasbehind the formalism is summarizedin Knuth [1990]. The first decade ofresearch focused on analyzing the char-acter of attribute grammars and onestablishing basic implementation algo-rithms. The first full implementation was

ACM Computmg Surveys, Vol 27, No. Z, June 1995


produced by Fang [1972] under the su-pervision of Knuth. Attribute grammarswere soon found to be an attractive toolfor modeling passwise compilationstrategies, Seminal results in this direc-tion include four attribute grammar sub-classes: S-attributed grammars andL-attributed grammars for one-pass com-pilation [Lewis et al. 1974], and abso-lutely noncircular attribute grammars[Kennedy and Warren 1976] and orderedattribute grammars [Kastens 1980] formultipass compilation.

Several systems were developed withhigh-level input languages, resulting inpowerful language processing tools. Ex-ample pioneer systems in this directionare GAG [Kastens et al. 1982],LINGUIST-86 [Farrow 1982], and HLP84[Koskimies et al. 1988]. In recent yearsresearch has shifted from theoretical in-vestigations into improving attributegrammars as a methodology, and intodesigning systems with major emphasison pragmatic issues. This tendency is alsoreflected in this survey, which aims atpresenting the main directions of devel-oping attribute grammars into a true en-gineering discipline.

While implementation of (textual) pro-gramming languages is the original andmost widely studied area of attributegrammars, they can also be used in manyother fields where relations among struc-tured information play a central role. Thisversatility is demonstrated by an in-creasing number of new application ar-eas where attribute grammars have beenpromoted to having significant value. Re-cent notable examples include generalsoftware engineering [Shinoda andKatayama 1988; Frost 1992; Lewi et al.1992], reactive systems [Ding andKatayama 1993], distributed program-ming [Kaiser and Kaplan 1993], logicprogramming [Deransart and Maluszyn-ski 1985; 1993], static analysis of pro-grams [Horwitz and Reps 1992],databases [Ridjanovic and Brodie 1982],natural language interfaces [Alexin et al.1990], graphical user interfaces and vi-sual programming [Hudson and King1987; Crimi et al. 1990], pattern recogni-

tion [Tsai and Fu 1980; Trahanias andSkordalakis 1990], hardware design

[Jones and Simon 19861, computer com-munication protocols [van de Burgt andTilanus 1989; Chapman 1990], and com-binatorics [Delest and Fedou 1992].

1.2 Definition and Basic Notations[Knuth 1968]

An attribute grammar ( AG) consists ofthree components, a context-free gram-mar G, a finite set of attributes A, and afinite set of semantic rules R : AG =

(G, A, R ). Informally, G specifies thesyntax of the target langaage, and A andR specify the (static) semantics of thelanguage.

A context-free grammar G is a quadru-ple: G = (N, T, P, D), where N is a fi-nite set of nonterminal symbols; T is afinite set of terminal symbols; P is afinite set of productions; and D = N isthe designated start symbol of G. Anelement in V = N u T is called a gram-mar symbol. The productions in P arepairs of the form X + a, where X = Nand a = V*, i.e., the left-hand side X isa nonterminal, and the right-hand side ais a string of grammar symbols. An emptyright-hand side (empty string) is repre-sented by the symbol c.

A finite set of attributes A(X) is asso-ciated with each symbol X E V. The setA(X) is partitioned into two disjoint sub-sets, the inherited attributes I(X) andthe synthesized attributes S(X). The startsymbol and the terminal symbols do nothave inherited attributes. 1 Now A =uA(X).

1The original definition in Knuth [1968] acceptsterminal symbols to have inherited attributes butno synthesized attributes. While this is in line with

the general dlsclphne of associating attributes withgrammar symbols, the rule has been reversed inmost Implementations, The reason for acceptingjust synthesized attributes for terminal symbols ismodularizatlon of language processors: now the ter-minal symbols become context-independent, and the

lexical analyzers can be generated independently ofthe other components. As this survey uses exmtingsystems to demonstrate the different paradigms,we also have adopted the nonstandard conventionin our definition



A production p = P, p : XO -+ Xl . . . X.

(n > O), has an attribute occurrence X,.a,if a c A(X, ), O g i s n. A finite set ofsemantic rules R.P is associated with the

production p with exactly one rule foreach synthesized attribute occurrenceXO .a and exactly one rule for each inher-ited attribute occurrence X,. a, 1 < i < n.Thus RP is a collection of rules of theform X,.a = f(yl,. . . . yh), k >0, where

(1) either i = O and a c S(X,), or 1< is n and a 6 1(X,);

(2) each Yj, 1< .j s k, is an attributeoccurrence in p; and

(3) f is a function, called a semanticfunction, that maps the values of

Y12 ...7 yk to the value of X,.a. In arule X,.a = f(yl, . . . . yk ), the occur-rence XL. a depends on each occur-rence y], 1 <j < k. NOW R = URP.

By the definition, synthesized attributesare output to the left-hand-side symbolsof productions, and inherited attributesare output to the right-hand-side sym-bols. (The synthesized attributes ofterminal symbols are assumed to be ex-ternally defined.)

A derivation tree (parse tree) for a pro-gram L??,generated by G = (N, T, P, D),is a tree, where

(1) each node is labeled by a symbol X =

(2)

(3)

(4)

An

V or by s;

the label of the root is D;

if a node labeled by X has the sonslabeled by Xl,. . . . X., then X -+xl.. . Xn is a production in P; and

the labels of the leaves of thetree, concatenated from left to right,form d’.

attributed tree for a program @ is aderivation tree for @ where each node n,labeled by X, is attached with attributeinstances that correspond to the at-tributes of X. For each attribute a =A(X) the corresponding instance is de-noted with n. a.

Attribute evaluation is a process thatcomputes values of attribute instanceswithin an attributed tree T according tothe semantic rules R. That is, the value

of an attribute instance n. a., correspond-ing to attribute a of symbol Y, is com-puted by executing the semantic ruleY.a = f(yl,..., yk) = RP where either (1)

a e KY) and p is the production X --+. . . Y... applied when generating n intoT, or (2) a G S(Y) and p is the produc-tion+ . . . applied when generating ninto T. The semantic rule is executed bycalling the function f with the values ofthose attribute instances as argumentsthat correspond to yl, ..., yk, and by as-signing the returned value to n.a. As forattribute occurrences, the instance n.a.is defined to depend on all the instancesforyl, ..., yk. The m-+? of a program@ consists of the values of the (synthe-sized) attribute instances associated withthe root node of the attributed tree for @.

Prior to the definition of attributegrammars, synthesized information andpurely syntax-directed language process-ing were considered as the “proper” formof programming language semantics[Irons 1961; Steel 1966]. From a purelytheoretical point of view, inherited at-tributes are unnecessary [Knuth 1968].They are, however, useful in many prac-tical situations, e.g., in representing sym-bol tables whose value is typicallyapplied outside of the creating context.Inherited attributes also introduce an at-tractive conceptual balance into the com-pilation process, and that is why they arewidely employed in systems that gener-ate multipass evaluators over the at-tributed tree.

An attribute grammar AG = (G, A, R)is well defined if the semantic rules Rare such that for each attributed tree Tfor a program & (generated by G), thevalues of the attribute instances withinT can be unambiguously computed by anattribute evaluation process. In Knuth[1968] this criterion is stated such thatthe attribute dependency graph for T,induced by R, is acyclic.z In other words,

‘An attribute dependency graph for an attributed

tree T has the attribute instances within T as itsvertices. The graph contains a directed arc from n. bto ma if and only if the attribute instance n.a

depends on the attribute instance n. b.

ACM Computing Surveys, Vol. 27, No. 2, June 1995


attribute instances must have a partialevaluation ordering, and no attribute in-stance may (transitively) depend on it-self.

This requirement guarantees that it isalways possible to find an execution or-der for semantic functions such that thevalue of each attribute instance is com-puted exactly once, and each function ap-plies previously evaluated argumentsonly. In other words, the standard at-tribute evaluation model is strict. Whilethis strategy based on noncircular at-tribute dependencies is the traditionalmethod, it is not the only possible one. InSection 3 we will discuss mechanismsthat are based on the intuition that themain objective of an attribute evaluationprocess is not to compute the value of allthe attribute instances within T, but in-stead just the meaning of the corre-sponding program &. This requirementis weaker than that given above andmakes it possible to have a broader inter-pretation of well-defined attribute gram-mars. Another relaxation of the originalmeaning of being well defined, also ad-dressed in Section 3, is based on the useof nonstrict functions and incomplete val-ues in attribute evaluation.

1.3 Characteristic Graphs

The general noncircular property of at-tibute grammars requires an exponentialtesting algorithm [Jazayeri et al. 1975].Also, implementing attribute grammarsin their most general form is very hard.These aspects call immediately for relax-ing the ultimate goal of applying at-tribute grammars in their full power andthus make it necessary to discover re-stri cted yet powerful subclasses of theformalism.

In this section we introduce the con-cept of characteristic (dependency)graphs that make it possible both to de-fine more practical attribute grammarclasses and to design effective implemen-tation strategies for them. The basic ideabehind characteristic graphs is to assem-ble the attribute dependency informationstatically into a single representation

that holds for all the possible attributedtrees for the grammar. A universal de-pendency description makes it possible toanalyze the characteristic properties ofan attribute grammar and the corre-sponding language processor withoutconsidering the concrete source pro-grams. We will only give an introductionto the topic; for a more detailed presenta-tion, refer to Deransart et al. [1988] andAIblas [1991],

To simplify the discussion, we adoptthe conventional restriction that the ap-plied attribute occurrences yl, ..., yk fora semantic rule X,. a = f(yl, ..., y~) inRP must be defined outside of the pro-duction p: XO + Xl ..- X.. That is, foreach yj of the form X1. b,j = 1,. ,., k,

either 1 = O and b = l(Xl), or 1 < 1 < nand b G S(X1 ). If this holds for all thesemantic rules of the attribute grammar,it is in normal form [Bochmann 1976].Unless otherwise stated, the attributegrammars in this survey are assumed to

be in normal form.3The main building blocks of character-

istic graphs are the local dependencygraphs DGP. A graph DGP summarizesthe attribute dependencies associatedwith the production p: XO + X1 “”” X.:

the vertices of DGP are the attributeoccurrences of p;

for each pair of attribute occurrencesX,.a and ‘X .b of p, there is a directedarc from ~J.b to X,.a in DGP if andonly if X, .a depends on Xl. b.

The local dependency graphs already laythe foundation of two important sub-classes of attribute grammars:

(1) An attribute grammar is S-attributedif it has only synthesized attributes(hence for each arc from XJ.b to X1.ain any DG the following conditionshold: i = ~ and 1< j < n) [Lewiset al. 1974].

3This is not a severe restriction since every (well-defined) attribute grammar can be put in normalform by a simple transformation

ACM Computmg Surveys, Vol 27, No. 2, June 1995

Attribute Grammar Paradigms w 203

(2) An attribute grammar is L-attri-buted if for each arc from X~..b toX,.a in any DG , where 1<1< n

(and thus a G I(XL )), the followingcondition holds: j < i [Lewis et al.1974; Bochmann 1976].

While these classes seem very primitive,they have turned out to be surprisinglypractical in a large number of languageprocessor generators. For instance YACC[Johnson 1975], probably the most well-known language implementation tool, canbe regarded as an implementation ofsimple S-attributed grammars. A moreprofound motivation for S-attributed andL-attributed grammars is that they canbe considered as models of one-pass lan-guage processing, e.g. one-pass compil-ation, where semantic information isproduced in one traversal over an attri-buted tree and in most cases even inter-leaved with syntax analysis.

More complex language processingtasks must be solved with attributegrammar classes more general than S-attributed and L-attributed grammars.In essence, in such cases there must besome means to analyze global attributedependencies instead of just the localones, as above.

Consider the inherited attributes of asymbol as its input and the synthesizedattributes as its output. Then the input-output behavior of a (nonterminal) sym-bol X can be modeled by the graph 1S( X)with a directed arc from an inheritedattribute b G 1(X) to a synthesized at-tribute a = S(X) if the instance for adepends transitively on the instance forb in some attributed subtree with a nodelabeled by X as the root.

Let us consider a production p: XO +x, . .. Xn. (Recall that there is a localdependency graph DGP for p.) Supposethat for each i = 1,2,. ... n we have adirected input-output graph 1S( X, ).Then we denote by DG~ = DGP[ IS(X1),LS(X2), . . . . 1S( Xn)] the directed graphthat is obtained from DGP by adding anarc from attribute occurrence X,. b to X,. awhenever there is an arc from b to a inlS(X, ), i = 1,2,..., n.

The input-output graphs lS(X) can berecursively defined in terms of the graphsDGj :

0 the vertices of 1S( X ) are the attributesA(X);

● there is an arc in lS( X ) from an inher-ited attribute b c 1(X) to a synthe-sized attribute a ● S(X) if and only ifthere is a path from X. b to X.a in thegraph DG* for some production p:x- . . . Lw ose left-hand side is X.

An attribute grammar is absolutely non-circular if no augmented dependencygraph DG~ contains a directed cycle[Kennedy and Warren 1976]. The graphsDG~ and IS(X) can be computed itera-tively by starting from the local depen-dency graphs DG and the graphs IS(X)

Jwithout arcs, an by adding a nonexist-ing arc to an IS(X) if there is a produc-tion p with left-hand side X such thatthe current DG~ contains a path fromb @ I(X) to a G S(X) (simultaneouslyextending the graph DG~. for each pro-duction q having X on Its right-handside), until no more arcs can be added toany 1S( X ).

The arcs in 1S( X) reflect all theinput-output dependencies that could ex-ist in an attributed subtree with X as itsroot. The approximation is, however,overpessimistic and may reject an at-tribute grammar which is actually welldefined. Still, absolutely noncircular at-tribute grammars have been accepted asthe largest tractable class of attributegrammars because the decision algo-rithm for the class is polynomial insteadof the intrinsically exponential test forgeneral well-defined grammars.

Another powerful and widely appliedmultipass grammar class of polynomialcomplexity is ordered attribute gram-mars [Kastens 1980]. While being aproper subclass of absolutely noncircularattribute grammars, ordered attributegrammars are attractive because theycan be implemented in a simpler andmore efficient way. Another aspect is thateven the ordered attribute grammarsseem to include all the practical cases


204 * Jukka Paakki

when considering the processing of pro-gramming languages. This class is onlysketched below; for technical details, seeKastens [1980] or Alblas [1991].

In addition to the input-output depen-dencies IS(X), the output-input depen-dencies S1( X ) are approximated inordered attribute grammars. That is,the graph S1( X ) includes an arc from asynthesized attribute b G S(X) to an in-herited attribute a ● 1(X) if a may(transitively) depend on b in some at-tributed derivation tree. Notice that suchinformation is necessarily computed interms of the upper contexts of X-nodes inthe attributed derivation trees.

From the compound graph lSS1(X) =IS(X) U SI(X), a linear partial orderTO(X) for the attributes of each symbolX is computed. TO(X) comprises all thedirect and indirect attribute dependen-cies which may be derived from anycontext of X. An attribute grammar isordered if and only if for each produc-tion p: Xo+ xl... X, the graphDGP[7’O(XO), ‘TO(XI), . . . . TO(X~)] isacyclic. A central property of ordered at-tribute grammars is that lSS1(X) GTO(X) for each symbol X. For tech-niques of computing the applicable linearorders TO(X) as extensions of ISSI(X)and forcing a circular dependency pat-tern into an orderly arranged form withaugmented attribute dependencies, seeKastens [1980].

A context-independent evaluation pro-cedure for a symbol X arranges the at-tributes A(X) into a linear sequenceII(X), Sl(x), 12(X), S2(X), . . . . lm(x),Sin(X). The disjoint subsets of A(X),I (X) and SJ(X), form a partition ofA(X). For ordered attribute grammars,TO(X) defines a linear total order overthe subsets Ij( X) and S~(X), j =1,2,..., m, even though the evaluationorder within each subset is irrelevantand thus undefined.

The evaluation algorithm for an or-dered attribute grammar exhibits astrategy of evaluating the attributes of Xin m visits, such that each set lJ( X)includes the inherited attribute in-stances to be evaluated when entering a

node labeled by X for the jth time, andeach set S1( X) includes the synthesizedattribute instances to be evaluated whenexiting a node labeled by X for the jthtime. Between these evaluation actions,the algorithm visits other nodes in thecontext and evaluates some of the at-tribute instances therein in the samemanner.

Example 1.3.1

For demonstrating attribute grammars,let us study a simple desk calculationlanguage, DESK. In DESK, one can writeprograms of the form

PRINT (expression) WHERE (definitions)

where (expressIon ) is an arithmetic expres-sion over numbers and defined constants, and(definitions) is a sequence of constant defini-tions of the form

(constant name) = (number)

Each named constant applied in (expres-sion) must be defined in (definitions),and (definitions) may not give multiplevalues for a constant. For instance, thefollowing is a DESK program:

PRINTx+ y+lwHEREx=l, y=2 (1.1)

We specify the DESK language with anattribute grammar. To illustrate the var-ious paradigms presented, the DESKlanguage (with minor variations) will beused as a case example throughout thissurvey. Because of repeated elaboration,the example is concise. For instance, onlyadditions are allowed in expressions; aricher selection would just make thegrammar longer without bringing in anynew aspects. However, DESK still hasmany central characteristics of a realprogramming language:

* declaration of named entities (here:constants)

e use of declared entities

o conditions on the declaration and useof an entity:

-no constant can be multiply declared

ACM Computmg Surveys, Vol 27, No 2. June 1995

Attribute Grammar Paradigms * 205

—only declared constants can be refer-enced by name

● executable entities (here: expressions).

Without loss of focus of the presentation,DESK may also be considered as onepart of a complete, more advanced pro-gramming language.

On the implementation side DESK in-troduces the following typical tasks:

●

e

●

0

●

lexical and syntactic analysis

name analysis (i.e., symbol table man-agement)

checking of static conditions

multipass, or more precisely, right-to-left processing (because named entitiescan be used before declaration) and

interpretation, or code generation forthe executable entities. -

Let us start by specifying the DESK lan-guage in the original “standard form ofan attribute grammar. Since attributegrammars are more suitable for describ-ing compilation than interpretation, the(dynamic) meaning of a DESK programis defined implicitly as a mapping into alower-level target code. For simplicity, wemake use of an assembly code for a sim-ple one-register machine as the target.The relevant assembly instructions arethe following:

LOAD n, loads the value n into the register;

ADD n, increments the contents of theregister with value n;

PRINT O, prints the contents of the register;

HALT O, halts the machine.

The execution of a legal DESK programevaluates the expression and prints itsvalue, whereas an illegal program haltsthe machine without printing. For in-stance, the code generated for the DESKprogram (1. 1) is

LOAD 1 (X)

ADD 2 (y)ADD 1PRINT OHALT O

The context-free grammar G for DESKconsists of the following elements:

N = {Program, Expression, Factor,ConstName, ConstPart,ConstDefList, ConstDef},

T=

P=

PRINT’, ‘WHERE’, ‘,’, ‘= ‘,‘+’, Id, Number},

Program +‘PRINT’ Expression ConstPart,

Expression ~Expression ‘+‘ Factor,

Expression ~Factor,

Factor -ConstName,

Factor -Number,

ConstName ~Id,

ConstPart s

Co&nstPart e‘WHERE’ ConstDefLW,

ConstDefList -ConstDefList ‘,’ ConstDef,

ConstDefList ~ConstDef,

ConstDef ~ConstName ‘ = ‘ Number},

D = Program.

We make use of the following attributesA:

code, synthesized target code;name, synthesized name of a constant;value, synthesized value of a constant

or a number;envs, synthesized environment

(symbol table);envi, inherited environment

(symbol table);ok, synthesized indicator of correctness.

The target code is a list of instructions ofthe form (operation code, argument). Anenvironment is a list of bindings of theform (name, value).

The semantic rules R are associated

with the productions as follows, usingthe notation “production {semanticrules}”. Within a production, different oc-currences of the same grammar symbolare denoted by distinct subscripts.


206 e Jukka Paakki

(1.2)(pi)

(p2)

(p3)

(p4)

(p5)

(p6)

(p7)

(P8)

(p9)

(plo)

(pll)

Program +’PRINT’ Expression ConstPart{Program.code = if ConstPart.ok

then Expression,code + (PRINT, O) + (HALT, O)else (HALT, o),

Expression.envl = ConstPart envs}

Expressionl - Expressionz ‘+’ Factor{Expresslonl code= if Factor.ok

then Expresslonz.code + (ADD, Factor. value)else (HALT, o),

Expression 2.envl = Expressionl ,envi,Factor.envi = ExpressIonl .envi}

ExpressIon + Factor{Expression.code = if Factor.ok then (LOAD, Factor, value)

else (HALT, o),Factor.envl = Expression.envl}

Factor - ConstName{Factor.ok = isin (ConstName.name, Factor. envi),Factor. value = getvalue (ConstName.name, Factor. envO}

Factor - Number{Factor.ok = true, Factor value= Number value}

ConstName ~ Id{ConstName.name = Id.name}

Constpafl * E{ConstPart.ok = true, ConstPart.envs = ()}

ConstPart ~‘ WHERE’ ConstDefList{ConstPart.ok = ConstDefLlst.ok,ConstParl envs = ConstDefList.envs}

ConstDefListl ~ ConstDefListp ‘,’ ConstDef{ConstDefLlstl .ok = ConstDefLMp.ok and not

isin(ConstDef name, ConstDefList2.envs),ConstDefListl .envs = ConstDefList2.envs +

(ConstDef.name, ConstDef.value)}

ConstDefList + ConstDef{ConstDefList.ok = true,ConstDefList.envs = (ConstDef.name, ConstDef.value)}

ConstDef ~ ConstName ‘ = ‘ Number{ConstDef.name = ConstName.name,ConstDef.value = Number. value}

As utmal in attribute gammars, we as-sume that the values of the intrinsic at-tributes Id.name and Number. value of theterminal symbols are externally pro-vided, e.g., by a lexical analyzer.

We have applied the following seman-tic functions (some of them written in amore convenient infix notation):

if(c, VI, v2), if c yields true, returns VI elsereturns v2;

+(1,2), returns the catenation of lists

1 and 2;

and (cl, c2), returns the conjunction of cland c2;

not (c), returns the negation of c;

isin (n, e), if the environment e containsa binding (n, x), returns trueelse returns false;

getval ue (n, e), if the environment e containsa binding (n, x), returns x elsereturns O.



(DGP1)

Figure 1. Local dependency graph for p 1,

We have also applied some conventionalconstant functions, such as the integer O,the Boolean true, and the empty list ().

For clarity, all the applications of theidentity function 1 (1(x) = x for all x)have been directly replaced by the resultvalue. (Recall that the attribute gram-mar definition only permits semanticrules of the form X.a = ~(. . . ) where f isa function.)

The meaning of a DESK program isthe value of Program. code, i.e., the targetcode associated with the root of the corre-sponding attributed derivation tree. Notethat in this case a semantically incorrectDESK program also has a meaning; forinstance the meaning of

PRINTzwHEREx=l, y=2

is the target code

HALT OPRINT OHALT O

(End of Example 1.3.1)

Let us analyze the DESK attributegrammar (1.2). The grammar is not L-attributed (nor S-attributed), due to aright-to-left arc in the local dependency

graph DGPI for production p 1, as shownin Figure 1. The inherited attributes areassociated to the left and the synthesizedattributes to the right of a grammar sym-bol.

The grammar is, however, absolutelynoncircular. This is shown in Figure 2 bythe acyclic augmented dependency graphDG~ for each production p that has asymbol in its right-hand side with bothinherited and synthesized attributes. Thetransitive input-output dependencies inIS(X) are denoted by dashed arrows.

The inclusion of the input-output de-pendency arcs enui— + ok and enui— +value in LS(Factor) (as well as in DG~zand DG~~ ) is revealed by the local depen-dency graph for production p 4, shown inFigure 3. Notice that IS(Factor) implic-itly introduces the arc envi — --+ code intoIS(Expression) (and into DG~l andDG*Z ) via the graph DG~~ in Figure 2.

&nce the attribute grammar is abso-lutely noncircular, it is also well defined.4Hence, the attribute dependency graph isacyclic for each attributed tree spannedby the grammar. To illustrate the rela-tion between the characteristic graphsand the attributed trees for concretesource programs, Figure 4 sketches theattributed tree for the DESK program

(1.1). For clarity, only the upper level ofthe tree is completely given. Semanticfunctions are denoted by circles.

This attribute dependency graph showsexplicitly the data flow within the deriva-tion tree. The graph shows, most notably,that in order to evaluate Program.code, the synthesized instance of Const-Part. envs, the inherited instance ofExpression. envi, and the synthesizedinstance of Expresson.code must first beevaluated, in that order. (Recall the sameinformation in the augmented character-istic graph DG~l of Figure 2.) In otherwords, for generating the target code forthe program, the symbol table must beconstructed in the subtree for ConstPartand consulted in the subtree for Expres-sion (since the values of named constants

4The grammar also belongs to a number of other

well-defined supersets of L-attributed grammars,such as the class of ordered attribute grammars. Afurther elaboration is omitted.

ACM Computing Surveys, Vol 27, No 2, June 1995

208 ● Juhka Paakki

L.. —_-...-

‘DGP:VL*S3 va u

L– ___ L–– J7

(DG P3+) envi” Expression code

~ f>okenvi: Factor.

I L . . =Value

L––3

Figure2. Augmented dependency graphs.

Ww) ‘n@inI I_,/

ConstName:name

Figure3. Local dependency graph forp4,

are needed for generating the code). Thisalso applies to name analysis for the ex-pression part of the program.

When considering the attribute gram-mar (1 .2) as specification of a DESKcompiler, we immediately notice thatcompilation cannot be totally done dur-ing parsing (and embedded lexical analy-sis). This is due to the fact that whenparsing the expression part of a program

(e.g., x + y + 1 in program (1.1 )), the val-

ues of the named constants applied in it

(e.g., x and y) are not yet available.Therefore, name analysis and code gen-eration for the expression part have to bepostponed until the constant definitionpart of the program has been processed,leading necessarily to a multipass compi-lation scheme.

The ability to describe multipass pro-cessing is an inherent and powerful char-acteristic of attribute grammars. Thiscomputational expressiveness is providedby inherited attributes that can modeldata flow into a construct from its con-text. This aspect is demonstrated in ourDESK grammar by the dependency fromthe synthesized attribute occurrenceConstPart.envs to the inherited occur-rence Expression .envi in production p 1.

The notation used in the attributegrammar (1 .2) is quite common in exist-



Program’code

‘-7v /

envl :Expresslon:code ‘

[~!\

x+ +1

/ .

3ConstPart ~~s

/ \LWHERE ConstDefList.‘k

A

envs

x=l, –– -.$

.2 ‘––

Figure 4. Attribute dependency graph over an attributed tree.

ing language processor generators. Aspecification of the DESK language andits compiler, written in the input lan-guage (the metalanguage) of such asystem, contains typically the followingcomponents:

(1) a list of grammar symbol declara-tions (N, T) with associated at-tributes (A),

(2) a sequence of productions (P) withassociated semantic rules (R), and

(3) the semantic functions (~) in an ex.ternal file, usually written in someconventional programming language.

This simplistic style reflects the defini-tion of attribute grammars in a straight-forward way and is used in all the oldersystems. Multipass systems based on this“pure” attribute grammar paradigm arefor instance GAG [Kastens et al. 1982],LINGUIST-86 [Farrow 1982], and HLP78

[Riiihii et al. 1983]. From the grammar(1 .2) such a system would generate amultipass DESK compiler that (1) scansand parses the source program, (2) con-structs an explicit attributed derivationtree as the intermediate representationfor the program, and (3) evaluates theattribute instances in the tree during atraversal over it. Phase (3) would involveboth (static) semantic analysis and tar-get code generation. Examples of one-passsystems whose metalanguage follows the

standard paradigm are MIRA [ExpertSoftware Systems 1984] (originally de-veloped as LILA [Lewi et al. 1979]), andYACC [Johnson 1975; Mason and Brown1990].

The standard attribute grammar nota-tion has, however, severe practical short-comings. This stems from the fact thatattribute grammars, as a concept, arejust a theoretical model of language pro-cessing without any advanced engineer-ing facilities. The grammars written inthis manner tend to become most un-structured and lengthy. As an example,an attribute grammar for the program-ming language Ada written in GAGsspecification language comprises an en-tire book with over 500 pages and 20,000lines, more than 260 homogeneous pro-ductions, and about 600 global semanticfunctions [Uhl et al. 1982]. The problemswith such specifications are parallel withthe known problems encountered whenprogramming in a low-level unstructuredprogramming language: the specifica-tions are hard to understand, modify, andmaintain. Some attribute grammars areeven larger than their procedural coun-terparts (e.g., compilers), an aspect thatmakes it rather questionable to considersuch grammars as specifications.

Another problem with standard at-tribute grammars is their unduly strictnotion of dependencies and well-defined-ness. Recall that, by definition, an



attribute instance cannot be evaluateduntil all the instances on which it de-pends have been evaluated, and that thesemantic rules shall not introduce anypotential circularities into the attributedependency graphs. In some cases theserestrictions force an attribute grammarto be written in a form which is not themost natural or intuitive one. Note thatto an extent these restrictions are merelytechnical and due to the assumption ofapplying a strict computational mecha-nism in attribute evaluation.

In the following chapters we will pre-sent techniques that have been devel-oped for removing the above-mentioneddrawbacks of standard attribute gram-mars. The approaches can be roughlyclassified into two categories: organiza-tional paradigms and evaluationparadigms. The organizational para-digms provide facilities to compose anattribute grammar of autonomous, yetintegrated units. By this, the grammarsbecome more manageable and easier tounderstand. The evaluation paradigms,on the other hand, employ powerful com-putational mechanisms in attribute eval-uation, thus raising the expressive powerbeyond standard attribute grammars.

The organizational paradigms will bediscussed in Section 2. We start in Sec-tion 2.1 by presenting attributionparadigms where abstract notations areprovided for commonly applied patternsof semantic rules. More general solutionsadopt their model from established pro-gramming paradigms that are foundedon some central structural concept. Theseare presented under the notions of struc-tured attribute grammars (based on theconcept of a block), modular attributegrammars (based on the concept of amodule), and object-oriented attributegrammars (based on the concept of aclass) in Sections 2.2, 2.3, and 2.4, respec-tively.

In Section 3 we will present evaluationparadigms. Section 3.1 discusses logic at-tribute grammars where the special fea-tures of logic programming are utilizedfor increasing the semantic power of at-tribute grammars. A similar effect, using

functional programming, is demon-strated in Section 3.2 under the notion offunctional attribute grammars. In orderto give a complete picture of the state ofthe art, we briefly discuss in Section 3.3two special techniques, parallel and in-crem en tal evaluation, that are currentlysubjects of intensive research.

The main principles of the differentparadigms are illustrated by examplesshowing how some representative sys-tems tackle the problems discussedabove. For a quick overview, examplesystems promoting the paradigms aregiven in Table 1. Some of the systems inthe table are given merely for referenceand will not be further discussed in Sec-tions 2 and 3.

2. ORGANIZATIONAL PARADIGMS

In this section we present techniques formanaging the complexity of an attributegrammar by organizing some of its partsas linguistic units. The methods are simi-lar to those developed for structuring or-dinary programs in terms of concepts likecompound statements, blocks, proce-dures, modules, packages, and classes.Accordingly, the presented paradigmsaffect the structure of the attributegrammar rather than its semantics. As aconsequence, a specification written inany of these styles could be translatedinto a semantically equivalent standardattribute grammar by reducing its ab-straction level (as a program written in ahigh-level programming language can becompiled into machine code). In fact, thisis the implementation method applied insome systems, although the normal prac-tice is to translate an organized attributegrammar directly into a programminglanguage with similar structuring facili-ties.

2.1 Attribution Paradigms

Often a significant number of semanticrules in a typical attribute grammar aremuch alike. Since these attribute defini-tion patterns occur very frequently, us-ing short and comprehensible special

ACM Computmg Surveys, Vol. 27. No. 2, June 1995

Attribute Grammar Paradigms “ 211

Table 1. Classlflcatlon of Attribute Grammar-Based Systems

STANDARD PARADIGM

Pure attribute grammars YACC [Johnson 1975] LILA [Lewi et al. 1979] ]

ORGANIZATIONAL PARADIGMS

Attribution GAG HLP78paradigms [Kastens et al. 1982] [IWhii et al. 1983]Structured HLP84 FNC-2

attribute grammars [Koskimies et al. 1988] [Jourdan et al. 1990]

Modular MAGGIE [Dueck and Linguist [Declarativeattribute grammars Cormack 1990] Systems 1992]

Object-oriented Mjalner/Orm TOOLS [Koskimies andattribute cmunmars lHedin 19891 Paakki 19901

EVALUATION PARADIGMS

L@ic Pan PROFIT

1 attribute grammars [Ballance et al. 1990] [Paakki 1991]Functional I FNC/ERN ] YACC/CAMLICousineau

II attribute grammars [Jourdan 1984] and Huet 1990]Parallel FOLDS [Boehm and

attribute evaluation [Fang 1972] Zwaenepoel 1987]

Incremental oPTRAN The Synthesizerattribute evaluation [Lipps et al. 1988] Generator [Reps and

Teitelbaum 1989]

notations for them may drastically re-duce the size of a language (processor)specification. These compact abstractionscan be systematically transformed intothe basic notations without changing anyproperties of the attribute grammar. Anumber of systems provide such attribu-tion paradigms in their specification lan-guages; examples include HLP78 [Raihaet al. 1983], GAG [Kastens et al. 1982;1987], HLP84 [Koskimies et al. 1988],LINGUIST-86 [Farrow 1982], Metauncle[Tarhio 1989], and FNC-2 [Jourdan et al.1990]. An introduction to the attributionparadigms is included in Kastens [1991].

Analyses of attribute grammars haveshown that many of their semantic rulesare simply copy rules (or “transfer rules”)of the form

X.a = Y.a.

Copy rules are frequently needed espe-cially in describing the propagation ofcontext information, such as a compiler’ssymbol table. Some systems either pro-vide a special notation for such attribu-tion schemes, or simply include them asimplicit default rules.

For instance, GAG provides the at-tribute transfer rule TRANSFER which,when associated with a production XO +xl . . . Xn, denotes (1) a copy rule XO.a =X,.a for each attribute a = S( XO ) that isassociated with exactly one symbol Xl inxl .“. Xn, and(2) acopy rule Xj.b =XO.bfor each attribute b ● I(XO ) and for eachsymbol X in Xl . . . X. that owns theattribute ~. This mechanism is based onthe natural convention that attributesdescribing the same property of differentsymbols should have the same name.



Using this facility, the first productionfor Expression and the production forConstDef in the grammar (1 .2) can bewritten as follows:

(p2)

(p,,)

Expressionl + Expression ‘+’ Factor{Expresslonl.code = if Factor ok

then Express! on2.code + (ADD,Factor. value)

else (HALT, o),TRANSFER}

ConstDef - ConstName ‘ = ‘ Number{TRANSFER}

Another commonly applied attributionpattern is to use an attribute whose in-stance is located in a context other thanthe current local one. In terms of thedynamic attributed tree, the value of anattribute instance for a node n dependsin such a case on an attribute instance athat is associated with an ancestor or adescendant node of n. In the standardframework the value of a would have tobe propagated to n with a chain of copyrules. There exist, however, more conve-nient techniques to handle such a situa-tion.

HLP78 provides a form of global at-tributes that were originally proposed inKnuth [1971]. A global attribute instancecan be directly accessed and updatedwithin the subtree with whose root it isassociated, without passing it explicitlythrough the nodes in the subtree. Thedrawback of the approach is that it is notalways easy to foresee the exact execu-tion order of the semantic rules on a

global attribute. This problem is re-moved, e.g., in HLP84 where global at-tributes are tuned solely for one-passlanguage processing (with an unambigu-ous execution order).

GAG provides the remote access in-structions INCLUDING (for accessingglobal attribute instances within a sub-tree) and CONSTITUENTS (for composingthe value of a global attribute instance ofdistinct attribute values within the sub-tree). The expression

INCLUDING (Y1.al,..., Y~,a~)

associated with the production XO -+ Xl~.o X. yields the value of either Y1.al, or. . . . or Ym.am, depending on which of thesymbols Y,, ..., Y~ is the label of the

nearest ancestor of the node for XO inthe attributed tree. The expression

CONSTITUENTS Y,a

associated with the production XO + Xl. . . X. yields a list of attribute values Y.afrom left to right in the subtree whoseroot is the turret node for XO. In bothcases the attribute grammar must guar-antee that the expression always pro-duces a proper value,

As an example, the attribute grammar

(1 .2) can be revised such that the symboltable is expressed as a global attributefor the DESK expression, and the targetcode is a list of individual instructions.Then a DESK expression can be specifiedas follows:

(pi) Program ~ ‘PRINT’ MainExpressIon ConstPart{Program.code = if ConstPart.ok

then MainExpression. code + (PRINT, O) + (HALT, O)else (HALT, o),

MalnExpresslon. envl = ConstPart,envs}

(pI’) MainExpressIon - ExpressIon{MainExpresslon. code = CONSTITUENTS Expression. code}

(p2) Expressionl ~ Expression ‘+’ Factor{Expression, code = if Factor.ok

then (ADD, Factor. value)else (HALT, o)}

(p3) ExpressIon - Factor{Expression.code = if Factor.ok

then (LOAD, Factor. value)else (HALT, o)}

ACM Computmg Surveys, Vol 27. No 2, June 1995


~envi Main Expression: code ConstPart

~ )

Expression: code /+ ~

+,Xpri:f<k(/o-1’\

ConstName\

If Id

t

IL 2

Y

L

> km

Factor

@w:e

1-)envs

ok

ConstName

IId

x

Figure 5. Globalized attributed tree.

(p4) Factor ~ ConstName{Factor.ok = isin (ConstName.name,

INCLUDING (MainExpression. envi)),Factor. value = getvalue (ConstName.name,

INCLUDING (MainExpression. envi))}

(p5) Factor ~ Number{Factor.ok = true, Factor.value = Number. value)

(p6) ConstName -+ Id{ConstName.name = Id.name}

The productions are shorter and simplerthan in the original grammar (1 .2),thanks to replacing the local attribute

occurrences envi with the global attributeoccurrence Main Expression .envi. Also thedefinition of Expression.code is simplerbecause it now represents one target in-struction only instead of the completecode sequence synthesized from a sub-

tree. Note that in the case of an invalidexpression the final target code mightnow be different from that specified in

grammar (1 .2). The dynamic semantics ofDESK, however, is the same: computa-tion of an invalid expression will alwaysbe aborted by a HALT instruction.

We clarify the globalizing method bysketching in Figure 5 the attributed tree


214 4 Jukka Paakki

for the DESK program (1. 1). The at-tribute evaluation pattern in each Factorcontext is the same as shown for theleftmost one.

Note that now the Expression and Fac-tor nodes do not have an instance of theenvi attribute at all, whereas conceptu-ally the instances remain both in thegrammar and in the tree when using thecopy rule elimination technique dis-cussed above (although a space-optimiz-ing system, such as HLP78 or GAG,would even then probably remove themautomatically from the tree).

Semantic error handling is cumber-some in standard attribute grammars.For instance, the grammar (1 .2) makesuse of the ok attribute for expressingstatic semantic restrictions. GAG andHLP84, among others, extend attributegrammars with consistency conditionsthat are boolean-valued expressions overattribute occurrences. The conditions canbe associated with nonterminals (HLP84)or productions (GAG). As an example,the following production in GAGs con-vention expresses the constraint thateach named constant applied in a DESKexpression must be defined. The consis-tency condition involves an error mes-sage to be emitted if the condition isviolated.

(p4) Factor ~ ConstName{Factor. value = getvalue(ConstName name,

INCLUDING(MainExpresslon envl));

CONDITION Isin (ConstName name,INCLUDING (MainExpression. envi))MESSAGE “Constant not defined”}

Notice that by this feature the ok at-tribute and its semantic rules (some ofwhich are redundant in grammar (1 .2))become useless. The incorrectness of aDESK program is now manifested by er-ror messages that are given by the gener-ated compiler at run-time.

2.2 Structured Attribute Grammars

The key issue in managing large systemsis decomposition, or structuring. A sys -

tern with small integrated components iseasier to build and maintain than amonolithic system. The fundamental con-cepts for structuring software have beendeveloped in parallel with the evolutionof programming languages. The firststructuring primitives introduced intoprogramming languages were subpro-grams in Fortran, compound statementsin Algol 58, and blocks in Algol 60. Thesehave been the basic models for a numberof later improvements.

In this section we address the questionof how to apply conventional structuringmechanisms of programming languagesto attribute grammars. The term “struc-tured programming” has in this context aspecific meaning. Two traditional narrowinterpretations might consider the termas a synonym to “programming withoutgoto statements” or “programming withstructured data types.” However, sincestatements or data types conceptually(albeit in practice, of course) are not cen-tral issues in attribute grammars, struc-tured programming is here considered asa programming style based on blocks andprocedures.

Blocks

A block is a language structure with anarbitrary number of local entities thatmay be blocks themselves. Hence, blockscan be characterized with the followinggeneral propeties:

a static partition of programs into hierar-chical elements and

0 local name environments.

A dominant characteristic of program-ming languages is c~isibility ( scope) rulesthat specify how a name applied in aprogram is associated with its declara-tion. This principle, which strongly af-fects both language design, definition,and implementation, originates in Algol60’s notion of nested blocks. In Algol 60an applied occurrence of a name is asso-ciated with its defining occurrence suchthat if the program contains severaldefining occurrences for the name, then



the one belonging to the innermost blockenclosing the applied occurrence is se-lected. This principle of statically deter-mining the name association has beenadopted in most structured programminglanguages.

Attribute grammars in their standardform, as defined in Section 1.2, provideonly limited structuring facilities. Theycan be characterized with the correspon-dence

~

since a standard attribute grammar iscomposed of a list of productions withtheir local semantic rules. This approachwas demonstrated in Example 1.3.1. Thelocal declaration property of blocks isprovided in some metalanguages as at-tributes that are local to a production(e.g., CWS2 [Bochmann and Ward 1978]and FNC-2 [Jourdan et al. 1990]). Thisconceptual coupling of productions andblocks is, however, rather primitive be-cause typically only a few productionscan sensibly make use of local attributesand because the nesting obtained thisway is merely flat (productions cannot begiven within productions). Hence, morenatural and general means have to beestablished in order to introduce usefulstructuring facilities into attribute gram-mars.

In a declarative attribute grammar, thesemantic emphasis should be laid on de-scribing the nonterminals in terms of at-tributes. Thus, a natural design decisionis to choose a nonterminal as the struc-turing primitive of attribute grammars,and to reflect conventional structuringmethodologies on nonterminals. Thisview gives rise immediately to the fol-lowing characterization of structuredattribute grammars and, from an oper-ational point of view, for a structuredlanguage processing methodology:

Nonterminal = Block

In other words, nonterminals of attributegrammars correspond to blocks of pro-

gramming languages, in that

(1) nonterminal definitions can be arbi-trarily nested,

(2) nonterminals can have local entities,and

(3) visibility of entities is controlled byconventional block-structured scoperules.

Nonterminal-based structuring makesa language specification more compre-hensible by dividing it into logicalcomponents: each nonterminal definitionspecifies a sublanguage, and the nestingdescribes the hierarchy of those sublan-guages. As is normal in block-orientedstructuring, a sublanguage that is in-cluded in several contexts of the wholelanguage must be expressed by a nonter-minal which is defined on a global level.

It must be emphasized that this “Non-terminal = Block” correspondence is onlyemployed for structuring language speci-fications, not for mapping nonterminalsinto blocks in the implementation of at-tribute grammars. In general, the struc-ture of a specification and the structureof the corresponding program are com-pletely different topics. For instance,HLP84 whose metalanguage is blockstructured generates language proces-sors where this structuring is totally ef-faced [Koskimies et al. 1988].

Procedures

In addition to blocks, nonterminals canbe mapped to other structuring units aswell, giving rise to alternative forms ofstructured language processing. The con-ventional style of programming languageprocessors is to apply the recursiue-descent method where the nonterminalsof the underlying grammar are repre-sented by recursive procedures.5 Whenconsidering parameters of these proce-

5In this case nonterminals are mapped into theimplementation. However, recursive-descent com-pilers are factually equivalent with LL-attributedgrammars [Wilhelm 1982], and thus represent aspecial case where implementation follows specifi-cation closely.

ACM Computmg Surveys, Vol. 27, No 2, June 1995

216 ● Jukka Paakki

dures as “semantic attributes,” we can TOOLS is much more powerful thancharacterize the recursive-descent HLP84, being able to generate multipassmethod as being based on the following implementations as well. This is achievedcorrespondence: by specifying in the attribute grammar

both a mapping of the source program

Nonterminal = Procedureinto its intermediate abstract syntax treeand a traversal scheme over the tree. The

Most implementations of L-attributedgrammars generate (one-pass) recursive-descent compilers that apply this corre-spondence operationally. Nonterminalsare considered as procedures even con-ceptually in some language processorgenerators. For instance, the metalan-guage of DEPOT2a, ML2a, is stucturedaccording to the correspondence givenabove [Grossmann et al. 1984]. A lan-guage (processor) specification written inML2a is composed of procedures suchthat each procedure expresses the pro-cessing of a sublanguage in terms of otherprocedures. Inherited attributes arerepresented as input parameters, andsynthesized attributes as output pa-rameters. The block structure in ML2ais flat: all the nonterminal proceduresmust be defined at the same level of thespecification. In DEPOT2a the “Non-terminal = Procedure” correspondence iscarried over from the metalanguage intothe implementation, and the generatedlanguage processors are backtracking re-cursive descent.

2.2.1 TOOLS

TOOLS is a language processor genera-tor whose metalanguage is structuredfollowing the style outlined above: non-terminals are expressed as blocks

[Koskimies and Paakki 1990; 1991]. Thesystem is a descendant of HLP84[Koskimies et al. 1988] that was designedto support one-pass language implemen-tation with a high-level extended at-tribute grammar as the metalanguage.The extensions, available both in HLP84and TOOLS, include (besides the struc-turing facilities) a restricted form ofglobal attributes, semantic consistencyconditions, and an abstraction of“ordinary” symbol table operations.

traversal may correspond to the codegeneration phase of a compiler, or to im-mediate interpretation.

TOOLS is a versatile system with anexpressive specification language. Thecustom of describing the abstract syntaxtree is to map instances of central non-terminals with nodes of the tree. Thosenonterminals that correspond to syntaxtree nodes are specified as classes in theattribute grammar. This principle bringsan object-oriented flavor into TOOLS. Wedo not address this aspect here but referto Section 2.4 where object-oriented at-tribute grammars are discussed.

Let the attribute grammar for a lan-guage include the following two produc-tions for the nonterminal N, where A andB denote other nonterminals:

N + A... {(senla~ti~ ~ul~s (1))}N + ... B... {(semantic rules (2))}

In TOOLS’ metalanguage, the gram-mar fragment is written in the followingblock-structured form:

structure N: (attributes of N);structure A: (attributes of A); . end A,structure B“ (attributes of B), end B;

form .A. . . do (semantic rules (1)>:form . . . B... do (semantic rules (2));

end N;

Hence, the nonterminal N is a block

(expressed by “structure N .,. end N“)with local declarations. The nontermi-nals used in the productions of N (here Aand B) are declared as local nonterminalsof N. As usual in block-structuring, A (orB) has to be declared on a global level ifit is also referenced outside of the blockfor N. A form clause stands for a produc-

tion (its right-hand side) and its associ-

ated semantic rules for the enclosingnonterminal. Note the centralizing effectof block-structuring: all the aspects of anonterminal can be specified as one unit,

ACM Comput,ng Surveys, Vol 27, No 2, June 1995


without spreading them over individualproductions throughout the specification,as is the case with standard attributegrammars.

As an example of a block-structuredattribute grammar, we describe ourDESK language (see Example 1.3.1) us-ing the metalanguage of TOOLS. Sincethe preferable application area of TOOLSis interpretation, the grammar specifiesnow an interpreter rather than a com-piler. Notice that this solution is actuallyquite natural in this case since the primi-tive DESK language does not have anyrecursive or iterative control structures.

The structure of the specification canbe systematically extracted from the con-text-free grammar of DESK. When fol-lowing the guidelines given above, thefollowing nesting of grammar symbols isobtained:

ProgramIdNumberExpression

FactorConstName

ConstPartConstDefList

ConstDefConstName

Notice that Id and Number must bedeclared at the same level as Expressionand ConstPart to make them globally vis-ible for the local nonterminals Factor,ConstName, and ConstDef. Notice alsothat the hierarchy above introduces twodifferent nonterminals of the same nameConstName. This reflects the fact thateven though the occurrences have thesame name, they have different seman-tics: the ConstName occurrence for Factorstands for an application of a definedconstant, whereas the ConstName occur-rence for ConstDef represents the defini-tion of a constant. This distinctionmatches with the TOOLS methodologybetter than the unified solution used inthe attribute grammar (1 .2), and it alsodemonstrates the central principle of lo-cal naming in block-structured attributegrammars. The specification of the DESK

interpreter is given below.

externalprocedure Print (i:lnteger);

end;

structure Program;

type Constant = class —symbol tablekey name: String;value: Integer;

end;

—intermediate tree and its interpretation

(dynamic semantics):

type Expr = classvalue: Integer;sort Literal: ( );sort ConstRef: (name: String);begin

value: = [Constantl name. value;end;sort Add: (left: Ref (Expr); right: Ref (Expr));begin

execute left;execute right;value: = left. value + right. value;

end;end;

—attribute grammar (static semantics):

token Id: String = Letter + ;token Number: Integer = Digit + ;

structure Expression: Ref (Expr);structure Factor: Ref (Expr);

object ConstName: Ref (ConstRef);form [d do name:= Id end;

end ConstName;object LiteralConstant: Ref (Literal);

form Number do value:= Number;end LiteralConstant;form ConstName doFactor: = ConstName;form LiteralConstant doFactor” = LlteralConstant;

end Factor;object Addition: Ref (Add);

form Expression ‘+‘ Factor do beginleft: = Expression;right: = Factor;

end;end Addition;form Addition do Expression:= Addltlon;form Factor do Expression:= Factor;

end Expression;

structure ConstPart;structure ConstDefList;

object ConstDef: Ref (Constant);structure ConstName: String;

ACM Computmg Surveys, Vol. 27, No. 2, June 1995

218 9 Jukka Paakkl

form Id do ConstName: = Id,end ConstName,form ConstName ‘ = ‘ Number

do beginname:= ConstName;value:= Number;

end,end ConstDef;

form ConstDefLlst ‘,’ ConstDef,form ConstDef,

end ConstDefList;form Empty;form ‘WHERE’ Const’DefLlst,

end ConstPart,

form ‘PRINT’ ExpressIon ConstPart

do beginexecute ExpressIon;Print (Expression. value);

end;end Program

TOOLS provides high-level abstrac-tions for managing hierarchical andlinked data structures. In this applica-tion we have used these abstractions forthe definition of the symbol table and theintermediate syntax tree. They are repre-sented in the specification as the classtypes Constant and Expr, respectively,with associated attributes.

The symbol table collects all the con-stants defined in a DESK program. Eachof them has name and value as its at-tributes. The name attribute is used foridentifying the constant (key indication).A symbol table lookup is expressed bythe notation [Constant]X where X is thekey value used for identification. A sym-bol table insertion is specified by denot-ing a nonterminal as being an object (oftype Ref (Constant)) instead of being anordinary structure. The created symboltable entry receives its attribute valuesfrom the associated nonterminal, in thiscase from an instance of ConstDef, Bothoperations, lookup and insertion, auto-matically yield an error message if a con-stant with the same name is already inthe symbol table, or if the referencedconstant is not found there, respectively.

The intermediate tree has severalkinds of nodes, one for each differentexecutable DESK entity. In this examplean expression may consist of literal con-

stants (sort Literal), named constants(sort ConstRef), and additions (sort Add).The creation of a node is specified in thesame manner as for symbol table en-tries, with object nonterminals in theattribute grammar. The dynamic seman-tics (that is, interpretation) of the inter-mediate tree is described by associatingsort-specific operations with the classExpr. The execute clause denotes execu-tion of the code associated with the indi-cated node. Note that dvnamic semanticsis specified operationally rather thandeclaratively.

The actual attribute grammar is orga-nized following the block-structured prin-ciples discussed above. The attributes ofa symbol are defined by a semantic typethat follows the symbol’s name. Ref (C) isa predefine type for (symbol table andintermediate tree) references of class C.If the semantic type is simple (e.g., Ref

(Expr)), the associated symbol has onlyone attribute of the same name as thesymbol itself. The attributes of terminalsymbol instances (Id and Number) areautomatically evaluated from the lexicalrepresentation of the instance in the.source program. We have included sometechnical object nonterminals in thegrammar for specifying the creation ofthe symbol table and the intermediatetree. Notice how the decision to use con-ventional blocks as the model of structur-ing the attribute grammar separates theproductions of a nonterminal from its at-tributes, a feature which may make ithard for a novice to read the grammar.

F’rom this specification, TOOLS gener-ates a “partially two-pass” interpreter forDESK. The first pass does lexical, syn-tactic, and static semantic analysis of theconstant defbitions, as well as createsan intermediate tree for the expression.For example, after executing the firstpass over the program

PRINTx+ y+lwHEREx=l, y=2

the symbol table (Constant) and theintermediate tree (Expr) have the con-tents shown in Figure 6. Dotted linesdenote symbol table bindings to be real-ized in the second pass of interpretation.


IIIL.-


Constantl—— I

Expr

Add

m

ConstRef

a &--

Figure 6. Symbol table and intermediate tree.

--l

In the second phase the tree is tra- ining, however, fall short in sizable appli-versed, and the intermediate code associ-ated with its nodes is executed. Due tothe use-before-declaration feature ofDESK, this phase also involves resolvingand checking referenced constants. Inter-pretation is finished by printing the valueof the expression using the external (Pas-cal) procedure Print. In the situation de-picted in Figure 6, the value 4 will beproduced as a result.

Note that TOOLS makes it necessaryto specify the structure of the intermedi-ate syntax tree explicitly, whereas thetree would be implicit in more declara-tive multipass systems, such as GAG[Kastens et al. 1982]. On the other hand,the TOOLS approach allows for quitegeneral and complex language processingstrategies (as interpretation in this ex-ample) instead of supporting a fixed com-pilation scheme only.

2.3 Modular Attribute Grammars

Blocks and procedures are sufficient fororganizing programs on a small scale.These concepts of structured program-

cations. That is why more advancedfacilities have been developed for pro-gramming-in-the-large. Such concepts,generally called modules, support in par-ticular the construction of programs fromindependent units that provide servicesto each other through an explicit narrowinterface. Modules are superior to blocksand procedures in their reuse and mod-ification capabilities: a well-designedmodule can be incorporated in many

programs, and it may be revised with-out forcing major (if any) changes to othermodules.

Therefore, even though modules are inmany respects similar to blocks and pro-cedures, this particular programmingstyle is usually characterized by the spe-cial term modular programming. Theparadigm involves, besides the generalproperties of structured programmingoutlined in Section 2.2, also the followingfundamental characteristics:

. data abstraction

. information hiding


220 “ Ju?%a Paakki

* separate compilation.

These modular programming featuresmake it possible to design abstract data

types. In an abstract data type specifica-tion the values of the type are not givenex~licitlv but are instead defined indi-re&ly b~ the operations. An abstract datatype specification (as well as a module ingeneral) is usually divided into two parts:an interface part introduces the publiccomponents that are available to othermodules. and a se~arate im~lementation

part gives the e;act realization of thecomponents. The data type is “abstract”in the sense that a user of the type hasonly access to the interface of the publiccomponents, not to their implementa-tions nor to the private components ofthe module. Thus the im~lementationpart can freely be modified without in-ducing any changes into other parts ofthe program, as long as the interfaceremains the same.

Another pragmatic merit of modules isthat thev are autonomous to the extentthat the; can be compiled separately fromother modules. This facilitates incremen-tal software development, makes it feasi-ble to assemble program libraries, andreduces recompilation efforts on softwareu~dates.

‘In the spirit of the structured attributegrammar paradigm, one form of a modu-

lar attribute grammar methodology isfounded on the following correspondence:

Nonterminal = Module

Now the nonterminals of an attributegrammar are represented as modulesthat make it possible to specify and storelinguistic elements completely that arecommon in several programming lan-guages. Such sublanguage specificationscan then be used in a new language spec-ification by importing the nonterminalmodules into the new specification. Theinterface of a nonterminal module con-sists of the attributes of the nonterminal,whereas the semantic rules are hiddenwithin the implementation part. Thismakes it possible to change the seman-tics of a nonterminal without modifying

its clients. The same also holds for thesyntax: the productions for the nontermi-nal and for the grammar symbols ap-pearing in them are given only in theimplementation part.

Modular attribute grammars introducean interesting implementation problem:how can a lexical and syntactic analyzerbe produced for a nonterminal withoutany global syntactic information (such asthe First and Follow sets: e.g. Aho et al.

[19861)? One approach recently sug-gested is to employ a lazy/incrementalmethod where the analyzers are con-structed dynamically at parse-time, si-multaneously with parsing the input (seeHeering et al. [1990] or [Koskimies1990]).

Attribute grammars based on modular-izing the nonterminals have been dis-cussed, e.g., in Koskimies [1989] and inToczki et al. [ 1989]. Other, principallydifferent methods of modularizing at-tribute grammars have also been devel-oped. The correspondence

is the basis in MAGGIE [Dueck andCormack 1990]. This approach suggeststhat attributes, rather than nontermi-nals, are the central semantic elementsof an attribute grammar. In this case amodule contains all the semantic rulesfor the corresponding attribute, whichimplies that the module also must list allthe productions that define an occur-rence of the attribute. The modular prop-erties of MAGGIE are rather primitivesince they do not support true informa-tion hiding nor separate implementation.

(Before compiler generation, the modularstructure of the attribute grammar is ef-faced by a transformation into a stan-dard monolithic grammar.)

A more general and flexible form ofmodularity is suggested in, e.g., Watt[1985], Reps and Teitelbaum [1989],Jourdan et al. [1990], and Farrow et al.[1992], that pursue modularization interms of different semantic subproblems.The following characterization summa-

ACM Comput]ng Surveys, Vol 27, No 2, June 1995

Attribute Grammar Paradigms w 221

rizes this direction for modular attributegrammars:

Semantic aspect = Module

Now a module contains all those parts ofan attribute grammar that assist withthe specification of a semantic aspect,typical examples being the scope and typerules of the language, data-flow analysis,and code generation. Typically themethod assigns several nonterminals, at-tributes, and productions to the samemodule. This general form of modulariza-tion can also be applied in a more opera-tional style by mapping the modules withthe different phases of a compilation pro-cess, as suggested in Ganzinger andGiegerich [1984] and Ganzinger et al.[1982].

One way of introducing data abstrac-tion into attribute grammars is to con-sider the semantic functions as abstractoperations on attribute domains. Thenthe operations applied on the same do-main constitute an abstact data type thatcan be externally implemented. The at-tribute grammar can be pasted togetherwith the abstract data types in the usualmanner, through the interfaces of thetypes. This method has been suggested,e.g., in Waite [1986], as an enhancementof the GAG system [Kastens et al. 1982].

An application-oriented utilization ofdata abstraction is to focus on the centraldata structure in language implementa-tion: the symbol table. Considering thesymbol table as an abstract data typemakes it possible both to specify symbolprocessing on an abstract level in theattribute grammar and let the underly-ing system generate a suitable imple-mentation.

The obvious problem with this idealis-tic view is that the visibility and typerules of two languages can be totally dif-ferent, and that even related languagesmay have subtle variations in their sym-bol processing policy. That is why it isquite hard to design high-level abstrac-tions that universally apply to a largeclass of programming languages. Onegeneral model of visibility control is given

in Garrison [1987], including an exten-sive study of the variations in differentlanguages. However, the model has notbeen implemented. Another approach isto concentrate on features that are com-mon in a family of related languages andto design high-level abstractions for thoselanguages only. Such a resticted symboltable abstraction for one-pass languageshas been presented in Koskimies [1984]and implemented in HLP84 [Koskimieset al. 1988] and TOOLS [Koskimies andPaakki 1990]. Reiss [1983] presents amore general model that is influencedmost notably by the features of Ada. Themodel has been integrated as part of theACORN compiler writing system [Reiss1987]. Other approaches to high-level de-scription of common symbol table mecha-nisms include those of Vorthmann andLeBlanc [1988] and Kastens and Waite[1991].

2.3.1 Linguist

Modular attribute grammars are dis-cussed in Farrow et al. [1992] under thenotion of composable attribute gram-

mars. The module concept of this formal-ism has been designed to support reuseand separate implementation of attributegrammar units. Composable attributegrammars are directed at separate speci-fication of different subproblems in lan-

guage processing and thus belong to thecategory “Semantic aspect = Module” ofthe modular attribute grammar method-ology. A restricted class, separable com -

posable attribute grammars, has beenimplemented in the Linguist translatorwriting system [Declarative Systems1992].

A composable attribute grammar con-sists of a set of component (module) at-tribute grammars and one glue gram-mar. Each component specifies the phrasestructure of a particular subproblem.Since the components should be highlyreusable, they are expressed in terms ofabstract, language-independent context-free grammars. The syntactic structureof the language under implementation isspecified as the glue grammar, where thesyntax of the language is given as a con-



crete context-free grammar, and the se-mantics is defined in terms of relevantcomponent grammars. The ideal princi-ple is to pick the components from aspecification library fit for the particularlanguage and for the specific implemen-tation strategy.

The interface of a component consistsof its (abstract) context-free grammar andits association of data flow with the (ab-stract) terminal svmbols. The noveldesign decision ha; been to base thesemantic interfacing on the input andoutput attributes of the terminals of acomponent attribute grammar. The inputattributes represent contextual data tothe component, while the output at-tributes represent resulting semantic in-formation. This principle is quite simpleand makes it easy to verify the correct-ness of the final interfaces. On the otherhand, the method may in some cases forcethe introduction of unintuitive and artifi-cial semantic handles into the compo-nents.

The explicit interactions between com-ponent attribute grammars are not fixeduntil the glue grammar is constructed.Hence, modularity is preserved, and acomponent can be freely modified with-out affecting the other components. Amodification of a component even leavesthe glue grammar unchanged, as long asthe interface remains unaffected. Thisproperty makes it possible to design in-terchangeable components having thesame phrase structure and interface (i.e.,they address the same problem) but ex-pressing different solutions for differentclasses of languages,

As an example of the approach, wespecify the DESK compiler as a compos-able attribute grammar. Our implemen-tation must take care of two semanticsubproblems: name analysis and codegeneration. Accordingly, it is reasonableto base the modular specification on twocomponent attribute grammars, one forname analysis and the other for codegeneration.

Since the notation for composable at-tribute grammars has not been abso-lutely fixed in Farrow et al. [ 1992], we

use the same basic notations as earlier.An abstract terminal symbol t with inputattributes il, . . . . in and output attributes01, ..., Om is defined as follows:

terminal t: {in 11,. . .. in. out ol, . . ..om}

The productions are preceded by theirsymbolic name, to be used in the gluegrammar. A grammar module M is ex-pressed in the form

module M

end M.

The component grammar Env for nameanalysis is given below. For emphasizingthe reuse property of grammar modules,the component specifies symbol tablemanagement in a slightly more generalmanner than is actually needed for im-plementing the DESK language. Thecomponent specifies the pattern of thename analysis phase for a typical un-structured programming language withdeclared symbols. The grammar couldthus be adopted as a fragment in thespecification and implementation of an-other language in the unstructured fam-ily. We make use of the same attributesas in the attribute grammar (1 .2) of Ex-ample 1.3.1.

Module Envterminal symbolDEF {in name, value, out ok}terminal symboIREF, {in name, out value, ok}lnit symbols, + symbolsz

—creation of an empty symbol table

{symbols,.envl = ( ),symbols, envs = symbolsz. envs}

empty, symbols + s

—empty structure{symbols envs = symbols.enw}

chain symbolsl + symbolsa

—symbol table propagation

{symbols, .envl = symbols, enw,symbolsl ,envs = symbolsz, envs}

IW symbolsl + symbolsz symbols~—recursive structure

{symbolsz.envr = symbols, ,envl,symbols~ ,enw = symbols2 envs,symbols, .envs = symbols~ envs}

def symbols + symbolDEF—symbol declaration



{symbols.envs = symbols.envl +(symbolDEF,name, symbolDEF,value),

symbolDEF.ok = notIsm (symbolDEF.name, symbols. envl)}

ref symbols + symbolREF—symbol reference

{symbols.envs = symbols.enwsymbolREF.value

= getvalue (symbolREF.name, symbols.envl),

symbolREF.ok= Ism (symbolREF,name, symbols,envi)}

end Env,

The component grammar Code for as-sembly code generation is given below.The module is constructed with the ob-servation that in an assembly problem ofthis kind we must be able to handle (1)generation of single instructions, (2) gen-eration of instruction sequences, and (3)provision of final code.

module Codeterminal Ioadable’ {in: value, ok}terminal operand: {in: instr, ok}terminal end: {in. ok, out: code}.sIngle: assembly + loadable

—single load Instruction

{assembly .code = if Ioadable.okthen (LOAD, Ioadable.value)

elaa (HALT,0)}seq: assemblyl ~ assembly2 operand

—sequence

{assembly, code = if operand.okthen assembly2 code

+operand.instrelse (HALT,o)}

final: assembly, ~ assembly2 end—total code

{assembly, code = assembly2.code,end.code = if end.okthen assembly2 code+ (PRINT, O)

+ (HALT, o)else (HALT, o)}

end Code.

Finally, the glue attribute grammar forthe DESK language is constructed. Thecomplete specification imports the com-ponent grammars Env and Code. Themethod of integrating component gram-mars into a total attribute grammar is touse syntactic attributes and production

constructors in the glue grammar. A non-terminal N of the glue grammar mayhave a syntactic attribute with the same

name a as a nonterminal defined in oneof the component grammars. Supposethat a component grammar includes thefollowing definition for a:

r:a~bl. .. bn }...}

Then the semantic rule for N.a must beof the following form:

N.a=r(bl,..., b~)

where r is a production constructor (i.e.,the name of a production in the com-ponent grammar), and each b is anoccurrence of a syntactic attribute or anapplication of another production con-structor. Hence, the rule for N .a inte-grates the glue grammar structurallywith the component grammar, and theactual semantic rules applied on N .a arethose defined in production r of the com-ponent grammar. If some element b inproduction r is a terminal symbol, t~enthe corresponding element b; in the glueproduction must be a local terminal con-stant (see below). The glue productionmust in that case define the input at-tributes of the terminal constant, servingas the input interface to the correspond-ing terminal symbol in the componentproduction r. Accordingly, the output at-tributes of the terminal symbol, repre-senting its output interface, can beaccessed in the glue grammar via thecorresponding terminal constant.

Recall that the only form of propaga-tion of data between the modules is ex-pressed using the terminal symbols ofthe components and the correspondingterminal constants of the glue. (Syn-tactic) nonterminals cannot be used forthis purpose, but they instead serve fordefining the phrase structure of attributeevaluation in the component grammars.We use the following notation for defin-ing a terminal constant c that is mappedwith a terminal symbol t:

c: t = {(definition of input attributes)}

The concrete glue grammar for DESKis given in Algorithm 1. The concreteattribute evaluation scheme for thesource program “PRINT x WHERE x = 2“,

as defined by the glue grammar DESK, is



Algorithm 1.

module DESK (Env, Code) -- glue grammar, given In terms of––the components Env and Code

Program ~ ‘PRINT’ ExpressIon ConstParl

{Programsymbols = –– syntactic attribute

Init (l!st(ConstParf symbols, -production constructorExpression. symbols)),

Program assembly = flnal(Expresslon assembly, STOP),

Program.code = STOP, code, ––ordinary attribute

STOP. end = {ok = ConstPart ok}} –– terminal constant

Expressionl + ExpressIon ~ ‘+‘ Factor

{Expresslonl symbols= lwt(Expresslon ~ symbols, Factorsymbols),ExpressIon, assembly= seq(Expresslon2 assembly, OP),

OP. operand = {Instr = (ADD, Factor. value), ok= Factor ok}}

ExpressIon ~ Factor

{Expression.symbols = cham(Factor.symbols),ExpressIon assembly= single,

OP: Ioadable = {value = Factor value, ok = Factor ok}}

Factor ~ ConstName

{Factor. symbols = ref(CREF),Factor value = CREF value,Factor ok= CREF ok,CREF: symbolREF = {name = ConstName.name}}

Factor ~ Number

{Factor symbols = empty,Factor value = Number value,

Factor.ok = true}

ConstName ~ Id {ConstName name = Id name}

ConstPart ~ s {ConstPart,symbols = empty, ConstPart ok = true}

ConstPart ~ ‘WHERE’ ConstDefLlst

{ConstPart.symbols = cham(ConstDefLlst symbols),ConstPart,ok = ConstDefLW,ok}

ConstDefListl s ConstDefList2 ‘,’ ConstDef

{ConstDefLlstj symbols= hst (ConstDefLMz.symbols, def(CDEF)),ConstDefLlstl ok = ConstDefLlst2 ok and CDEF ok,CDEF: symboiDEF = {name = ConstDef name,

value = ConstDef,value}}

ConstDefLlst + ConstDef

{ConstDefLM.symbols = def(CDEF),ConstDefLM,ok = true,CDEF. symbol DEF = {name = ConstDef name,

value = ConstDef value}}

ConstDef + GonstName = Number

{ConstDef.name = ConstName name,ConstDef value = Number value}

end DESK.

illustrated in Figure 7. The figure shows trees stand for grammar symbols of thehow the glue grammar gives rise concep- corresponding component grammars Envtually to two abstract attributed syntax and Code. The association of a node totrees, one for name analysis and the other the symbol in the glue grammar is indi-for code generation. The nodes in these cated by giving in parenthesis the name

ACM Computmg Surveys, Vol. 27, No 2, June 1995

Attribute Grarnrnar Paradigms * 225

symbols assembly

22?7 rra!?op)

/ (Con~tPari) ~+[ (;f~~~on)~

Figure 7. Tree association by modular attribution.

of the glue symbol. The tree rooted by the cility, provided by the conceptual separa-node with label symbols (Program) repre-sents name analysis, and the tree rootedby the node with label assembly (Pro-gram) is for code generation. Note that anode is associated with attribute in-stances for both its component symbol

(e.g., symbols) and its glue symbol (e.g.,Program).

For simplicity, Figure 7 includes onlythe environment attribute instances ofthe nodes for symbols (envi to the leftand envs to the right of a node), exceptfor one node that illustrates the seman-tic coupling between the attributed treesvia the instances of value and ok. Theattribution of symbolDEF has been sim-plified. Moreover, the attributed tree forcode generation is given in a reducedform that includes only the interface be-tween the two trees. Notice that theorder of the subtrees for the constantdefinition part and for the expression partof the source program (nodes for Const-Part and Expression, respectively) is dif-ferent from the order in the glue gram-mar and in the source program. This fa-

tion of the (abstract) component gram-mars and the (concrete) glue grammar,makes it possible to elegantly coerce theconcrete right-to-left flow of symbol tableinformation (see Figure 4) into the ab-stract left-to-right form as implementedin the component grammar Env.

2.4 Object-Clriented Attribute Grammars

In the previous section we characterizedmodular programming as a paradigmbased on static decomposition of pro-grams, data abstraction, informationhiding, and separate compilation. Object-

oriented program ming is a refined formof the structured and modular styles andcombines the concepts of a module (apurely syntactic unit) and a type (a con-struct that can give rise to an arbitrarynumber of dynamic instances) into a sin-gle concept, a class. Thus, a class can beemployed on one hand as a programstructuring tool and on the other hand asan abstract data type. The entities thatare created at run-time as instances of a


226 * Jukka Paakki

class are called objects. The third funda-mental concept is inheritance: a class canbe defined as a generalization (super-class) or a specialization (subclass) of an-other class. Accordingly, the objects canbe grouped into hierarchies that are in-duced by their superclass and subclassrelations. Objects of a subclass inheritimplicitly all the properties defined forobjects of the superclass. Additionally,objects may have specific properties de-fined in the subclass. The referencemechanism is polymorphic: a referenceof class C can denote, besides an object ofclass C, also an object of a subclass of C.This feature implies that in general theactual object referenced must be resolvedat run-time by dynamic binding.

The basic concepts of object-orientedprogramming, in addition to those ofmodular programming, are thus

e classes

e inheritance

0 objects, having an inner state and a setof applicable operations (“methods”)

* polymorphism and dynamic binding.

These special properties support systemreusability and extendibility in a moreflexible way than the non-object-orientedstructuring facilities discussed in Sec-tions 2.2 and 2.3: a new system can bebuilt from an existing one by specializingthe existing classes and objects throughinheritance to flt the problem domainbetter.

When introducing object-oriented con-cepts into attribute grammars, the fol-lowing correspondence is one relevantframework for object-oriented attribute

grammars:

Ncmtermimd = Class

With respect to static interpretation ofclasses, this amounts to the structuredand modular language processingparadigms discussed in Sections 2.2 and2.3: nonterminals serve as structuringtools of the attribute grammar. The es-sential feature, however, that makes the

object-oriented style most powerful inlanguage processing is the dynamicnature of nonterminals it promotes: anonterminal can be considered as anabstract type (class) that specifies theproperties of the dynamically created ob-jects of that type. This view is consistentwith the principle used in syntax-di-rected language processing where non-terminals, terminals, and productionsrepresent a static language specificationfrom which an underlying parser createsthe corresponding dynamic objects asnodes of the parse tree.

Object-oriented language processing isappropriate for both compilation and in-terpretation, the two main implementa-tion schemes of programming languages.The operations of an object can specifyeither compilation of the correspondinglanguage structure into some target codeor dynamic execution of the object interms of its state. Hence, objects can beregarded as abstract operations of an un-derlying intermediate language that isexecuted by an abstract interpreter.

In the object-oriented language pro-cessing paradigm a source program isviewed as a set of interrelated and hier-archical objects that behave according tothe semantics of the source language. Theobjects are created as instances of thenonterminal classes that specify both thesyntax and the semantics of the objects.Hence, for each object there is (1) a non-terminal (class) that defines the syntac-tic structure of the object in terms ofproductions and (2) a class (nonterminal)that specifies the static and dynamic se-mantics of the object in terms of its at-tributes (“state”) and operations. Thispertains to an application-oriented viewthat is often mentioned as a profoundfactor in the object-oriented approach to-ward software engineering.

The correspondence “Nonterminal =Class” suggests that the syntactic specifi-

cation of the source language derivesimplicitly the superclass/subclass hier-archy in the attribute grammar and, froma dynamic point of view, the relationsbetween the objects generated by a sourceprogram (i.e., the “attributed derivation

ACM Computmg Surveys. Vol 27, NCI 2, ,June 1995


tree”). In order to gurantee that the classand object hierarchies are regular enoughboth from a general object-oriented andfrom a language processing point of view,the syntactic specification should be givenin a disciplined form. The idea of map-ping a context-free grammar into a classhierarchy has implicitly been applied inlanguage definitions as a rather naturaltool. For instance, the production

compound_ statement ::= lf_statement Icase_ statement Iloop_ statement I block_ statement Iaccept_ statement I select_ statement

in the Ada reference manual specifiesthat: “if_statement is-a compound_statement”, ‘[case _statement is-a com-pound_ statement”,..., “select_ statementis-a compound _statement” [Departmentof Defense 1983]. Different forms of ob-ject-oriented context-free grammars aredefined in Koskimies and Paakki [ 1990]and Koskimies [1991].

A conceptual correspondence betweennonterminals and classes is the basis inTOOLS [Koskimies and Paakki 1990] andin AG [Grosch 1990]. The TOOLS systemhas been presented in Section 2.2, wherestructured attribute grammars were dis-cussed. Besides a block-structured basis,the specification language of TOOLS hasa number of primitives that support theobject-oriented language processingmethodology. For instance, nonterminalscan be organized as classes into (re-stricted) inheritance hierarchies over at-tributes. The classes may also specifyoperations for their objects that are poly-morphic within their own class hierar-chy. Some of these features were appliedin the example of Section 2.2.1.

A slightly broader perspective is fol-lowed in Mjdlner\Orm [Hedin 1989] andin OOAG [Shinoda and Katayama 1990]that suggest the correspondence

Production = Class

A completely different view is taken inSmallYACC where a context-free gram-mar as a whole is subject to inheritance

of productions from “superclass” gram-mars [Aksit et al. 1990].

2.4.1 Mjdlner 10rm

Mjdlner/Orm is a metaprogrammingsystem based on a general object-ori-ented view of programs. The systemmaintains programs consistently as at-tributed abstract syntax trees, and sup-ports the development of integratedprogramming environments includingsuch program processing tools assyntax-directed editors and interpreters.An overview of the system is included inKnudsen et al. [19931.

Mjdlner/Orrn inciudes as a centralsubcomponent an object-oriented at-tribute grammar-based metalanguage forspecifying and developing different kindsof language processors of a programmingenvironment. Besides treating nontermi-nals as (abstract) classes. the metalan-guage of Mjdlner/Orm also considerseach production as a class that specifiesthe syntactic structure of the production,the attributes of its left-hand-side non-terminal, and the associated (default) se-mantic rules. All these elements can beinherited, specialized, and overridden insubclasses, thus introducing uirtual

properties and dynamic binding into themetalanguage. The original object-ori-ented notation of Mjdlner/Orm is pre-sented in Hedin [1989] and its furtherelaboration in Hedin [ 1992].

Because Mjdlner/Orm is designed toproduce integrated environments, thecontext-free grammar for a language isgiven in terms of its abstract syntax. Inorder to process concrete programs, aspecial interface must be separately builtbetween the concrete and the abstractrepresentation. Each production is ex-pressed as a class that can be one of thefollowing kinds:

(1) An abstract class models an entitywhose syntactic structure is not fixedand that usually represents generalsemantic properties.

(2) A structured class represents an en-tity with a particular syntactic out-look.


228 . Jukka Paakkl

(3) A case class represents an entitywhose syntactic structure is inheritedas is but whose semantics can be re-fined.

A structured class specifies a production’sright-hand side either as a sequence ofnamed symbols, as a symbol list, or as alexical element (“lexeme”). In addition tothe conventional inherited (ancestral inthe MjiJner/Orm terminology) and syn-thesized attributes local attributes canbe associated with a production. Theycannot be accessed from outside of theproduction class.

The production classes are defined us-ing the following notation. P denotes thename of the class, and S its optionalsuperclass. A sequence of attribute decla-rations and semantic rules is denotedbriefly by Sem.

abstract, and therefore the delimiters andoperators of DESK are not specified.

The abstract classes in Algorithm 2,Node, Root, Descendant, Expression, andConstPart, are semantic superclasses thatdo not give rise to explicit objects in thesyntax tree. They are instead used forspecifying general properties of treenodes, most notably the common at-tributes and their default semantic rules.These general properties are refined,when needed, in the structured and casesubclasses Program, IdUse, Number,BinOp, Addition, EmptyConstPart, Const-DefList, and ConstDef specifying the ac-tual objects as tree nodes.

The class hierarchy of nonterminals asspecified by the grammar is depicted inFigure 8 with subclasses drawn belowtheir superclass. The classes are associ-

(P) (S) ,= Abstract Sem (abstract class)(P) : (S), ,= (C)* Sem (structured Ilst of symbols C)(P): (S): :={(tl Cl)& . ..&(tn. Cn)}Sem

(structured sequence of symbolstl (of class Cl),... ,tn (of class Cn))

(P) : (S) : := L.exeme Sem (structured Iexeme class)(P) : (S) = Case Sem (case class)

In the conventional notation of contex-free grammars, these correspond to thefollowing productions, respectively:

P+ P11P21 . . .p+c’P~C1.. .Cnp * some lexlcal defirutionP + same syntax as defined for S

Hence, an abstract class models a groupof related language entities PI, P2, . . .(such as a compound_ statement of Ada;see above), and lexeme classes stand forterminal symbols. Case classes are notgiven any syntactic structure becausethey are implicitly defined by the super-class S.

As an example of the approach,we give an object-oriented attributegrammar for DESK in the Mjdlner/Ormmetalanguage in Algorithm 2. Inheritedattributes are denoted with BJIC and syn-thesized attributes with S)m. Note thatthe underlying context-free grammar is

ated with their final set of attributes,obtained after applying the inheritancemechanism. The figure also shows theborder between the abstract classes andtheir structured and case subclasses. No-tice that an abstract class must have atleast one structured subclass in order tobe useful for the implementation. Theflexibility granted by inheritance is theintroduction of attributes and semanticrules at any level of the class hierarchy.Default behavior is typically specified inthe abstract classes and redefined in theirsubclasses, If necessary. For instance, themultiple semantic rule “for all sons (X)in Descendant son (X). envi: = ( )“ for theclass Root states that all the Descendantsons of a Root object node in an abstractsyntax tree will get an empty tables asthe default value of their envi attribute.This default rule is partially overriddenin the class Program that specifies thatthe envl attribute of an Expression objectnode (with Descendant as superclass)

ACM Computing Surveys, Vol 27, No 2, June 1995


Algorithm 2.

(Node) ::= Abstract, --general node ofanabstract syntax tree

(Root), (Node):: = Abstract ––abstract root nodefor all sons(X) in Descendant son(X),envl : = ( ),

(Descendant): (Node): : = Abstract ––abstract interior nodeAnc enw: SymbolTable; Syn ok Boolean;for all sons(X) in Descendant son(X),env! = enw;

ok:= true,

(Program) (Root) ::={(e. Expression) &(cp ConstPart)}

––structured class for production--Programa Expression ConstPart

Syn targetCode lnstrLlst,e.envi = cp, envs;targetCode: = if cp,ok then e.code + (PRINT, O) + (HALT, O)

else (HALT, o);

(Expression) : (Descendant)::= Abstract

Syn code: lnstrLlst; Syn value: Integer;code: = (HALT, o);value:= O;

(ldUse) : (Expression)::= Lexerneok =isin(string, envi),value: = getvalue(strwrg, envl),

code:s if ok then (LOA13, value) else (HALT, O);

(Number) (Expression)::= Lexeme

value: = StrTolnt(stnng);

code: = (LOAD, value),

(BmOp) : (Expression) ::={(left: ExpressIon) & (right: ExpressIon)};

(Addition) : (BmOp) :: = Casecode:=if nght.okt henleft.code+ (ADD, nght.value)

else (HALT, o);

(ConstPart): (Descendant): : = Abstract

Syn envs: SymbolTable,envs:=( ),

(EmptyConstPart) :( ConstPart) ::={ };

{ConstDefList) :( ConstPart).. ={(cp ConstPart) &(cd:ConstDef)}

ok:= cp.ok and not ism(cd.name, cp.envs);envs: = cp.envs + (cd. name, cd,value);

<ConstDef): (Node)::= {(I: Id) & (n: Number)}Syn name: String; Syn value: Integer;name: = istring,value: = n.value;

(Id) ,: = Lexeme,

shall not have the empty table as its attribute string that gives the lexical con-value but instead a copy of the synthe- tents of a terminal symbol, that is, of ansized envs instance of the sibling Const- object of a lexeme class. StrTolnt is aPart node. predefine function that returns the inte-

In the object-oriented attribute gram- ger value of a character string consistingmar above we have used the intrinsic of numerals. Note that since productions


230 a Jukka Paakki

Node

IRoot Descendant

(enw,ok)

Program(targetCode)

Empty ConstPart Cons! DefLlst

(enw, ok,envs)

IdUse Number BlnOp

(env,ok (envl,ok, (enw,ok,

code value) code, value) code, value)

I

Addlt!on

(enw,ok,

code, value)

Figure8. Class hierarchy of productions.

are represented as (named) classes inMjdlner/Orm, the alternative produc-tions must be uniquely named (e.g.,(Em ptyConstPart)). This is a central prin-ciple of object-oriented context-free gram-mars in general.

The example illustrates some impor-tant aspects of object-oriented attributegrammars. Inheritance of attributes andsemantic rules makes object-oriented at-tribute grammars shorter than theirstandard counterparts. Having generalsemantic properties centralized in oneplace (in an abstract class) makes it eas-ier to understand and maintain the spec-ifications. Polymorphism complementsthe classification and inheritance frame-work by making it possible for an objectof class C to apply properties imple-mented in the subclasses of C. This isshown in our example, e.g., by the se-mantic rule

code. = if right.ok then Ieft. code+(ADD, nght.value) else (HALT, O)

specified for the class Addition. Since leftis of class Expression, Ieft.code is allowedto stand for a code attribute defined inany of the subclasses of Expression:IdUse, Number, BinOp (applies the de-fault of class Expression), or Addition. Theselection of the applied rule for Ieft. codeis made by dynamic binding, on the basisof the actual class of the object that /eftrepresents at run-time of the DESK com-piler. Thus, the dynamic binding prop-erty introduces special semantic powerinto the attribute evaluation process sim-ilar to the primitives to be discussed inSection 3. We have, however, classifiedthe formalism as an organizationalparadigm rather than an eval-uation paradigm because most of thecentral features of object-oriented attri-bute grammars have their merits on theorganizational side.

The fusion of attribute inheritance andclass inheritance in Mjdlner/Orm causessome unexpected problems. Since a


Attribute Grammar Paradigms w .231

structured class C with structure {(a: A)& (b: B)} only knows the attributes ofthe (static) classes A and B and not theattributes of their (dynamic) subclasses

(since these depend on the shape of thesyntax tree), one cannot ensure that allthe inherited attributes of the dynamicsubclasses have a defining rule in theclass C. To prevent such problems withwell-definedness, dynamic subclasses arenot allowed to have inherited attributesat all. The same reason rules out multi-ple inheritance as well: a class (produc-tion) may have only one immediatesuperclass (production) [Hedin 1989].

Another object-oriented enhancementin Mjdlner\Orm is to allow references tomutable objects as a domain of at-tributes. This mechanism has been devel-oped especially for flexible attributereevaluation in incremental semanticanalysis. An account of the developedclass of door attribute grammars is givenin Hedin [1992; 1994].

3. EVALUATION PARADIGMS

In Section 2 we have presented tech-niques for organizing attribute gram-mars into independent and coherentunits. The organizational paradigms con-tribute mostly to managing the complex-ity of large specifications, whereas theobjective of this section is to concentrateon the attribute evaluation process anddiscuss how its power can be raised withspecial mechanisms. The presented for-malisms are more expressive than thestandard notion of attribute grammars.Unlike with the organizational para-digms, a specification written in any ofthese styles cannot be trivially trans-formed into an equivalent standard at-tribute grammar.

The semantic power of the paradigmsis due to the use of special computationalprimitives of logic and functional pro-gramming in attribute evaluation. Thesemechanisms make it possible to accept arestricted form of temporarily undefined

attribute values, a feature which is con-sidered formidable in standard attributegrammars based on strict semantic func-tions.

The evaluation paradigms can be re-lated to standard attribute grammars by

using characteristic dependency graphs

as the common denominator. Mostnotably, extensions of (one-pass) L-

attributed grammars and well-definedattribute grammars are addressed inSection 3.1 on logic attribute grammarsand in Section 3.2 on functional attributegrammars, respectively.

3.1 Logic Attribute Grammars

In declarative programming, the empha-sis is laid on expressing the problem ab-stractly rather than on expressing anexplicit solution to that problem, as isthe case with imperative languages.Logic programming is a declarativeparadigm founded on the mathematicalsystem of predicate calculus. A logic pro-gram is given as a set of clauses (alsocalled rules) over relations between ob-jects of the problem domain. The clausescorrespond to formulas of first-order logicwith implication as the major logical con-nective and with at most one atom as theconclusion. Hence, logic programming isnot based on full mathematical logic butinstead on the computable Horn subsetof first-order logic.

Some features making logic program-ming an established paradigm are

* relations

c nondeterminism

= logical variables

@unification.

Relations (in logic programming usuallycalled predicates) treat arguments andresults uniformly; that is, there is noexplicit division of arguments into inputand output ones. Unification is an equa-tion-solving algorithm which aims atmaking its two arguments syntacticallyequivalent by generating suitable bind-ings on variables in them. Bindings canbe made both on the arguments of f andon the arguments of g when resolving anequation f(. . . ) = g(. . . ). Hence, unifica-tion is more general that its directedcounterpart in the functional program-

ACM Computing Surveys, Vol. 27, No 2, June 1995

232 * Jukka Paakki

ming side: pattern matching (see Sec-tion 3.2).

Closely coupled with unification is theconcept of a logical variable, which makesit possible to process provisionally incom-plete values that will be completed laterduring program execution, and to buildequivalence classes over uninstantiatedvariables. When one variable in theequivalence class becomes instantiated,afi the other variables in the class will besimultaneously instantiated with thesame value.

During the execution of a logic pro-gram the choices of the next goal to besolved and the next clause to be appliedare made nondeterministically among thepotential alternatives. Ths mechanism isusually simulated in the implementa-tions by backtracking.

While the logic programming paradigmand the attribute grammar formalismmay at first glance seem to be quite dif-ferent, they both share a common struc-tural representation: the proof tree in-logic programming and the attributed

tree in attribute grammars, which pro-vides for a rigorous framework for relat-ing these two. Indeed, the relationshipbetween logic programs and attributegrammars has been analyzed to an ex-tent which makes it possible to trans-form logic programs into semanticallyequivalent attribute grammars, and viceversa [Maluszynski 1991; Deransart andMaluszynski 1985; 1993], Building sucha close relationship is based on the corre-spondence

Nonterminal = Predicate

which is the obvious result from unifyingm-oof trees and attributed derivation{rees. This characterization also directlypromotes the correspondences “Produc-tion = Clause”, “Attribute value =Term”, and “Semantic function =Predicate”, which together provide themethodological basis for logic attribute

grammars.

In addition to attribute m-ammars. thelogic programming parad~gm has beenrelated with other semantic formalisms,

such as two-level grammars [Maluszyn-ski 1982] and denotational and axiomaticsemantics [Bryant and Pan 1989]. Thisflexibility is based on the “two-level” fa-cilities of logic programming: resolutionover predicates can be applied in specify-ing a language’s syntax and unificationover terms in specifying its semantics.

The integration of attribute grammarsand logic programming can also befounded on some principle other than the‘(Nonterminal = Predicate” correspon-dence. In Sataluri [1988] a concept of“relational attribute grammars” is pre-sented that is based on the guidelineimplicit already in the preceding discus-sion:

Semantic rule = Horn clauseI 1

In this approach an attribute can flexiblybe considered as inherited or synthesizeddepending on the shape of the”derivationtree.G Another generalization is that cir-cular attribute grammars can be evalu-ated to some extent since the semanticrules written as Horn clauses accept non-strict arguments. As a third enhance-ment, relational attribute grammars mayin principle express, besides compilationfrom language A into language B, alsothe reversed compilation from B into A,

thanks to the flexibility of relations andtheir arguments [Arbab 1986]. This prin-cipal possibility of implicitly inverting at-tribute mammars is. however. limited inpractice”because of the impure featuresthat are usually included in logic pro-grams. Hence, an explicit attribute gram-mar inversion may still be necessary[Yellin 1988].

Pan is an incremental editing systemwhere logic attribute grammars (“logicalconstraint grammars”) can be applied forspecifying the static semantics of a pro-gramming language [Ballance et al. 1990;Ballance and Graham 1991]. While therelational attribute grammar style makes

6Note, however, that such generahty IS m contrastwith the consistent mherlted/synthesized prmclpleof attributes and makes It hard to verify staticallythe vahdlty of the grammar,

ACM (’omput]ng Surveys. Vol 27, No 2 June 1995

Attribute Grammar Paradigms 8 233

full use of the special features of logicprogramming, it is interesting to notethat the pragmatic development of Panhas made it necessary both to restrict theusage of the features and to modify theiroperational model. For instance, “code”and “data” are separated, and onlyground (completely instantiated) at-tribute values are accepted.

3.1.1 Definite Clause Grammars

The “Nonterminal = Predicate” corre-spondence has been adopted in a numberof syntactic tools built on top of logicprogramming. The most well-known logicgrammar formalism is the definite clause

grammars (DCGS) that were originallyintroduced for specifying and parsingnatural languages [Pereira and Warren1980]. Other formalisms of similar kindare, for example, metamorphosis gram-mars [Colmerauer 1978], gapping gram-mars [Dahl and Abramson 1984], anddefinite clause translation grammars[Abramson 1984]. A survey of logic gram-mars is given in Dahl and Abramson[1989].

DCGS are a logic counterpart to con-text-free grammars such that nontermi-nals can be augmented with arguments,and productions can be augmented witharbitrary code in Prolog. When consider-ing the arguments as “attribute values”and the embedded Prolog code as“semantic rules,” DCGS match closelywith attribute grammars. DCGS are use-ful because they are provided in manyProlog implementations. These systemsinclude as a requisite a DCG preproces-sor that translates the grammar part ofthe program into ordinary Prolog. Thegenerated program acts as a parser-driven processor for the language speci-fied in the DCG and can be directlyexecuted by the Prolog system. Note thatthe underlying linear execution model ofProlog makes DCGS operationally closeto L-attributed grammars (see Section1.3).

The DCG productions (rules) are writ-ten in the form

n(al, ..., al) + nl(bl, ..., bl),. ... n~(cl, ck), ck)

where n,nl, ..., n~ are predicates, andal, . . ..a., bl, bJ, cl,, ,c~. ... c~ (i> O,j>O, k > O) are terms. This corresponds tothe attribute grammar production

n~nl... n~}... }

such that the argument terms representattribute values of the associated nonter-minals. A terminal symbol t with at-tribute value a is represented by theunary list [t(a)], and the empty string isrepresented by an empty list. ArbitraryProlog code can be included in the rule’sright-hand side by enclosing it in curlybraces {... }.

We give an example of the DCG stylein the next section where the PROFITsystem is presented.

3.1.2 PROFIT

PROFIT is a language and system de-signed for compiler writing in a logicalstyle. PROFIT integrates logic program-ming and attribute grammars in a sim-ple manner, by extending Prolog withsome facilities that are necessary in theapplication area. The most notable facili-ties are deterministic error-recoveringDCGS and functions [Paakki and Toppola1990; Paakki 1991].

Conceptually, PROFIT is based on log-ical one-pass attribute grammars, aproper superset of L-attributed gram-mars [Paakki 1990]. The semantic powerof logical one-pass attribute grammars isgranted by the correspondence

Attribute = Logical variable

that makes it possible to delay certainattribute evaluations. The idea is to al-low the value of an attribute instance tobe undefined as long as it is not neededin making control decisions in the at-tribute evaluation process. The formal-ism restricts the binding of undefinedvalues to nonstrict argument positionsonly and guarantees that the conven-tional L-attributed evaluation strategy[Lewis et al. 1974; Bochmann 1976] is


234 * Jukka Paakkz

always able to compute the meaning of asource program.y

PROFIT is implemented by translationinto ordinary Prolog. The DCG facility isbased on a conventional error-recoveringrecursive-descent execution of LL( 1) con-text-free grammars, and the functions aretransformed into predicates. The func-tions of PROFIT are written as condi-tional equations of the form

f(fl,..., fn)=t –gj,.,9m

where f is the function’s name; the f, areits formal parameters; t is the result value(Prolog term), and the g, are guards (Pro-log predicates). When executed, thisfunction will return the value t, providedthat the formal parameter list unifieswith the actual parameter list and thatall the guards succeed. Several declara-tions can be given for f in which case thatsucceeding declaration which is givenfirst defines the result. A function mustnever fail to produce a value; in such acase execution is aborted.

Function applications are expressed asfunctional terms of the form@f(al,..., a.) where f is the function’sname, and the al are its actual parame-ters. Functional terms given in theright-hand side of a rule (DCG produc-tion) model inherited attributes and arecalled inherited functional terms,

whereas those given in the left-hand sidemodel synthesized attributes and are ac-cordingly called synthesized functional

terms.

The operational behavior of inheritedand synthesized attributes with an L-

attributed evaluation scheme is reflectedin the functional terms as follows:

(1) Let a predicate (i.e., a nonterminal) pbe associated with an inherited func-tional term:

7Note that the lo~cal variable mechamsm mayleave some attribute values temporarily undefinedduring evaluation. The formahsm, however, guar-antees that when finishing the one-pass evaluationprocess, all the synthesized attribute instances as-

sociated with the root of the parse tree have adefined (completely ground) value

(2)

r(... )~ . ..p(. ... @foal,..., an)) ...)...

When execution reaches p, the term@f(al,..., an) is first evaluated bycalling the function f with argumentsal, ..., an. Then p is entered with thevalue returned by f replacing thefunctional term.

Let a predicate q be associated with a

synthesized functional term:

q(..., @g(b,, brn),r)+,... )+ . . .

When entering q (and unifying itshead with the current goal), the term

C?g(b,,... , b~) is replaced by an aug-mented variable V. The evaluation of

<?g(bl, . . . . b~ ) is suspended untilthe body of q has been successfullyexecuted. Then g is called witharguments b,, ..., bm (having theircurrent values ), and the returnedvalue is unified with V.

Successive and nested functional termsare allowed and evaluated in a left-tnright depth-first manner.

As an example of the semantic powerof logical one-pass attribute grammars,we give the DESK attribute grammar inPROFIT. To simplify the discLlssion, theok attribute is omitted. Now the context-free grammar that corresponds to theDCG is right-recursive and not left-recursive because PROFIT accepts onlyattribute grammars whose underlyingcontext-free grammar is LL( 1 ~ (see Ahoet al. [1986]). The constructor olo / 2 repre-sents the assembly operations, and theconstructor sym / 2 represents symboltable entries. Notice that the attributesare not explicitly named.

program ([Code, op(prlnt, O), op(halt, 0)1 +[’P131NT’], expression(Env, Code’l, constpart(Env, Env).

expression (Env, [op(load, Value) ICode]) -factor (Env, Value), express ionrest(Erw, Code),

expressionrest (Env, [op(add, Value) ICode]) ~

[’+’], factor (Env, Value), expressionrest(Erw, Code).

expressionrest (Env, [ ]) + [ 1.

factor (Env, @getvalue (Name, Env)) =’constname(Name).



factor (Env, Value) e [number (Value)].

constname (Name) a [ld(Name)].

constpart (Envi, Envs) ~ [’WHERE’],constdeflist (Envi, Envs).

constpart (Env, Env) ~ [ ].

constdeflist (Envi, Envs) ~constdef (Name, Value),constdefrest

(@define(Name, Value, Envi), Envs),

constdefrest (Envi, Envs) ~

[’, ‘1, constdef (Name, Value),constdefrest(@define( Name, Value, Envi),Envs),

constdefrest (Env, Env) 4 [ ].

constdef (Name, Value) -constname(Name), [’= ‘], [number(Value)],

—semantic functions and predicates:

getvalue(Name, Env) =Value :-lookup(Namej Env, Value),

define(Name, Value, Env) =Env :-lookup(Name, Env, Value).

lookup(Key, [sym(Key, Value) IEnv], Value).

lookup(Key, [sym(Keyl, Valuel) IEnv], Value) :-Key # Keyl, lookup(Key, Env, Value).

The attributes are associated with thenonterminals of this PROFIT-DCG asfollows, where i denotes an inherited at-tribute and s a synthesized attribute:

program(s)

expression(i, s)

expression rest(i, s )

facto~i, s)

constname(s)

constpart(i, s)

constdeflist(i, s)

constdef rest(i, s )

constdef(s, s)

The semantic functions getvalue anddefine are strict in their first argumentthat gives the name of the referencedconstant. The functions are nonstrict inall the other arguments; that is, thosearguments can be uninstantiated (unde-fined) when calling the function. In addi-tion to these explicitly defined functions,we have made use of the implicit identityfunction whose argument is nonstrict,the list construction function [ ]

whose arguments are nonstrict, a few

strict constant functions, the lookuppredicate, and the built-in predicate # .

As already concluded in Example 1.3.1,the DESK attribute grammar is not L-

attributed, due to right-to-left dependen-cies for attribute occurrences Env in thefirst production. This implies that nostrict one-pass left-to-right evaluationmethod is capable of generating the tar-get code for a DESK program. The gram-mar is, however, logically one-pass sincethe non-L-attributed attributes (the firstargument of expression and constpart) arealways applied nonstrictly in the seman-tic functions. The logic-based strategy ofPROFIT succeeds therefore in evaluatingall the attributes in a top-down left-to-right manner over the (implicit) at-tributed tree for a DESK program. Inconclusion, the attribute grammar can beevaluated using a much simpler one-passstrategy than when employing a multi-pass system, such as those presented inSections 1 and 2.

One central solution is to presentthe symbol table (the attribute valuesEnv, Envi, Envs) as an incomplete datastructure. Now it is possible to insertconstants with a defined name and anundefined value into the symbol tablewhile processing the expression part ofthe source program, and to complete theentries with value information in thesubsequent constant definition part. Notethat such a facility, based on the delayedbinding property of logical variables,introduces a synthesized flavor to theformally inherited first attribute of theexpression part. Both symbol tableinsertions and lookups can be imple-mented using the same lookup predicateover the incomplete data structure. Thiselegant solution has originally been sug-gested in Warren [1980].

The target code for a DESK expressionmay also be incomplete during attributeevaluation. The PROFIT evaluator, how-ever, binds the undefined operands withthe (incomplete) entries in the symboltable. These operands will be implicitlyinstantiated while completing the symboltable during the processing of the con-


236 e Juhka Paakki

stant definition part of the source pro-gram. Thus, the final target code will becompletely defined.~ A similar delayedone-pass evaluation effect as providedhere implicitly by the logical variableshas been proposed in Nell and Vogler[1994] where unevaluated attributes aremaintained and resolved in an explicitgraph.

As an example of the logical one-passattribute evaluation process, consider thefollowing DESK program:

PRINTx+ y+xwHEREx=l, y=2

When the compiler has reached the endof the expression x + y + x, the symboltable is in the form

[sym(x, Vl), sym(y, V2) I Envl

Here V1, V2, and Env are uninstantiatedvariables (that is, undefined attributevalues). The target code has the value

[op(load, Vl), op(add, V2), op(add, vi)]

Here the second operands of the instruc-tions are bound with the correspondinguninstantiated variables in the symboltable. After processing the whole pro-gram, the symbol table has obtained itsfinal value:

[sym(x, 1), sym(y, 2) I Envl

Thanks to the logical variable facility,the target code will be simultaneouslycompleted into the following form, with-out having to employ any explicit back-patching operations:

[[op(load, 1), op(add,2), w(add,l )],

op(print, O), op(halt, O)]

3.2 FuntXiQnal Attribute Grammars

In the previous section we discussed theintegration of logic programming and at-tribute grammars. Besides logic pro-

8Note that this holds for valid source programsonly since undefined constants leave them corre-sponding operands m the target code unmstantl-ated This aspect could be improved simply by rein-troducing the ok attribute

gramming, functional programming is aparadigm dominating the declarativescene. Functional programming is basedon the mathematical model of expressingcomputation with functions. A functionf: D + R expresses a rule that maps theelements of the domain D to the ele-ments of the range R. The evolution ofthe ~“unctional programming paradigmhas produced a variety of concepts andlanguages for expressing such functions.The functional style of programming canbe summarized with the folloing charac-terist its:

_ referential transparency

e higher-order functions

~ lazy evaluation

. pattern matching

Referential transparency is the term usedtraditionally to express that the value ofan expression depends only on the valuesof its subexpressions, and that the valueof ea~ch occurrence of an object is thesame, irrespective of the context. In otherwords, side effects are ruled out. Func-tions being higher-order means that they

are ~“mst-class values and can, for in-stance, be stored in data structures andreturned as result of function calls. Lazy

evaluation is tantamount to “nonstrict-ness,” meaning that the value of an ob-ject is not computed until it is actuallyneeded, and thus the value of an argu-ment may be undefined when calling andexecuting the function. Pattern matching

is a general term used to express themechanism applied when trying to makeX and Y identical in an equation X = Ywhere X and Y are expressions. Patternmatching is restricted in functional pro-gram ming to introduce bindings only tothe left-hand side X when solving suchan ecluation. (Recall from Section 3.1 thatthe more general unification primitive oflogic programming may instantiate Y aswell.

The referential-transparency propertyis characteristic of a number of metalan-guages based on attribute grammars. Forinstance the metalanguage of GAG is, inits original form, free of side effects and

ACM Computmg Survey~, Vol 27, No 2, tJune 1995


in that respect of a functional nature[Kastens et al. 1982]. Usually the refer-entially transparent metalanguages,however, do not provide the other centralfeatures of functional programming.

Actually the special mechanisms offunctional programming have not beenexploited very extensively in attributegrammars (which is a bit surprising sincedeclarative functions are a main conceptin attribute grammars), but rather in de-notational semantics. Since denotationalsemantics-directed formal language defi-nition and implementation is an ap-proach based on valuation functions(mapping the syntactic constructs of alanguage to their semantic meanings),the central concepts of the functionalprogramming paradigm fit well with theapproach. A more detailed discussion offunctional programming exclusivelywithin denotational semantics is beyondthe scope of this survey. Such analysis isincluded in, e.g., Watt [1984] and Lee[1989].

Defining the semantics of a source lan-guage using functions makes it possibleto relate attribute grammars with deno-tational semantics. Chirica and Martin[1979], Ganzinger [1980], Mayoh [1981],and Courcelle and Franchi-Zannettacci[1982], among others, discuss methodsfor relating an attribute grammar withan equivalent denotational system of re-cursive functional equations. These for-mulations are based on the principle ofmodeling each synthesized attribute ofan attribute grammar by a functionwhich maps the underlying derivationtree and the values of the inherited at-tributes of the associated nonterminalonto the semantic value of the tree.Hence, the correspondence

Synthesized attribute = Function

is followed in these mathematical ap-proaches. The equation system may re-quire a Ieast-fixpoint computation to beapplied in attribute evaluation and maythus be rather laborious. On the otherhand, this general method makes it pos-

sible to evaluate even circular attributegrammars in case the derived recursiveformulas have a computable least-fix-point solution.

Because relating attribute grammarsand denotational semantics is based onfunctional attributes, the theoreticalguidelines mentioned above can beapplied in practice by including high-er-order functions into an attributegrammar-based metalanguage. Then thesemantic functions of an attribute gram-mar can be written in a denotationalstyle, mapping functional attribute val-ues into functional attribute values. Suchan amalgamation of these two languagedefinition formalisms provides means toexpress the “total” semantics of a pro-gramming language in a unified manner.The attribute grammar concepts of themetalanguage can be exploited in defin-ing the static semantics of the language,while the denotational concepts are bet-ter suited for defining the dynamic se-mantics, Such mixed formalisms with anautomatic implementation are proposedin, e.g., Paulson [1982], Ganzinger et al.[ 1982], and Johnsson [1987] that alsodiscuss in more detail the merits ofhigher-order functions in attribute gram-mars. The concept of higher-order func-tions is loosely applied in higher-orderattribute grammars where parts of theattributed tree can be defined in terms ofattributes and vice versa [Vogt et al.1989].

When sticking solely to the attributegrammar formalism, the most obviousway to make use of the functional pro-gramming paradigm is to express func-tionally the semantic functions of anattribute grammar. Hence the proposi-tion of

writing the semantic functions

in a functional language

results in a formalism that can be char-acterized as functional attribute gram-mars. As a concrete example of theadvantages of such grammars, we willshow in Section 3.2.1 how lazy evaluation


238 * Jukka Paakki

can be exploited to extend the concept ofwell-defined attribute grammars fromtheir original meaning to accept a re-stricted form of circular attribute depen-dencies. This enhancement will be fur-ther elaborated in Section 3.2.2 where amore powerful fixpoint evaluation tech-nique is presented.

While the power of functional attributegrammars has not been widely applied ingeneral systems, several functional ver-sions of the one-pass system YACC havebeen developed. In these tools the under-lying implementation and programminglanguage C of standard YACC has beenreplaced by a functional language. Suchfunctional parser generators are pre-sented in, e.g., Peyton Jones [1985] (withSasl as the base language), in Jones[1986] and Longley [1987] (Miranda), inCousineau and Huet [1990] (a dialect ofML), and in Appel and MacQueen [ 1991]

(standard ML). A more general view is toconsider attribute grammars as a specialclass of functional programming lan-guages, as proposed in Frost [ 1992; 1993].

3.2.1 Lazy Evaluation (FNC I ERN)

The standard definition considers circu-lar attribute grammars to be ill defined

[Knuth 19681, and therefore such gram-mars are rejected by a vast majority oflanguage processor generators. Recallthat an attribute grammar is circular, ifit generates an attributed tree where anattribute instance depends transitivelyon itself.

Forbidding circular attribute depen-dencies exclusively is inconvenient be-cause many common language processingtasks could quite naturally be expressedas a simple circular attribute grammar.As a demonstrating example, let us re-vise the DESK language such that thevalue of a constant can be defined sym-bolically as well. Moreover, the constantdefinitions can be given in any order.Thus, the following is a program in theextended language, in the sequel referredto as DESK + :

PRINT x+y+l WHERE x=y, y=z, z= 2(3,1)

The symbolic value of a constant may

be defined in terms of a single constantonly. This restriction is made for simpli-fying the discussion. Of course, a realisticlanguage would accept general expres-sions, but such an extension would notbring any additional nuances into ourdiscussion of circularity. Recursively ormutually defined constants are not ac-cepted in DESK + . For instance, the fol-lowing program is illegal:

PRINT x+y+l WHERE x=y, y=x

An attribute grammar for DESK + isgiven in Algorithm 3. Since a particularmetalanguage is not essential for ourtheme, we use the same pure notation asin Example 1.3.1. Much of the originalDESK grammar remains unaffected bythe generalization of allowing symboli-cally defined constants. The only notablereformulation is that the symbol table isalso needed for processing the constantdefinition part of a DESK + program,since now the constant values have to beavailable even there. This feature is ex-pressed using the inherited attribute envithat is propagated to the constant defini-tion part. To select a literal value or asymbolically defined value for a constant,we make use of an additional synthe-sized attribute isliteral to denote whetheror not a value is literal. The semanticfunction undefined represents an unde-fined (and useless) attribute value. Forsimplicity of discussion, the ok attributeis omitted for the constant definition part.Consequently, invalidity of the programis manifested by abortion of the executedcode with a premature HALT instruction.The crucial semantic rules of the gram-mar are emphasized.

By constructing the characteristic de-pendency graphs, the attribute grammarcan be shown to be circular and thus illdefined in the original sense; for in-stance, the grammar is not absolutelynoncircular.g To verify this, Figure 9

9The grammar could be transformed mto a noncm-cular form (e.g., by introducing additional symboltable attributes), but then the specification wouldbecome far less declarative,



Algorithm 3.

Program + ‘PRINT’ Expression ConstPart{Program,code = Expression,code + (PRINT, o) + (HALT, o),

Expression.envl = ConstPaR,envs,

ConstParf.envi = ConstPart.envs}

Expressionl + ExpressIonp ‘+’ Factor {--as m Example 1.3.1 --}

Expression + Factor {--aS m Example 1.3.1 --}

Factor ~ ConstName {--as in Example 1.3.1 --}

Factor a Number {--as m Example 1.3.1 --}

ConstName ~ id {- -as in Example 13.1 --}

ConstPart ~ s {ConstPart.envs = ( )}

ConstParl ~ ‘WHERE’ ConstDefList

{ConstPart.envs = ConstDefLM.envs,ConstDefLW.envl = ConstPart,env[}

ConstDefLlstl + ConstDefListz ‘,’ ConstDef

{ConstDefL@ .envs = ConstDefLlstz.envs +(ConstDef name, ConstDef.value),

ConstDefLtst2,envi = ConstDefLtstl ,envi,

ConstDef.envl = ConstDefListl .envi}

ConstDefList + ConstDef

{ConstDefLlst.envs = (ConstDef.name, ConstDef.value),ConstDef,envi = ConstDefList.envi)

ConstDef ~ ConstName ‘ = ‘ Value{ConstDef.name = ConstName.name,ConstDef. value= if Value. isliteral then Value. value

else getvalue(Value. name, ConstDef. enw)}

Value ~ Number

{Value. ishteral = true, Value.value = Number.value,Value,name = undefined}

Value + ConstName

{Value. dlteral = fake, Value.value = undefined,Value name = ConstName.name}

sketches the attribute dependency graphfor the following DESK + program:

PRINTx+ y+lwHEREx=y, y=2

The cyclic dependency paths are indi-cated by arrows with a solid head.

Let us consider the DESK + grammaras a functional attribute grammar; thatis, the semantic functions (including theidentity function) are assumed to be im-plemented in a functional language witha lazy “call-by-need” evaluation strategy.As a consequence, only those attributeinstances will be evaluated that are actu-ally needed by the compiler to generatethe target code for the source program.Now the termination problem with recur-

sive evaluation of circular attributegrammars becomes less severe.

Assume that the DESK + programdoes not contain any symbolically de-fined constants. In that case all the islit-eral attribute instances associated withthe Value nodes will have the value true,and the compiler does not execute anygettdue function call associated with theproduction “ConstDef - ConstName ‘ = ‘Value” in Algorithm 3. Therefore, none ofthe useless envi attribute instances forthe Const Part subtree have to be evalu-ated, Hence, the spurious static cycle inthe attribute dependency graph will bedynamically removed by the lazy evalua-tion mechanism (cf., Figure 9).

ACM Computing Surveys, Vol 27, No. 2, June 1995

240 * Jukka Paakki

en~ConstDefL(st envsk envl ConslDef i ~.,,,.

Hdlllts ,On. m(=f A ConstName name \ Ah I

ConstName name

‘a~”e ‘nfe=GizE= I

Number value

Id2

1x ConstName name

IId

Figure 9. Cmcular attribute dependency graph

The solution is only partial, though.While the lazy strategy is able to compilethe following DESK + program correctly

PRINTx+ y+l WHERE x=l, y=2 (3.2)

it does not terminate, e.g., with the pro-gram (3. 1), because symbolically definedconstants induce a true cycle on the at-tributed tree (cf., Figure 9). Notice, how-ever, that a conventional strict attributeevaluation strategy would loop even forthe DESK + program (3.2) since in thatcase all the attribute instances (includ-ing the circularly defined envi instances)

would have to be evaluated, whether ac-tually needed or not.

Functional attribute grammars are im-plemented in some systems. The lazy at-tribute evaluation method describedabove is provided, for example, inFNC/ERN where the language for thesemantic functions is Lisp [Jourdan1984]. The system implements a func-

tional attribute grammar by translatingeach synthesized attribute into a func-tion that takes a syntactic subtree andthe values of some inherited attributesas arguments and that returns the valueof the synthesized attribute as result.Hence, the implementation follows the“Synthesized attribute = Function” prin-ciple as well. The FNC component of thesystem implements the class of abso-lutely noncircular attribute grammarsthat excludes statically circular attri-bute grammars, such as the DESK +grammar above. However, the ERNcomponent provides for a dynamicallynoncircular evaluation scheme that be-haves in the manner discussed above forDESK + programs with literal constantsonly.

A different method of lazy attributeevaluation is implemented in Elegant

[Augusteijn 19901. The system accepts“pseudocircular” attribute grammars

ACM Computing Surveys Vol 27, No 2, June 1995


where the circular dependency chainsmust be explicitly broken by the user

with an additional semantic rule for oneof the attributes within each cycle. Thismechanism, however, has not been for-malized nor completely automated.

3.2.2 Fixed-Point Evaluation (Linguist)

In the previous section we discussed theproblem of circular attribute grammarsand presented a partial solution based ona lazy attribute evaluation method. Inthis section we continue with a specialtechnique that is more powerful than thelazy strategy, in that a larger class ofcyclic dependencies can be solved. Note,however, that even this method based onan iterative computation scheme is ableto evaluate only a subclass of circularattribute grammars. In order to evaluategrammars falling beyond this technique,it would be necessary to transform thegrammar into a tractable form, e.g., byintroducing more powerful semanticfunctions, which usuallly would make theattribute grammar more complex thanthe original circular one.

Formally, a circular attribute gram-mar induces a recursive definition x =

f(y) . on all the attribute instances xwlthm a cycle in the attribute depen-dency graph. Extensive investigations,based on mathematical fixed-point the-ory [Kleene 1952], have been made onestablishing computational means tosolve equations of such form. The generalidea is to compute the least fixed point ofx by starting from an initial special bot-tom value .L , and by successively ap-proximating the value of x until it is notchanged anymore; that is, the least fixedpoint has been reachedi

~:=~;~:=f(~);~:=f(~);,.

To guarantee termination of the fixed-point computation, the domain of x mustbe a complete partial order in whichequality can be tested (having L as thesmallest value), and the function f mustbe (Scott-) continuous [Chirica andMartin 1979]. If that is the case thensome computation of f(x) in the se-

quence above will finally return the cur-rent value of its parameter x, and itera-tion can be finished with x having itsfinal value f(f(... f(l))..)).

We can apply an iterative fixed-pointattribute evaluation method on the circu-lar DESK + attribute grammar of theprevious section. Intuitively, the methodfirst assigns -L to each circularly de-fined attribute instance in the subtree

for the constant definition part

(ConstF’a@ of the source program; seeFigure 9. In the first iteration, the valueattribute instances of all the constants

(ComtDef) with a literal value can beevaluated because they are not actuallycircularly defined, Also, the environmentattribute instances envi and envs can beupdated to include the literal constants.In the next iteration, those constants canbe processed and inserted in the symboltable that are symbolically defined interms of the constants evaluated in theprevious iteration. This gradual evalua-tion scheme is repeated until no moreconstants become defined during someiteration.

For instance, let us apply the iterativestrategy for evaluating the constant defi-nition part of the DESK + program (3.1):

. ..wHEREx=y. y=z, z=2

Initially, all the defined constants havebottom as their value, resulting in thefollowing symbol table:

[k, L), (Y, l),(z, 1)1

In the first iteration, the actual valueof z is computed since it is literal:

[(x, l), (y>l), (z,2)l

In the second iteration, the constant ydefined in terms of z can be evaluated:

[(X, L), (Y,2), (Z,2)I

In the third iteration, the constant xcan be evaluated, resulting in the follow-ing final symbol table as the fixed point:

[(X,2), (y,2), (Z,2)I

Notice that there are two reasons whya constant c might still have bottom asits value in the final symbol table:


242 “ Jukkcr Paakki

(1) c is defined in terms of an undefinedconstant d: e.g.,

PRINT. .. WHERE c = d; or

(2) c is recursively defined: e.g.,

PRINT . .. WHERE c=d. d=c

In both cases the DESK + program isillegal. To be able to detect such situa-tions, the final value of the symbol tablecould be checked. Another, more liberalsolution is to forbid only the use of suchinvalid constants in the expression partof the program. Then a symbolic operandof an expression could be specified, e.g.,with the following production which, forbrevity, is in this case not in normalform:

Factor - ConstName{Factor, value = getvalue

(ConstName.name, Factor, envi),Factor ok = Isln

(ConstName.name, Factor envl)and Factor. value # 1 }

To be safe with the iterative evaluationsketched above, the domain of both theconstant values and the symbol tablemust be a complete partial order, and theinvolved semantic functions must be con-tinuous with a stationary upper bound.Such a rigorous interpretation of do-mains and semantic functions within acircular attribute grammar similar to ourDESK + grammar is given in Farrow

[19861, where also the fixed-point methodis precisely described in connection of theLinguist system [Declarative Systems1992]. Other strategies of effectivelyevaluating circular attribute grammarsare presented in, e.g., Jones and Simon[ 1986] and Jones [ 1990]. All these ap-proaches define general attribute gram-mar classes that are circular in theircharacteristic graphs but still well de-fined with respect to a fixed-point compu-tation.

3.3 Implicit Paradigms

In the previous sections we havediscussed different ways to raise the ex-pressiveness of attribute grammars byapplying logic or functional programming

in the attribute evaluation process. Thesemantic power of these attribute gram-mar paradigms is provided by the se-mantic functions that are written in alogic or a functional language. Hence, theevaluation paradigm is explicitly in-cluded in the attribute grammar itself.

In addition to such explicit mecha-nisms, some specialized techniques havebeen developed where an unconventionalattribute evaluation behavior is auto-matically generated from an attributegrammar, thus being implicit in nature.Ideally, exploiting such an evaluationparadigm should in no way affect theform of the attribute grammar. In prac-tice, however, it may be necessary toinclude some instructing commands orsemantic rules in the specification, typi-cally for optimizing the performance ofthe generated language processor. In thissection we give a brief account of twopopular implicit and specialized attributeevaluation techniques, parallel evalua-

tion (Section 3.3. 1) and incremental eval-

uation (Section 3.3.2).

3.3.1 Parallel Attribute Evaluation

A programming language whose opera-tions have a total order at execution timecan be referred to as a sequential one. Incontrast, concurrent programming is aparadigm where operations can be exe-cuted in parallel, that is, simultaneouslyunder a special multiprocessor hardware.

With the advent of commercial parallelarchitectures, concurrent programminghas in recent years gained considerabletheoretical and practical importance. Aprocess is the basic self-standing elementwithin a concurrent program, having lo-cal data which is manipulated by localcode. The exchange of data between pro-cesses makes them communicate, eitherusing explicitly sent data structures(messages), or through a shared memorythat can be accessed by several pro-cesses. Synchronization is the mecha-nism making the execution of the entireprogram proceed in a controlled fashionby imposing that a set of processes mustbe in a certain inner state before they



can continue their execution (e.g., be-cause one process needs data fromanother process). If processes can beexecuted independent of each other, theyare called asynchronous.

Although concurrent concepts are mostnatural ones for modeling some inher-ently parallel systems (such as operatingsystems), the primary merit of concur-rent programming is the exploitation ofparallel hardware for achieving maximalperformance. Thus the benefits of the ap-proach should be the largest when ap-plied on frequently used software, suchas compilers. Parallel compilation tech-niques are, however, still a rather unex-plored area, and experimental resultshave not been available until recently

(e.g., Katseff [19881, Gross et al. [19891,and Seshadri and Wortman [1991]). Typ-ical results from these parallelizing ex-periments indicate a compilation speedupof 3 using 5 processors and a speedup of5 using 9 processors.

Because concurrent and parallel com-pilation techniques are still immature,the design of methods and tools for speci-fying and automatically implementingsuch compilers is a relatively young re-search topic. It is surprising, though, thatthe first historical implementation of at-tribute grammars, FOLDS [Fang 1972],was already based on considering pro-ductions as processes:

Production = Process

In FOLDS, processes could also be de-fined attributewise, giving rise to the fol-lowing correspondence:

~

In the current approaches, the most pop-ular principle can be expressed with thecorrespondence

~

emphasizing that the parallelization isespecially directed to the dynamic in-

stance (attributed tree) of an attributegrammar. Two subtrees should be evalu-ated in parallel only if the semantic cou-pling between them is loose enough. Theideal case is that the subtrees are totallyindependent such that no attribute in-stance in one subtree depends on an at-tribute instance in the other subtree.While total independence is rare in prac-tical attribute grammars, an analysis ofsome frequently occurring attributionpatterns has shown that often the sym-bols within one production can be ar-ranged into disjoint sets such that thereis only one attribute dependency betweenthe sets [Klein and Koskimies 1989]. Ifeach set is realized as a process, thecommunication between the processes isquite inexpensive. Within each process,the nodes for the symbols of the corre-sponding set are evaluated sequentiallyin the order determined by the attributedependencies in the grammar.

While the tendency in the parallel at-tribute evaluation paradigm lies on thedynamic side, it is desirable to partitionthe attributed tree into processes by astatic analysis of the attribute grammar.General static multipass strategies forparallel evaluation are proposed in, e.g.,Kuiper and Zwierstra [1990], Zaring[1990], and Klein [1992]. One-pass paral-lel evaluation is discussed in, e.g., Kleinand Koskimies [1989; 1990]. A less auto-mated method, based on explicit user-given parallelization instructions in theattribute grammar, is presented inBoehm and Zwaenepoel [1987]. An exten-sive survey of parallel attribute evalua-tion methods is given in Jourdan [1991].

One attribute evaluation approachreaching for a maximal amount of paral-lelism would be to consider an attributegrammar as a data-flow program, as sug-gested in Farrow [1983]. Then attributeinstances would map into data-flow nodesthat would fire when all their input in-stance nodes have been evaluated. Rathersurprisingly, though, no practical experi-ments on this natural and appealing ideahave been reported.

We could apply a parallel evaluationstrategy on the DESK(+) attribute


244 e Jukka PaakkL

grammar for raising the speed of thegenerated DESK(+) compiler. Withoutgoing into details, the most effective waywould be to parallelize the code genera-tion phase of the compiler by allocatingexpression subtrees into processors, thusemploying the “Subtree = Process” prin-ciple. A static analysis of the attributegrammar (see Example 1.3.4) shows thatthe different operands of a DESK(+) ex-pression, represented by the nonterminalFactor, are loosely coupled in the sensethat their attribute instances do not de-pend on each other. Thus, the Factor sub-trees could be effectively evaluated inparallel, as soon as the symbol table hasbeen constructed and propagated tothe Factor.envi attribute instances. Theanalysis also shows that the constantdefinitions (instances of ConstDef) aresimilarly independent and could be eval-uated in parallel as well,

3.3.2 Incremental Attribute Evaluation

The development of high-performanceworkstations has given rise to advancedinteractive applications. The fundamen-tal principle behind such systems is irz-cremental computation, where existinginformation is constantly updated inresponse to the user’s actions. To be ef-fective, the update should exclude theexecution of those parts of the applica-tion that are not affected by the particu-lar interaction.

The key element in interactive pro-gram development is a language-basedprogramming environment that providesintegrated tools for the whole softwareengineering process. In such a frame-work the tools must be based on incre-mental techniques so as to reduce the

workload caused by program modifica-tions. Usually the main component of anintegrated programming environmentis a syntax-directed editor that main-tains an internal representation of theprogram and keeps track of the modi-fications induced on it by the program-editing process. The other componentsof the environment (such as an inter-preter, a compiler, and a debugger)

effectively share the same internalrepresentation. Smalltalk [Goldberg andRobson 1983] and Mjdlner\Orm [Knud-sen et al. 1993] are two representativeexamples of an integrated programmingenvironment.

An attractive characteristic of inte-grated language-based programmingenvironments is that they can be auto-matically generated from a high-leveldescription. The generation of syntax-di-rected editors has been an especially pop-ular topic of research, usually based onattribute grammars as the specificationformalism. The Synthesizer Generator isthe most well-known editor generatorbased on attribute grammars [Reps andTeitelbaum 1989]. GANDALF is a moregeneral system that supports the genera-tion of complete environments, also withattribute grammars as one of the specifi-cation for~alisms [Notkin 1985]. ‘

The central m-oblem in incrementallanguage proce~sing based on attributegrammars is the efficient evaluation ofattributes. For source programs of realis-tic size, an attributed tree mav be suitelarge for an internal representation. Also,the attribute dependency graph thatmodels the information needed for imple-menting an editing update of the sourceprogram covers typically the whole tree.For these reasons, it is not reasonable toreevaluate the whole attributed treecompletely in reaction to a small syntac-tic modification.

The need for efficient and immediateupdates has resulted in the developmentof lncremen tal attribute evaluation tech-

niqz~es. Intuitively, these methods try tominimize the semantic cost of a syntacticprogram modification by reevaluatingonly those attribute instances whose

values are affected by the modification.

Usually the methods rely on the charac-teristic dependency graphs for the un-derlying attribute grammar to computeincrementally the affected region of theattributed tree. Recall from Section 1.3that the characteristic graphs approxi-mate the functional dependencies stati-

cally between the attribute instances inany”derivation tree for the grammar, thus



providing for an effective basis to deduceimmediately which attribute instancesdepend (indirectly) on the modified nodesin the tree and shall therefore be reeval-uated.

Example systems with an optimizedincremental attribute evaluation supportinclude, e.g., OPTRAN [Lipps et al. 1988],the Synthesizer Generator [Reps andTeitelbaum 1989], Pan [Ballance andGraham 1991], and Mjdlner/Orm [Hedin1992]. Combining the specialized tech-niques of parallel and incremental evalu-ation is discussed in Alblas [1990].

The attribute grammar for DESK(+)could be used as such for generating asyntax-directed DESK(+) editor with animplicit incremental attribute evaluatorembeded. In order to make the editorpleasant to use, the attribute grammarshould, however, be extended with rulespertaining solely to the interactive edit-ing process without touching the actualsemantics of DESK(+) and its compiler.Such customizing instructions should de-fine how the program is displayed on thescreen, which error messages the editorshall give, and what kind of source-leveltransformations are allowed during edit-ing. For instance, the grammar couldenforce restrictions that the main ex-pression and the constant definitions ofthe edited DESK(+) program are eachdisplayed on their own line, and that theeditor shall, in response to a request,replace the main expression with its lit-eral value.

Regarding the compilation process, anincremental attribute evaluator forDESK(+) would reevaluate only thoseattribute instances that are affected byan editing action. For instance, changingthe main expression of the program wouldnot induce any reevaluation on the con-stant definition part because there is noflow of attribute values from the expres-sion subtree into the constant definitionsubtree in the characteristic graphs (seeFigure 1) nor in the underlying at-tributed tree (see Figure 4). The targetcode, however, depends on the contentsof the main expression, and that is whycode attribute instances would have to be

reevaluated after such a modification, re-sulting in an updated sequence of gener-ated assembly instructions.

4. CONCLUSIONS

In this survey we have presented alter-native methods of expressing attributegrammars by integrating into them vari-ous concepts of well-founded program-ming paradigms, Starting from thestandard notion of attribute grammars,different styles of expressing the form-alism have been created. The analogybetween attribute grammar styles andprogramming paradigms is reflected inthis survey by the characterization of theformalisms as structured, modular, ob-ject-oriented, logic, and functional at-

tribute grammars. To complement theseself-standing paradigms, we have alsopresented two implicit paradigms whosenature is manifested by a special paral-lel or incremental attribute evaluationstrategy which is automatically gener-ated, rather than being explicit in theattribute grammar.

The motivation to develop these at-tribute grammar paradigms has been thesame as the trend in the evolution ofprogramming languages: to provide morehigh-level, flexible, expressive, or effi-cient concepts for specifying and imple-menting a particular application. Thefollowing list summarizes the aspectsthat are often emphasized when analyz-ing the merits of programming languages(e.g., Wasserman [1980]). The same crite-ria can also be used for evaluating andrelating the different attribute grammarparadigms against each other:

m

0

●

●

0

e

●

.

●

simplicity

readability

expressiveness

regularity (orthogonality)

security

reuse

application supportformal definition

efficiency

Structured, modular, and object-orientedattribute grammars most notably sup-

ACM Computmg Surveys, VOI 27, No 2, June 1995

246 * Jukka Paakki

port the organizational aspect of at-tribute grammars. We can illustrate thedifferences between these approaches bysketching in Figure 10 the structure ofattribute grammars obtained when ap-plying these paradigms. The views corre-spond to the following standard attributegrammar with the nonterminal symbolsS (the start symbol), X, Y, and Z, theterminal symbols y and Z, and the at-tributes a and b:

S + XY {S.a = X.a}X-Z {X,a=Zb, Xb=Z.a}Y+y {}

z-z {Z.a = O, Z.b = 1}

Treating productions as blocks (Figure10a) results in an attribute grammarwhose structure resembles the flat blockstructure of the programming languageC, for example. Having nonterminals asblocks or procedures (Figure 10b) resultsin a more general form that correspondsto the nested block structure of Pascal,for example. Modeling either nontermi-nals, attributes, or productions as mod-ules or classes (Figures 10c and d) has itscounterpart, e.g., in Ada packages or Eif-fel classes. (The interface part of a mod-ule/class is expressed using “windows”on the left border of the module/class.An arrow from a module/class A to a

module/class B indicates that the publiccomponents of B are used by A.)

The merits of conventional structuringmethods have been thoroughly analyzedin the literature of programming lan-guages. A special account of blocks, pro-cedures, and modules is given in Hanson[1981]. The general discussion is relevantin this application area as well. Blocksand procedures are valuable in structur-ing programs (here: attribute grammars)of modest size, whereas modules andclasses are superior when building largersystems with a necessity for maintainingand reusing components (here: attri-bute grammar fragments). The two formsof modular attribute grammars differin that having attributes as modules(Figure 10d) typically produces lessmodules, whereas the modules for non-terminals (Figure 10c) tend to be smaller

and thus easier to maintain. The small-est number of modules would result whencomposing them as different aspects ofan attribute zrammar (not shown in thefigure). Obje~t-oriented attribute gram-mars provide additionally the inheri-tance concept which makes the paradigmsu~erior to both structured and modularat&ibute grammars in abstraction capa-bilities.

Functional and logic attribute gram-mars provide for powerful semantic facil-ities. On the functional side, we havediscussed especially the use of lazy anditerative evaluation, and on the logic sidethe use of predicates and logicfi vari-ables. These mechanisms have their mer-its in evaluating attribute grammars thatare problematic under strict evaluationmethods. Two concrete examples pre-sented in this survey are statically circu-lar attribute grammars that dynamicallyturn out to be noncircular when evalu-ated in a lazy or fixed-point-findingfashion, and strictly counter-one-passgrammars [Giegerich and Wilhelm 1978]that can be evaluated during parsingwhen employing logical variables as at-tribute instances.

The special attribute evaluation toolsof functional and logic attribute gram-mars can be demonstrated by showing(Figure 11) what kind of attribute depen-dencies they accept. In the attributedsubtree, X, Y, and Z denote nonterminalnodes, and mherlted attribute instancesare attached to the left and synthesizedattribute instances to the ripht of thenodes. A strict dependency chain (i.e., achain of attribute instances that areevaluated using strict semantic func-tions) is represented by the attributes at,a lazy functional dependency chain bythe attributes bi, and a logical one-passdependency chain by the attributes ci.

Let us assume that the underlying im-plementation applies a one-pass left-to-right attribute evaluation strategy. Thegrammar fragment is in each case well

defined with respect to the attribute in-

stances ai since they can always be eval-uated using the standard L-attributedstrategy. The functional and logical

ACM Computmg Surveys, Vol. 27, No 2. June 1995

Attribute Grammar Paradigms . 247

S (a)X (a,b)Y()Z (a,b)

w

(a) Production = Block

X (a,b) -

a)n

Z (a,b)

Z->z

(Za=O, Zb=l)

X->z{Xa=Zb, Xb=Za)

m

->XYSa=Xa}

(b) Nontermmal= Block

Nontermmal= Procedure

~

Sa

Xa

Za

s

Z=z!aS->x’i

[S.a= X.a]

x

a

Y

X->za [Xa. Zb,

Xb. Za]

L

o‘i.>y[1

!

a

$0

Z->z[Za=O,

b Zb=l]

(c) Nontermmal = Module

Nontermmal = Class

ProductIon = Class

a

I I

(d) Attribute= Module

Figure lO. Organizational attribute grammars.

ACM Computmg Surveys, Vol 27, No.2, June 1995


Figure Il. Strict, lazy, andloglcal dependencies

chains are less restricting in their at-tribute dependencies, but on the otherhand they induce some conditions on thesemantic functions. The grammar frag-ment is well defined with respect to theattribute instances bi only if the valueof b 3 is not needed in computing themeaning of the program (or if the staticdependency chain between bl and b2disappears dynamically when executingtheir semantic rules’). Finally, the frag-ment is well defined with respect to theinstances ci if the values of c 2, c3, c4,and C5 (and all the instances dependingon them) are not used as a strict argu-ment of a semantic function, since thenthey can be evaluated using the logicalone-pass strategy. A strict one-passmethod can under no circumstances eval-uate the bi and ci attribute instances.

In contrast to the paradigms discussedabove, the facilities of concurrent andincremental programming do not primar-ily raise the conceptual level of attributegrammars. Instead, they focus on theperformance of the generated languageprocessors. Therefore, as a notation theseimplicit paradigms do not differ from or-dinary attribute grammars, except thatthey in practice may contain some ex-plicit user-specified instructions to thesystem. The significance of concurrencyand incrementality should by no meansbe underestimated when selecting theapplied attribute grammar paradigmbecause efficiency is a major concernin frequently used software, such as com-pilers.

To summarize the discussion, the pre-sented approaches can be roughly di-vided into three categories. The maincontribution of the organizational

(structured, modular, object-oriented)paradigms is raising the software engi-

neering support of the metalanguages.Hence, these paradigms emphasize inparticular such aspects as readability,security, and reuse of specifications. Theevaluation (logic, functional) paradigmsprovide for powerful semantic facilities,

thus facilitating simplicity, expressive-ness, and regularity. Finally, the effi-

ciency of language processors is stressedby the implicit (parallel, incremental)paradigms. Note that since the paradigmsare based on the same model of standardattribute grammars, they all have a for-mal foundation, although the notion ofwell-definedness may slightly vary.

Choosing a particular attribute gram-mar paradigm for specifying or imple-menting a language depends on how thevarious aspects are emphasized. With asmall and simple language that presum-ably is not going to change, even thestandard pure style is sufficient. How-ever, a larger or more complex languagethat may exist in many generations in-volves a significant degree of softwareengineering. In that case a modular orobject-oriented paradigm is certainly abetter choice. The powerful logic andfunctional facilities are valuable whenone wants to focus on the specification ofthe language and on keeping the at-tribute grammar as declarative as possi-

ACM Computmg Surveys, Vol 27, No 2. June 1995


ble, without forcing any explicit attributeevaluation decisions. Finally, parallelismshould be considered when both perfor-mance of the language processor is theprimary goal and an appropriate archi-tecture is available.

The application area (when some otherthan mere language processing) may alsoaffect the decision. Interactive applica-tions require obviously the use of incre-mental evaluation techniques. Modelingof general sequential software with at-tribute grammars [Shinoda ad Katayama1988; Frost 1992] is an area where anorganizational paradigm with an under-lying one-pass implementation is mostfeasible. The object-oriented paradigm isthe most appropriate one when modelingcommunication protocols [Chapman1990], with interfaces, abstract data, andstate machines as a major concern. Dis-tributed applications [Kaiser and Kaplan1993] require a parallel evaluation strat-egy in order to be effective. As the lastexample, VLSI design [Jones and Simon1986] and data-flow analysis [Babich andJazayeri 1978] are two areas whose nat-ural description leads to a circular at-tribute grammar, thus making it feasibleto apply the functional fixed-point evalu-ation paradigm.

The choices by the designers of a lan-guage processor generator may also bestrongly influenced by the intended ap-plication area of the tool. For instance,both the Synthesizer Generator [Repsand Teitelbaum 1989] and Pan [Ballanceet al. 1990] generate incremental at-tribute evaluators. Since the main objec-tive of the Synthesizer Generator is justsyntax-directed editing, the metalan-g-uage of the system is a rather directadaptation of the standard form of at-tribute grammars. In contrast, the Pansystem has a broader scope of supportingthe development and maintenance ofgeneral (unstructured documents, not jutprograms. Such a versatile environmentis usable only if it maintains a sharabledatabase of documents. To map a specifi-cation more directly into the databasewith a set of integrated access opera-tions, the metalanguage of the system

has been based on the logic attributegrammar paradigm.

In this survey we have demonstratedhow attribute grammars have been inte-grated with different programmingparadigms. Most existing systems sup-port a single paradigm. The next naturalphase in the evolution of attribute gram-mars may well be the development oflanguage processor generators whosemetalanguage integrates several par-adigms. Using the taxonomy of thissurvey, such a multiparadigm systemshould (1) have advanced software engi-neering capabilities, (2) provide for pow-erful semantic abstractions, and (3)generate efficient language processors.One recent example of such a versatilesystem is FNC-2 whose metalanguage isbased on blocks and modules (category1), pattern matching and polymorphism

(category 2), and an underlying paralleland incremental attribute evaluationstrategy (category 3) [Jourdan et al. 1990;Jourdan and Parigot 1991].

While the original and most widelyrecognized application area of attributegrammars is compiler generation, only afew commercial compilers have actuallybeen developed using attribute gram-mars as a design or implementation tool.Indeed, it has been argued that attributegrammars fall short in the production ofhigh-speed compilers for conventionalgeneral-purpose programming languages[Waite 1990]. Two common explanationsfor such a conjecture are that attributegrammars are just a model of compila-tion and thus too primitive for a realengineering discipline, and that they donot directly support the generation andoptimization of low-level machine code.On the other hand, the success of YACCshows the practical usability of attributegrammars at least in simple front-endapplications [Johnson 1975].

In this survey we have shown that at-tribute grammars have developed into anadvanced language processing methodol-ogy by a paradigmatic evolution, and thatthe software engineering requirementsare taken into account in modern meta-languages and systems. The second main

ACM Computmg Surveys, Vol 27, NCI 2, June 1995

250 * Jukka Paakki

problem, lack of proper support for codegeneration and optimization, originatesin the model itself and is harder to at-tack.

From this viewpoint, we can argue thatattribute grammar paradigms should ac-tually not be applied in the developmentof conventional optimizing compilers. In-stead, a much more suitable area is thedesign and implementation of speclal-

purpose application languages, typical

examples being database query lan-

guages (e.g., SQL), robot control lan-guages, hardware design languages (e.g.,VHDL), protocol specification languages

(e.g., ASN.1, SDL), and narrow “littlelanguages” [Bentley 1986]. Such a lan-guage is usually developed with empha-sis on high-level application abstractionsrather than on optimal performance.Other typical aspects are rapid imple-mentation, exploratory and flexibledesign, modifiability, reuse of existinglanguage concepts, and mapping into ageneral-purpose programming language(“source-to-source translation”). Thesecharacteristics conform to the methodol-ogy of language processor generatorswhich indeed have widely and success-fully been used in the implementation ofa variety of application languages.

Due to the rapid growth of softwareintensive applications, it is most likelythat the main trend of language designwill more and more focus on applicationlanguages. To be productive, the develop-ment of these languages must be basedon high-level automated tools with sup-port for both design and implementation.A realistic methodological foundation forapplication-oriented langaage processingin the future are attribute grammarparadigms, such as promoted in this sur-vey.

ACKNOWLEDGMENTS

This survey has been inspired by my various joint

research projects with Kal Koskimles. The com

ments from Gorel Hedm, Remo Kurkl-Suomo, Scppo

SIppu, and Esko Ukkonen have been useful when

producing earlier versions of the survey The sug-

gestions of the anonymous referees have been very

helpful for focusing and Improvmg the presenta-

tion.

REFERENCES

ABRAMSON, H 1984 Defimte clause translationgrammars In Proceedmgb of the 1984 IEEE

Symposium on Logzc Programming (Atlantlc

City, NJ) IEEE, New York, 233-240

ACM COMPUTING SURVEIS 21, 3, 1989. Special Issue

on Programmmg Language Paradigms.

&Io, A. V,, SETHI, R., AFJD ULLMAN, J. D. 1986

Compders-Prmczples, Techruques, and Tools.Addison-Wesley, Reading, Mass,

AKSIT, M,, MOSTERT, R,, AND HAVERKORT, B. 1990.

Compder generation based on grammar mherl-tance. Rep. 90-07, Dept. of Computer Science,

Umv. of Twente.

ALBLM, H, 1991. Attribute evaluation methods, InAttribute Grammars, Appllcatlons, and Sys-

tems, Lecture Notes m Computer Science, vol

545, Sprmger-Verlag, New York, 48-113.

ALBLAS, H. 1990. Concurrent incremental attributeevaluation, In Proceedings of the InternationalConference on Attrzbute Grammars and thezrApplications, Lecture Notes in Computer Sci-ence, vol 461 Sprmger-Verlag, New York,

343-358.

ALBLAS, H ~NII MELICHAR, B. (EDS ) 1991, Attrzbute

Grammar~, Appllcatlons, and ,S’vstems. Lec-ture Notes in Computer Science, vol 545.

Springer-Verlag, New York.

ALEXIN, Z , GYIM6THY, T , HoRvLTH, T , AND F.f.BI+Icz,

K 1990. Attribute grammar specification for anatural language understanding interface In

Proceedings of the International Conference onAttribute Grammars and them Appllcatlons,Lecture Notes m Computer Science, VOI 461.Sprmger-Verlag, New York, 313-326

APPEL, A. W, AND MAC’QUEEN, D. B. 1991. Standard

ML of New Jersey In Proceedings of the 3rd

International S.vmpo~lum on ProgrammingLanguage Implementation and Logic Program-

mmg (PLILP ’91) Lecture Notes ]n ComputerScience, vol. 528, J. Maluszynskl and MWmsmg, Eds, Sprmger-Verlag, New York, 1-13

ARBAB, B, 1986. Compdmg cmcular attribute gram-mars into Prolog, IBM .J. Res. Devel. ,30, 3,294-309.

ACTWSTEIJN, L. 1990. The Elegant Compder Gener-

ator System In Proceedings of the Interna-tzona[ Conference on Attribute Grammar? andthezr Applzcatlons, Lecture Notes m ComputerScience, vol 461 Springer-Verlag, New York,238-254

BABIrH, W. A AND JAZ.AYERI, M 1978 The method

of attributes for data flow analysls, Part 1,Exhaustive analysm: Part II: Demand analyslsActs Informatlca 10, 245-272

BALLANCE, R. A, AND GRAHAM, S, L, 1991, Incremen-

tal consistency maintenance for mteractlve ap-plications In Proceedings of the 8th Interns-ttonal Conference on Logzc Programmzrzg, K,Furukawa, Ed The MIT Press, Cambridge,

Mass , 895-909

ACM Computmg Surveys, Vol 27, No ?,. June 1995

Attribute Grammar Paradigms e 251

BALLANCE, R. A., GRAHAM, S. L., AND VAN DE VAT+TER, M. L. 1990. The Pan language-based edit-

ing system for integrated development environ-ments. In Proceechngs of the 4th ACM SIG-

SOFT Symposmm on Software Development

Emxronments (SIGSOFT ‘90). ACM SIG-

SOFT Softw. Eng. Notes 15, 6, 77-93.

BENTLEY, J. 1986. Little languages. Commun. ACM29, 8, 711-722.

BOCHMANN, G. V. 1976. Semantic evaluation fromleft to right. Commun. ACM 19, 2, 55-62,

BOCHMANN, G. V. AND WARD, P. 1978. Compilerwriting system for attribute grammars. Com-put. J, 21, 2, 144-148.

BOEHM, H.-J. AND ZWAENEPOEL, W. 1987. Parallel

attribute grammar evaluation. In Proceedingsof the 7th International IEEE Conference onDistributed Computing Systems (Berlin). IEEE,

New York, 347-354.

BRYANT, B. R. AND PAN, A. 1989. Rapid prototyping

of programming language semantics using Pro-log. In proceedings of IEEE COMPSAC ’89

(Orlando, F1.). IEEE, New York, 439-446.

CHAPMAN, N. P. 1990. Defining, analysing and im-plementing communication protocols using at-tribute grammars. Formal Aspects Comput. 2,359-392.

CHIRICA, L. M. AND MARTIN, D. F. 1979. An order-

algebraic definition of Knuthian semantics.Math. Syst. Theory 13, 1,1-27.

CHOMSKY, N. 1959. On certain formal properties of

grammars. Inf. Contr. 2, 137-167.

COLMERAtTER, A. 1978. Metamorphosis grammars.

In Natural Language Communication withComputers, L. Bole, Ed. Springer-Verlag, NewYork, 133-189.

COURCELLE, B. AND FRANCHI-ZANNETTACCI, P. 1982.Attribute grammars and recursive program

schemes. Tr’zeor. Comput. SCL. 17, 2, 163–191(Part I) and 17, 3, 235-257 (Part II).

COUSINEAU, G. AND HUET, G. 1990. The CAMLPrimer. Tech. Rep. 122, INRIA.

CRIMI, C., GUERCIO, A., PACINI, G., TORTORA, G., ANDTUCCI, M. 1990. Automating visual language

generation. IEEE Trans. Softw. Eng. 16, 10,

1122-1135.

DAHL, V. AND ABRAMSON, H. 1989. Logic Grammars.Springer-Verlag, New York.

DAHL, V. AND ASRAMSON, H. 1984. Gapping gram-mars. In Proceedings of the 2nd Internat~onalLogzc Programming Conference (Uppsala).

DECLARATIVE SYSTEMS 1992. User Manual for theLmguwt Translator-Wr~tmg System. Declara-tive Systems, Inc., Palo Alto, Calif.

DELEST, M. P. AND FEDOU, J. M. 1992. Attributegrammars are useful for combinatorics Z’heorComput. Sci 98, 1, 65-76.

DEPARTMENT OF DEFENSE. 1983. The ProgrammingLanguage Ada, Reference Manual. ANSI/MIL-STD-1815A-1983. Springer-Verlag, New York.

DERANSART, P. AND JOURDAN, M. (ED.). 1990. Pro-ceedings of the ZnternatLonal Conference on At-

tr~bute Grammars and thew Appltcat~ons. Lec-

ture Notes in Computer Science, vol. 461.

Springer-Verlag, New York.

DERANSART, P. AND MALUSZYNSKI, J. 1993. A Gram-

matical View of LogLc Programmmg. The MIT

Press, Cambridge, Mass.

DERANSART, P. AND MALUSZYNSKI, J. 1985. Relatinglogic programs and attribute grammars.

J. Logic Program. 2, 2, 119-155.

DERANSART, P., JOURDAN, M., AND LORIIO, B. 1988.Attribute Grammars—Definitions, Systems andBibliography. Lecture Notes in Computer Sci-ence, vol. 323, Springer-Verlag, New York.

DING, S. AND KATAYAMA, T. 1993. Attributed statemachines for behavior specification of reactive

systems, In proceedings of the 5th Interna-tional Conference on Software Engineering andKnowledge Engmeermg (SEKE’93) (San Fran-

cisco). Knowledge Systems Institute, 695–702.

DUECK, G. D. P. AND CORMACK, G. V. 1990. Modular

attribute grammars. Comput. J. 33, 2, 164– 172.

EXPERT SOFTWARE SYSTEMS. 1984. MIRA, User’sManual. Expert Software Systems.

FANG, I. 1972. FOLDS—A declarative semantic for-mal language definition system. Rep. STAN

CS-72-239, Computer Science Department,Stanford University, Stanford, Calif.

FARROW, R. 1986. Automatic generation of fixed-

point-finding evaluators for circular, but well-defined attribute grammars. In Proceedings of

the ACM SIGPLAN ’86 Sympowum on Com-

piler Construction. ACM SIGPLAN Not. 21, 7,

85-98.

FARROW, R. 1983. Attribute grammars and data-flowlanguages In Proceedings of the SIGPLAN’83Symposium on Programming Language Issuesin Software Systems. ACM SIGPLAN Not. 18,

6, 28-40.

FARROW, R, 1982. LINGUIST-86, yet another trans-lator writing system based on attribute gram-mars. In Proceedings of the ACM SIGPLAN’82 Symposmm on Cornpder Construction.

ACM SIGPLAN Not. 17, 6, 160-171.

FARROW, R., MARLOWE, T. J., AND YELLIN, D. M.

1992. Composable attribute grammars: Sup-port for modularity in translator design andimplementation, In Conference Record of the19th Annual ACM SIGPLAN-SIGACT Sympo-szum on Pn nciples of Programming Languages(Albuquerque, New Mex.). ACM, New York,223-234.

FISCHER, C. N. AND LEBLANC, R. J. 1988. Crafttng aCompder. Benjamin-Cummings, Menlo Park.Calif.

FROST, R. A. 1993. Guarded attribute grammars.

Softw. Prac. Exp. 23, 10, 1139-1156.

FROST, R. A. 1992. Constructing programs as exe-cutable attribute grammars. Comput. J 35, 4,376-389.

GANZINGER, H. 1980. Transforming denotational se-mantics into practical attribute grammars. Inproceedings of the Workshop on Semant~cs -

ACM Computmg Surveys. Vol 27, No 2 June 1995

252 e Jukka Paakki

Directed Compiler Generation Lecture Notesin Computer Science, vol. 94, N. D, Jones, Ed.

Sprmger-Verlag, New York, 1-69

GANZINGER, H AND GIEGERICH, R. 1984 Attributecoupled grammars. In F’roceechngs of the ACJf

SIGPLAN ’84 Symposium on Compiler Czm -struct~on. ACM SIGPLAN Not. 19, 6, L57–170.

GANZINGER, H., GIEGERICH, R., MONCRE, U., ANDWILH~LM, R. 1982. A truly generatwe seman-

tics-dmected compiler generator. In Proceed-ings of the ACM SIGPLAN ’82 Symposl um on

Compder Construction. ACM SIGPLAN Not.

17, 6, 172-184.

GARRISON, P. 1987 Modeling and implementation ofvislbdlty m programming languages Rep

UCB/CSC 88/400, Computer Science Divi-sion, Univ. of Cahforma, Berkeley, Cahf.

GUWERICH, R. AND WILHELM, R. 1978. Counter-one-pass features in one-pass compdatlon: A for-malisation using attribute grammars. Inf. Pro-cess. Lett 7, 6, 279–284.

GOLDBERG, A. AND ROBSON, D 1983. Smcdltalk-80.The Language and Its Implementation Addi-son-Wesley, Reading, Mass.

GROSCH, J. 1990. Object-oriented attribute gram-

mars. In Proceedings of the 5th InternationalSymposium on Computer and Informat~on Sci-ences (ISCZS V), A. E. Harmancl and E.

Gelenke, Eds. 807-816.

GROSS, T., ZOBEL. A., AND ZOI.G, M 1989. Parallelcompdatlon for a parallel machme In Proceed-

ings of the ACM SIGPLAN ’89 Conference onProgrammmg Language Design and Implemen-tation. ACM SIGPLANNot. 24, 7, 91–100

GROSSMANN, R., HUTSCHENREITER, J., LANWE, J.,LO TZSCH, J., AND MAGER, K. 1984.

DEPOT2a—Metasystem fur dle Analyse undVerarbeitung verbundener F’achsprachen. An-

wenderhandbuch, Sektion Mathematlk, Tech-nische Universitat Dresden.

HANSON, D R, 1981 Is block structure necessary?Soft. Prac. Exp. 11, 8, 853-866.

HEDIN, G. 1989. An object-oriented notation for at-tribute grammars In Proceedings of the 3rd

European Conference on ob]eet-(lv,ented Pro-gramming (ECOOP ‘89), S. Cook, Ed. BntlshInformatics Society Ltd., Nottingham, 329-345.

HEDIN, G. 1994. An overview of door attributegrammars In Pmceedmgs of the Intern atwnalConference on Compder Constructmn (CC’94)Lecture Notes m Computer Science, vol 786,P. Frltzson, Ed. Sprmger-Verlag, New York.

HEDIN, G 1992. Incremental semantic analysis.Doctoral dissertation, Lund University.

HEERING, J., KLINT, P., AND REKERS, J. 1990 Incre-mental generation of parsers. IEEE TransSoftw Eng. SE-16, 12, 1344-1351.

HORWITZ, S. AND REPS, T 1992 The use of program

dependence graphs in software engineering. InProceedings of the 14th International Confer-ence on Software Englneer~ng IEEE ComputerSociety Press, Los Alamltos, Cahf., 392-411.

HLTDSON, S, E, AND KZNG, R, 1987 Implementmg a

user interface as a system of attributes InProceedings of the ACM SIGSOFT/SIGPLANSoftware Engzneerzng Symposzum on PracticalSoftuare Development Environments. ACM

SIGPLAN Not. 22, 1,143-149.

IRONS, E, T 1961 A syntax directed compiler for

Algol 60 C’ornmun ACM 4, 1,51-55

JAZAYERI, M., OGDEN, W F., AND ROUND\, W C.

1975. The intrinsically exponential complexity

of the cmcularlty problem for attribute gram-mars. Commun. ACM 18, 12, 679–706

JOHNSON, S. C. 1975. YACC, yet another compder

compder. Rep. CS-TR-32, Bell Laboratories,Murray Hill, N.J.

JOHNSSON, T. 1987. Attribute grammars as a func-tional programming paradigm In Proceed/rigsof the S-ymposl urn on Fu nctlonal Progra mm zng

Languages and Computer Architecture Lecture

Notes m Computer Science, vol 274, G Kahn,Ed. Springer-Verlag, New York, 154-173

JONES, L. G. 1990. Efficient evaluation of cmcular

attribute grammars. ACM Trans. Program.Lang. Syst. 12, 3, 429-462,

JONES, R. 1986 Flex—An experience of Mmanda.

UKC Computing Laboratory Rep. 38, Umv. of

Kent at Canterbury

JONES, L G AND SIMON. J 1986. Hwrarchlcal VLSIdesign systems based on attribute grammarsIn Conference Record of the 13th ACM Sympo-

szurn on Prmclples of Program m zng LanguagesACM, New York, 58-69

JOURDAN, M 1991, A survey of parallel attribute

evaluation methods. In Attribute Grammars,ApplzcatLons, and Systems. Lecture Notes m

Computer Science, vol. 545. Springer-Verlag,New York, 234-255.

JOURDAN, M. 1984 Strongly non-circular attributegrammars and them recursive evaluation. In

proceedings of the ACM SIGPLAN’84 Sympo-

szum on Compiler Construction ACM

SIGPLAN Not. 19, 6, 81–93.

JOLrREMV, M. AND PARIGOT, D. 1991, Internals andexternals of the FNC-2 attribute grammar sys-

tem In Attrzbute Grammars, Apphcatzons andSystems Lecture Notes m Computer Science,vol 545. Springer-Verlag, New York, 485–506.

JOURDAN, M , LE BELLEC, C , AND PARI~OT, D 1990The OLGA attrlb,~te grammar description lan-guage. Design, implementation and evaluationIn Proceedings of the International Conferenceon Attrzbute Grammars and thezr Appllcatton.<

Lecture Notes m Computer Science, vol. 461.Sprmger-Verlag, New York, 222-237.

KAISER, G AND KAPLAN, S M 1993 Parallel anddmtributed incremental attribute evaluationalgorkhms for multluser software developmentenvironments. ACM Tran.s Softw EngMethod. 2, 1,47-92,

KASTENS, U. 1991 Attribute grammars as a specifi-cation method In Attrzbute Grammars, Applz -catzons and Systems Lecture Notes m Com-



puter Science, vol. 545. Springer-Verlag, New

York, 16-47.

KASTENS, U. 1980. Ordered attributed grammars.

Acts Informatica 13, 229-256.

KASTENS, U. AND WAITE, W. M. 1991. An abstract

data type for name analysis. Acts Informattca28, 6, 539-558.

KASTENS, U., HUTT, B., AND ZIMMERMAN, E. 1987.

User Manual for the GAG-System, Version 7.GAG Documentation, GMD Forschungsstellean der Universitat Karlsruhe.

KASTENS, U., HUTT, B., AND ZIMMERMAN, E. 1982.

GAG: A Practical Compiler Generator. Lecture

Notes in Computer Science, vol. 141. Springer-

Verlag, New York.

KATSEFF, H. P. 1988. Data partitioning to imple-

ment a parallel assembler. In Proceedings ofthe ACM Conference on Parallel Programming:

Experiences wzth Applications, Languages andSystems ( PPEALS 1988). ACM SIGPLAN Not.23, 9, 66-76.

KKNNEDY, K. AND WARREN, S. 1976. Automatic gen-

eration of efficient evaluators for attribute

grammars. In Conference Record of the 3rdACM Symposium on Principles of Program-

mmg Languages. ACM, New York, 32–49,

KLEENE, S. C. 1952. Introduction to Metamathe-

matics. North-Holland, Amsterdam.

KLEIN, E. 1992. Parallel ordered attribute gram-

mars. In Proceedings of the IEEE Conference

on Computer Languages. IEEE, New York,106-116.

KLEIN, E. AND KOSKIMIES, K. 1989. The paralleliza-

tion of one-pass compilers. Arbeitspapiere derGMD 416, Gesellschaft fur Mathematik undDatenverabeitung mbH.

KLEIN, E. AND KOSKIMIES, K. 1990. Parallel one-pass

compilation. In Proceedings of the In terna-tLonal Conference on Attribute Grammars andthem Applzcatzons. Lecture Notes in Computer

Science, vol. 461. Springer-Verlag, New York,

76-90.

KNUTH, D. E. 1990. The genesis of attribute gram-

mars. In proceedings of the International Con-

ference on Attr~bute Grammars and them Appll -catLons. Lecture Notes in Computer Science,vol. 461. Springer-Verlag, New York, 1– 12.

KNUTH, D. E. 1971. Examples of formal semantics.

In Proceedings of the Symposium on Semant~csof Algor~thm~c Languages. Lecture Notes inMathematics, vol. 188, E. Engeler, Ed.Springer-Verlag, New York, 212-235.

KNUTH, D. E. 1968. Semantics of context-free lan-

guages. Math. Syst. Theory 2, 2, 127–145. (Cor-rigenda: Math. Syst. Theory 5, 1,1971, 95–96.)

KNUTH, D. E. 1965, On the translation of languages

from left to right. Znf. Contr. 8, 6, 607-639.

KOSKIMIES, K. 1991. Object-orientation in attribute

grammars. In Attrzbute Grammars, Applcca-tzons and Systems. Lecture Notes m Computer

Science, vol. 545. Springer-Verlag, New York,

297-329.

KOSKIMIES, K. 1990. Lazy recursive descent parsing

for modular language implementation. Softzu.Pratt. Exp. 20, 8, 749-772.

KOSKIMIES, K. 1989. Software engineering aspectsin language implementation. In Proceedings ofthe 2nd Workshop on Compder Compilers andHigh Speed Compilation. Lecture Notes inComputer Science, vol. 371, D. Hammer, Ed.Springer-Verlag, New York, 39-51.

KOSKIMIES, K. 1984. A specification language for

one-pass semantic analysis. In Proceedings ofthe ACM SIGPLAN’84 Symposium on Com-

piler Construction. ACM SIGPLAN Not, 19, 6,179-189.

KOSKIMIES, K. AND PAAKKI, J. 1991. High-level toolsfor language implementation. J. Syst. Softw,

15, 2, 115-131.

KOSKIMIES, K. AND PAAKKI, J. 1990. Automating

Language Implementation-A Pragmatic Ap-proach, Ellis Horwood, Chichester, England.

KOSKIMIES, K., NURMI, O., PAAKKI, J., AND SIPPU, S.1988. The design of a language processor gen-

erator. Softw. Pratt. E.rper. 18, 2, 107–135.

KUIPER, M. F. AND SWIERSTRA, S. D. 1990. Parallel

attribute evaluation: Structure of evaluators

and detection of parallelism. In Proceedings ofthe International Conference on Attribute

Grammars and their Applications. Lecture

Notes in Computer Science, vol. 461. Springer-Verlag, New York, 61-75.

LEE, P. 1989, Reahstic Cornpder Generation. TheMIT Press, Cambridge, Mass.

LEWI, J., DE VLAMINCK, K., HUE~S, J., AND

HUYBRECHTS, M. 1979. A ProgrammingMethodology m Compder Construction. Vol. 1and 2. North-Holland, Amsterdam.

LEWI, J., DE VLAMINCK, K., STEEGMANS, E., AND VAN

HOREBEEK, J. 1992. Software Development byLL( 1) Syntax Description. John Wiley & Sons,

New York.

LEWIS, P. M. AND STEARNS, R. E. 1968, Syntax-

directed transduction. J. ACM 15, 3, 465-488.

LEWIS, P. M., ROSENKKANTZ, D. J., AND STEARNS, R.E. 1974. Attributed translations. J. Comput.

Syst. Sci. 9, 279-307.

KNUDSEN, J. L., LOFGREN, M., LEHRMANN MADSEN,O., AND MAGNUSSON, B. (EDs.). 1993. Ob~ect-Orzented Envu-onments: The M@ner Approach.Prentice-Hall, Englewood Cliffs, N.J.

LIPPS, P., MONCKE, U., OLK, M., AND WILHELM, R.1988. Attribute (reevaluation in OPTRAN.Acts Znformatzca 26, 213-239.

LONGLEY, M. 1987. Generating parsers in Miranda.UKC Computing Laboratory Rep. 49, Univ. ofKent at Canterbury.

MALUSZYNSKI, J. 1991. Attribute grammars and logicprogramming: A comparison of concepts. In At-trLbute Grammars, Apphcat~ons, and Systems.


254 * Jukka Paakki

Lecture Notes m Computer Science, vol 545Sprmger-Verlag, New York, 330-357

MALUSZ~NSKI, J. 1982. A comparison of the logeprogramming language Prolog with two-level

grammars, In Proceedings of the 1st Znterna-tlonal Logic Programm~ng Conference, M, van

Caneghem, Ed. Faculte des Sciences de Lu-miny, Marseilles, 193–199

MASON, T AND BI?OWN, D. 1990. Lex & Yacc,

O’Reilly & Associates, Inc., Sebastopol, Calif.

MAYOH, B. 1981 Attribute grammars and mathe-

matical semantics. SIAM J Comput 10, 3,

503-518.

NAUR, P, (ED.). 1960, Report on the algorithmic

language ALGOL 60. Commun. ACM 3, 5,299-314.

NOLL, T AND VOGLER, H. 1994 Top-down parsingwith simultaneous evaluation ofnoncircular at-

tribute grammars Fundamental Inf 20, 4,285-331.

NOTKLN, D. 1985. The Gandalf Project. J. Syst

Softw, 5, 91-106.

PAARKI, J. 1991. PROFIT: A system mtegratmglo~c programming and attribute grammars. In

Proceedings of the 3rcl International Sympo -sl urn on Program mmg Language Implementa-

tion and Logzc Programmmg (PLZLP ‘91), Lec-ture Notes in Computer Science, vol. 528, J.Maluszynskl and M. Wmsmg, Eds. Sprmger-Verlag, New York, 243-254.

PAAmiI, J. 1990. A logic-based modification of at-

tribute grammars for practical compder writ-ing. In Proceedings of the 7th International

Conference on Logzc Programming, D. H D

Warren and P. Szeredi, Eds The MIT Press,

Cambridge, Mass., 203-217.

PAAKKI, J. AND TOPPOLA, K. 1990. An error-recover-

ing form of DCGS. Acts Cj bernetLca 9, 3,211–221.

PAULSON, L. 1982 A semantics-directed compilergenerator In Proceedings of the 9th AnnualACM Symposium on Principles of Progrant-m zng Languages (Albuquerque, New Mex. )ACM, New York, 224-233.

PEREIRA, F, C, N. ANI) WARREN, D H. D. 1980Defimte clause grammars for language analy-

sIs—A survey of the formahsm and a compari-son with augmented transition networks. Ar-

tzf, Intell. 13, 231–278.

PEYTON JONES, S. L. 1985 Yacc in Sasl—An exer-cise in functional programming. Softw. Pratt.Exp 15, 8, 807-820

REISS, S. P. 1987 Automatic compiler production:The front end. IEEE Trans. Softw. Eng. SE-13.6, 609-627,

REISS, S P 1983. Generation of compiler symbol

processing mecb anisms from specificationsACM Trans. Program Lang Syst 5, 2,127-163.

REPS, T, W. AND TEITELBAUM, T, 1989. The Synthe-sizer Generator—A System for Construct ng

Language-Based Editors. Springer-Verlag, NewYork

RAIHA, K.-J , SAARINEN, M , S.+MA~OSKI, M , SIPPU,

S., SOISALON-SOININEN, E , AND TIENARI, M

1983. Revised report on the compiler writing

system HLP78. (Helsinki Language Processor)Rep A-1983-1, Dept of Computer Science,Umv of HelsinkL

RIDJANO\71C, D. AND BRODIE, M. L. 1982. Defining

database dynamics with attribute grammars.Inf. Process. Lett. 14, 3, 132-138.

SATALURI, S, R. 1988 Generahzmg semantic rules

of attribute grammars using loglc programs,Ph.D. thesis, Univ of Iowa, Ames, Iowa.

SESHADRI, V. AND WORTMAN, D, B. 1991. An investi-gation into concurrent semantic analysis

Softw. Pratt. Exp 21, 12, 1323-1348

SETHI, R. 1989. Programm~ng Languages—Con-cepts and Constructs. Addison-Wesley, Read-ing, Mass,

SHAW, M. 1990. Prospects for an engmeermg disci-

pline of software. IEEE Softw. 7, 6, 15-24.

SHINODA, Y. AND KATAYAMA) T. 1990. object-orientedextension of attribute grammars and its imple-

mentation. In Proceedings of the Interns tzonalConference on Attrzbute Grammars and thezrAppZLcattons. Lecture Notes in Computer Sci-

ence, vol. 461. Springer-Verlag, New York,177-191.

SHINODA, Y, AND KATAYAMA, T 1988. Attributegrammar based programming and Its envn-on-ment, In proceedings of the 21st Hau,azz Inter-national Conference on System Sczences. IEEE

Computer Society Press, 612-620,

STEEL, T B,, JR. (ED ). 1966, Formal language de-

scription languages for computer program-mmg. In Proceedings of the IFIP Working Con-

ference on Formal Language Descnptlon Lan-guages, North-Holland, Amsterdam.

TARHIO, J 1989 A compiler generator for attributeevaluation during LR parsing, In Proceedingsof the 2nd Internatmnal Workshop on CompilerCompzlers and Htgh-Speed Compzlatlon Lec-ture Notes in Computer Science, vol 371, D

Hammer, Ed. Sprmger-Verlag, New York,146-159,

TOCZKI, J., GYIM6THY, T., HORVATH, T,, AND KOCSIS,F. 1989. Generating modular compders mPROF-LP In Proceed, ngs of the Workshop onCompder Compiler and Hzgh Speed Compzlat-tlon. Berlln (GDR) Rep. 3/89, Akademle derWissenschaften der DDR, 156-166.

TRAHANIAS, P. AND S~ORDALA~IS, E 1990 Syntacticpattern recogmtion of the ECG IEEE TransPatt. Anal. Machtne Intell. 12, 7, 648-657.

TSAI, W. AND Fu, K. S 1980 Attributedgrammar—A tool for combining syntactic andsta’ustical approaches to pattern recogmtlon,IEEE Trans Syst Man Cybernet. 10, 873–885,

UHL, J., DROSSOPOULOIT, S , PERSCH, G , Goos, G ,DAUSMANN, M , WINTERSTEIN, G , AND



KIRCHGASSNER, W. 1982. An Attribute Gram-

mar for the Semantic Analysis of Ada. Lecture

Notes in Computer Science, vol. 139, Springer-

Verlag, New York.

WAITE, W. M. 1990. Use of attribute grammars incompiler construction. In Proceedings of theInternational Conference on Attribute Gram-

mars and thezr ApphcatLons. Lecture Notes inComputer Science, vol. 461. Springer-Verlag,

New York, 255-266.

WAITE, W. M. 1986. Generator for attributed gram-

mars—Abstract data type. Arbeitspapiere derGMD 219, Gesellschaft fiir Mathematik undDatenverarbeitung mbH.

VAN DE BURGT, S. P. AND TILANUS, P. A. J. 1989.Attributed ASN. 1. In proceedings of the 2nd

International Conference on Formal Descr~p-

tton Techruques for Distr~buted Systems and

C’ommunzcation Protocols. North-Holland, Am-sterdam, 298–310.

WARREN, D. H. D. 1980. Logic programming andcompiler writing. Softw. Pratt. Exp. 10, 2,97-125.

WASSERMAN, A. I. (ED.). 1980. Tutorial on program-ming language design. In Proceedings of IEEE

COMPSAC ’80. IEEE Computer Society Press,Los Alamitos, Calif.

WATT, D. A. 1991. Programming Language Syntax

and Semantics. Prentice-Hall, EnglewoodCliffs, N.J.

WATT, D. A. 1990. Programming Language Con-

cepts and Paradigms. Prentice-Hall, Engle-

wood Cliffs, N.J.

WATT, D. A. 1985. Modular description of program-ming languages. Rep. A-8 1-734, Computer Sci-

ence Division-EECS, Univ. of California,Berkeley, Calif.

WATT, D. A. 1984. Executable semantic descrip-tions. Softzo. Pratt. Exp. 14, 1,13-43.

WILHELM, R. 1982. LL- and LR-attributed gram-mars. In Programmiersprachen und Program-mentwzcklung, 7. Fachtagung, H. Wossner, Ed.

Informatik-Fachberichte. Springer-Verlag,Berlin, 151-164.

VOGT, H. H., SWIERSTRA, S. D., AND KUIPER, M. F.1989. Higher order attribute grammars. In

Proceedings of the ACM SIGPLMV ’89 Confer-ence on Programming Language Design and

Implementation. ACM SIGPLAN Not. 24, 7,131-145.

VORTHMANN, S. A. AND LEBLANC, R. J. 1988. Anaming specification language for syntax-

directed editors. In Proceedings of the IEEEConference on Computer Languages (Miami

Beach, Fla.). IEEE, New York, 250-257

YELLIN, D. M. 1988. Attribute Grammar Inverszon

and Source-to-Source Translation. Lecture

Notes in Computer Science, vol. 302. Springer-

Verlag, New York.

ZARING, A. K. 1990. Parallel evaluation in attributegrammar-based systems. Ph.D. thesis, Tech.

Rep. 90-1149, Dept. of Computer Science, Cor-nell University, Ithaca, N.Y.

Received June 1992; final revision accepted September 1994,

ACM Computing Surveys, Vol 27, No 2, June 1!395

attribute grammar paradigms--a high-level methodology in language implem...

Documents