University of Southern California Dissertations and Theses

Toward a multi-formalism specification environment

(USC Thesis Other)

Toward a multi-formalism specification environment

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content TOWARD A MULTI-FORMALISM SPECIFICATION ENVIRONMENT by Edward Anthony Ipser, Jr. A D issertation P resented to th e FACULTY O F T H E G RA D U A TE SCHOOL U N IV ER SITY O F SO U TH ER N CA LIFO RN IA In P artial Fulfillm ent of the R equirem ents for th e Degree D O C T O R O F PH ILO SO PH Y (C om puter Science) August 1990 Copyright 1990 E dw ard A nthony Ipser, Jr. UMI Number: DP22803 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. Published by ProQuest LLC (2014). Copyright in the Dissertation held by the Author. Dissertation Publishing UMI DP22803 Microform Edition © ProQuest LLC. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code ProQuest LLC. 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 48106-1346 UNIVERSITY OF SOUTHERN CALIFORNIA THE GRADUATE SCHOOL UNIVERSITY PARK LOS ANGELES, CALIFORNIA 90089-4015 This dissertation, w ritten by Edward Anthony Ipser, Jr. under the direction of h.%?........ Dissertation Committee, and approved by all its members, has been presented to and accepted b y The Graduate School, in partial fulfillm ent of re quirements for the degree of Pl D. C P S Iff D O C TO R OF PHILOSOPH Y Dean o f Graduate Studies D a te J.99.9. DISSERTATION COMMITTEE Chairperson Acknowledgments I w ish to th a n k m y advisors an d com m ittee m em bers, D rs. D avid W ile, a n d 1 D ean Jaco b s, w ho co n trib u ted to th e developm ent of m y thesis an d w ith thej fo rm u latio n of th e resu lts, an d D rs. Les G asser, Lewis Jo h n so n , D ennis M cleod, ] an d M ichel D ubois an d m y u n d e rg ra d u ate advisors: D rs. E dw ard M cN ertney^ an d Selby Evans. I also w ould like to acknow ledge th e research an d su p p o rt staff, a t U S C /Infoi’m atio n Sciences In stitu te , p articu larly those w ho helped pro o f this d issertatio n : D rs. D on Cohen an d K rish n am u rth y N arayanasw am y. Finally, I ; w ould like to th a n k m y wife, S u rjatin i W idjojo, for h er com fort an d su p p o rt and m y p a re n ts E dw ard Ipser, Sr. and A nnice R afield Ipser. T his research was su p p o rted , in p a rt, by Defense A dvanced R esearch P ro jects Agency, In fo rm atio n Science an d Technology office, A RPA O rd er No. 6096, issued by Defense Supply Service (W ashington) u n d er co n tracts no. M DA903-87-C-0641 an d M D A 903-8TC -0335. CONTENTS A ck n ow led gm en ts ii A b stra ct viii 1 In tro d u ctio n 1 1.1 Basic I s s u e s .......................................................................................................... 1 1.2 C o n tr i b u t i o n ....................................................................................................... 5 1.3 A p p r o a c h .................. 8 2 R ela ted W ork 11 2.1 Language E x t e n s i o n ......................................................................................... 12 2.2 M e ta p ro g ra m m in g ............................................................................................ 17 2.3 D r a c o ..................................................................................................................... 18 2.4 Local F o rm a lism s................................................................................................ 22 2.5 I D L ........................................................................................................................ 23 2.6 O pen S y ste m s....................................................................................................... 25 3 M u lti-F orm alism Specification M eth o d o lo g y 27 3.1 Interface D esig n .................................................................................................... 27 3.2 Form alism D esig n ................................................................................................ 31 3.3 A pplication D e s ig n ............................................................................................ 34 3.4 S u m m a r y .................. 35 4 F orm alism D esig n 37 4.1 Form alism S y n t a x ............................................................................................ 37 4.1.1 R elated W o r k ....................................... 38 4.1.2 Syntax . ................................................................................................ 41 4.1.3 M e ta v ariab le s............................................................ 43 4.2 Form alism S e m a n tic s......................................................................................... 43 4.2.1 Syntax D irected D e fin itio n s .............................................................. 44 4.2.2 R elated W o r k ...................................................................... 45 4.2.3 A ttrib u te A ction S e t ............................................................................ 48 4.2.4 Im p le m e n ta tio n ..................................................................................... 53 4.3 Closed C o m p o s itio n ......................................................................................... 56 iii 4.3.1 A pplications .......................................................................................... 57 4.3.2 P ro c e d u re ................................................................................................. 58 4.3.3 M e th o d s .................................................................................................... 60 4.3.4 Im p le m e n ta tio n .................................... 64 4.4 S u m m a r y ............................................................................................................. 65 5 O p e n C o m p o s itio n 66 5.1 A p p licatio n s.......................................................................................................... 66 5.2 R elated W ork ................................................................................................... 67 5.3 I n te r f a c e s ........................................................................................ 67 5.3.1 A ttr ib u te s ................................................................................................. 69 5.3.2 N onterm inal T y p e s ................................. 70 5.3.3 G lobal D eclarations . . . ................................. 71 5.3.4 Using Interfaces ................................................................................... 73 5.3.5 P ro d u cer/C o n su m er R e la tio n s h ip s ................................................ 75 5.3.6 C om m unication Between F o rm alism s................... 77 5.4 M odular C o m p o s itio n ............................................................... 77 5.4.1 E x a m p le .................................................................................................... 79 5.4.2 Inter-M odule R e fe re n c e s..................................................................... 83 5.4.3 E x e c u tio n ................................................................................................. 83 5.5 Recursive C o m p o sitio n ..................................................................................... 85 5.5.1 E x a m p le .................................................................................................... 87 5.5.2 Inter-Form alism T r a n s i t i o n .............................................................. 88 5.5.3 E x e c u tio n ................................................................................................. 90 5.6 M odule Interface F o r m a lis m s ....................................................................... 91 5.7 S u m m a r y ......................................................................................................... . 93 6 C o n c lu s io n 95 6.1 Evaluation of C o n trib u tio n s .......................................................................... 95 6.1.1 F ittin g th e M odel to th e D o m a in ................................................... 96 6.1.2 M ethods of C o m p o sitio n ..................................................................... 99 6.1.3 Extensible R e u s e ............................................................. 101 6.2 F u tu re D ire c tio n s ................................................................................................... 102 6.2.1 Form alism and Interface D e sig n .......................... 102 6.2.2 Sem antic Definition ................................................................................103 6.2.3 Closed vs. O pen C o m p o sitio n .............................................................. 104 6.3 Final R e m a r k s ....................................................................................................... 105 B I B L I O G R A P H Y 107 A L A D E 119 B G r a m m a r 121 B .l gram m ar .d e c la ra tio n ............................................................................................ 121 iv B.2 d e c l a r a t i o n ............................................................................................... 122 B.3 s ta r t.d e c la r a tio n ................................................................................................... 122 B.4 te rm in a L d e c la ra tio n .............................................................................................122 B.5 p ro d u c tio n .d e c la ra tio n ............................................................................. 123 B.6 expression, term , f a c t o r .................................................... 123 B.7 o p t i o n a l ..................................................................................................................... 123 B.8 constant ........................ 124 B.9 n a m e ........................................................ 124 B.10 n ested _ ex p ressio n ..................... 124 C A t t r i b u t e A c tio n S e t 125 C .l attrib u te_ actio n _ set_ d eclaratio n ........................................................................125 C.2 d e c l a r a t i o n .............................................................................................................. 126 C.3 s ta r t.d e c la r a tio n ........................ 126 C.4 u s e .d e c la r a tio n ....................................................................................................... 126 C.5 n o n te rm in a l.ty p e .d e c la ra tio n ........................................................................... 127 C.6 n o n te rm in a l-d e c la ra tio n ......................................................................................127 C.7 a ttrib u te .d e c la ra tio n .................................................... 127 C.8 a c t i o n .........................................................................................................................128 C.9 o th er .d e c la r a tio n ....................................................................................................128 C.10 e x p re s s io n ..................................................................................................................128 C .l l reference.expression ......................................................................................... 129 C.12 lite ra l.e x p re s s io n ....................................................................................................129 C.13 O th er E x p r e s s io n s ................. 130 D L e x e r 131 D .l le x e r .d e c la r a tio n ....................................................................................................131 D.2 d e c l a r a t i o n ...............................................................................................................131 D.3 c o m m e n t.d e c la ra tio n ................................... 132 D.4 en d .o fJin e.d eclaratio n . ............................................................... 132 D .5 delim iter .d e c la ra tio n ............................... 132 D.6 character .set .d e c la ra tio n ......................................................................................133 D .7 le x e m e .d e c la ra tio n ............................... 133 D.8 expression, term , and f a c t o r ...............................................................................133 D.9 n e ste d .e x p re ssio n ....................................................................................................134 D.10 o p tio n al.e x p re ssio n ................................................................................................ 134 D .l l rep etitio n _ ex p ressio n .......................................... 134 D.12 r a n g e ....................................................................................................................... 134 D .13 operation ....................................................................................................135 D.14 u n sig n ed _ o p e ratio n ............................................. 135 E M o d u le I n te r f a c e F o rm a lis m 136 E .l m o d u le .d e c la ra tio n ................................................................................. 136 v E.2 sim p le .d efin itio n ................................................. 136 E.3 co m p lex -d efin itio n ................................................................................................137 E.4 declaration .............................................................................................................. 137 E.5 in terface.d eclaration .............................................................................................137 E.6 MIF G ram m ar...........................................................................................................138 E.7 M IF INTERFACE....................................................................................................... 139 E.8 MIF In terp reter....................................................................................................... 139 F G rog 142 F .l Grog Base Formalism I n te r fa c e ........................................................................142 F.2 Expression G ram m ar.......................................................... ................................143 F.3 Expression In terp reter......................................................................................... 145 F.4 Statement G ra m m a r.............................................................................................148 F.5 Statement I n te r p r e te r .................................................................. 149 F.6 Declaration G r a m m a r ......................................................................................... 151 F.7 Declaration Interpreter......................................................................................... 153 G Su rvey A n alysis F orm alism s 156 G .l m l ............................................................................. 157 G.2 m 2 ............................ 158 G.3 m 3 ................................................................................................................................158 G.4 m 4 ........................ .158 G.5 m 5 ................................... 159 G.6 m 6 ................................................................................................................................159 G.7 STANDARD INTERFACE......................................................................................... 160 G.8 DATABASE INTERFACE......................................................................................... 160 G.9 DEVICE INTERFACE................................................................................................ 161 G.10 DDL Grammar ....................................................................................................... 162 G .ll DDL Interp reter....................................................................................................... 163 G.12 DM L G r a m m a r ................................................................... 168 G.13 DM L Interpreter....................................................................................................... 169 G. 14 STAT G r a m m a r....................................................................................................... 172 G. 15 STAT I n te r p r e te r ....................................................................................................173 G .16 GRAPH G ram m ar................................................. 175 G.l7 GRAPH In te r p r e te r ................................................................................................ 177 G.18 DEVICE G ram m ar....................................................................................................177 G. 19 d e v ic e G ram m ar............................................. 178 vi LIST OF FIGURES 1.1 A pplications and D o m a in s ................................................................ 5 1.2 A pplication C om ponents and D o m a in s ...................................................... 7 2.1 D raco DAG of L a n g u a g e s ............................................................................... 19 3.1 Software D e v e lo p m e n t...................................................................................... 28 3.2 Elem ents of D e s ig n ................................ 28 3.3 Form alism A x e s .................................................................................................... 33 4.1 Axes of A ttrib u te C la ssific a tio n ....................................... 49 5.1 M odular C om position P arse Trees ............................................................. 78 5.2 Recursive Com position P arse T r e e ............................................................. 86 vii Abstract In a m ulti-form alism specification environm ent an application specification is w ritten in term s of one or m ore dom ain form alism s. No one form alism is sufficient to subsum e th e others in such a way th a t the entire specification could be easily w ritten in th a t one form alism . Instead, different aspects of a specified application are described in term s of narrow dom ain form alism s whose sem antics are defined independently and linked together thro u g h interfaces. T he process of m ulti-form alism specification, in its p urest form , is three sep a rate activities: interface, form alism , and application design which in teract only through th e form alism library. Interfaces are first designed and then form alism s are designed in term s of one or m ore interfaces. Interface and form alism design are ongoing activities; the form alism s and associated tools are saved in a form alism library. T h e application designer selects form alism s from th e library and composes them to specify th e p articu lar application. O nce th e application is specified, an im plem entation is autom atically generated using th e sem antic definitions associated by th e form alism designer w ith the respective form alism s of the specification. T here are two basic m ethods of com position: closed and open. Closed com position explicitly joins p articu lar form alism s to create a new form alism . In open com position, on th e other hand, no new form alism is created. Instead, form alism s are com posed in th e specification on th e basis of th e interfaces on which they are defined. O ther th a n relying on a com m on interface, form alism s in open com position axe to tally independent: they m ay be designed relatively independently, unlike subform alism s of a closed com position. In general, inter-form alism interac tion in closed com position is a rb itrary w hereas interaction in open com position is restricted to th e sem antic concepts of th e interfaces betw een each form alism pair. Tw o m ethods of open com position are supported: m odular and recursive com position. In m odular com position, specifications are broken down into m odules. Each m odule is expressed in a single form alism . A m odular com position m ulti form alism specification consists of one or m ore such m odules, potentially in differ ent form alism s. In recursive com position, substrings in different form alism s m ay be interm ixed. Transitions betw een form alism s in the tex t of th e system specification are explic itly indicated by m et a-sym bols. W hereas m odular com position requires nam ed declarations to be shared betw een form alism s, recursive com position allows direct sw itching betw een form alism s. F u tu re softw are developm ent environm ents m ust su p p o rt m ultiple form alism s as sm oothly as to d ay ’s single-language software developm ent environm ents. A- m ong th e advantages a m ulti-form alism specification environm ent offers over con ventional software developm ent environm ents are: close fit of m odel to problem , com bination, w ithin a specification, of different m odels to describe an application, and extensibility of the m odel base. Guard with jealous attention the public liberty. Sus pect every one who approaches that jewel. Unfortunately, nothing will preserve it but downright force: Whenever you give up that force, you are inevitably ruined. - Patrick Henry Chapter 1 Introduction In a m ulti-form alism specification environm ent an application specification is w rit te n in term s of one or m ore dom ain form alism s.1 No one form alism is sufficient to subsum e th e others in such a way th a t th e entire specification could be easily w ritten in th a t one form alism . Instead, different aspects of a specified application are described in term s of narrow dom ain form alism s whose sem antics are defined independently and linked together thro u g h interfaces. Such a specification environm ent is desirable for several reasons. F irst, such an environm ent perm its a close fitting of m odel to application since each of the form alism s narrow ly describes a p articu lar set of objects and operations. Second, th e ability to com pose form alism s in such an environm ent allows th e selection of only th e form alism s necessary for a p articu lar application. T hird, th e entire base of m odels is extensible sim ply by adding new form alism s. T his m eans th a t as new specification concepts are invented; w hether out of a theoretical orien tatio n or a recognition of a p a tte rn of application requirem ents, these concepts m ay be used in conjunction w ith previously defined specification concepts. 1.1 Basic Issues T h e overall objective in defining a m ulti-form alism specification environm ent is to su p p o rt th e efficient developm ent of reliable softw are applications over th e long 1A formalism is distinguished from a language in that a language is usually self contained whereas, in a multi-formalism specification environment, formalisms are necessarily anything but self-contained. A language, then, may be considered as a formalism with no capability for refer encing constructs outside the language. 1 haul. It is not necessary th a t th e m ulti-form alism specification environm ent pro vide an efficient solution to the developm ent of single applications. In fact, it m ay well be th e case th a t a m ulti-form alism specification environm ent will be burdensom e w henever a new dom ain of applications is encountered. Nevertheless, over several applications w ithin th e sam e dom ain, a m ulti-form alism specification environm ent m ust provide efficient developm ent of application software. O ne approach to th e efficient developm ent of reliable softw are applications pro posed by Levy [Lev87] is to divide th e activity of softw are developm ent into two phases: developm ent an d testing of software developm ent tools, and developm ent of an application using th e tools. Each tool m ay be considered a form alism proces sor (a little com piler or in terp reter) w here the in p u t to th e tool is a specification in a form alism and th e behavior of th e tool is th e tra n slatio n or in terp retatio n of th e specification. A lthough Levy claim s th a t his approach provides an im provem ent in devel opm ent efficiency over trad itio n al approaches, we believe it can be m ade m ore efficient by reusing form alism s on subsequent applications; i.e. th e cost of their developm ent can be am ortized over several applications w ithin th e sam e dom ain. However, if form alism s are to be reused, they m ust be designed m ore carefully in order to be useful for subsequent applications. T here is a tra d e off betw een generality, th e ability to cover a large dom ain of applications w ith a single for m alism , and goodness of fit, th e ease and clarity of specifying and im plem enting a p artic u lar application w ith th a t form alism . G oodness of fit is a g reater challenge for form alism s w hich are to be reused since th e form alism s m ust be m ore general th a n is required by a single application. N eighbors’ D raco system [Nei81] recognized th e im portance of th e reuse and com position of form alism s. In D raco, form alism s axe archived in a dom ain library for reuse. Indeed, N eighbors also suggested th a t form alism an d application design should be perform ed separately by specialists in each activity. Because th e activity of developing softw are form alism s is very different from th e use of these form alism s to specify a p articu la r application, the two activities require very different skills. Form alism design, like language design involves special skills which are likely to be very different from application design skills. Therefore, th ey should be conducted by specialists in any large scale software house. 2 Because of reuse, form alism s are not specifically developed to suit th e require m ents of individual applications. A single form alism m ight not easily fit different application requirem ents. A single form alism m ay be too narrow an d therefore dif ficult, indirect, or im possible to use to specify p articu lar application requirem ents. O r a single form alism m ay be too broad and therefore inefficient or verbose. Levy notes: It seems unlikely th a t any single conceptual m odel can adequately cap tu re th e diverse aspects of a large application. Therefore, th e as sem bly of a num ber of program com ponents in to one large program is an im p o rtan t technology which m ust be developed. Conversely, it is unlikely th a t a single conceptual m odel which is adequate to cap tu re th e diverse aspects of a large application will be a good fit for each p art of th a t application. C om position an d extension of form alism s is necessary for general form alism reuse while m aintaining closeness of fit. A com bination of form alism s can be m ore closely fitted to arb itra ry application requirem ents. If form alism s were n ar rowly defined an d com bined as needed, th e resulting com bination w ould m ore closely fit th e needs of p articu lar applications. T his com bination is the key to m ulti-form alism specification and no previous approach has solved th is p articu lar problem . Language extension is a special case of com position in w hich a form alism is extended by th e addition of new constructs. A n earlier effort a t language extension [SIG69, SIG71] concentrated prim arily on syntactic extension of languages b u t serious language extension necessarily entails the addition not ju st of new syntactic constructs defined in term s of existing constructs b u t th e addition o f entirely new sem antic concepts. In D raco, form alism s axe defined in term s of com ponents, sets of refinem ents w hich transform concepts from one dom ain to others. A directed acyclic graph of high- to low-level form alism s is created by providing a lib rary of refinem ents. Each high-level form alism is defined in term s of one or m ore lower level form alism s and each lower level form alism s m ay be used to im plem ent several higher level for m alism s. Since each D raco refinem ent only operates on a p a rt of th e specification an d since refinem ents are applied one a t a tim e, a t any given tim e, a form alism m ay consist of substrings from several different dom ains. Inter-dom ain interaction is m anaged by th e design of refinem ents and th eir selective application. D raco m ake no effort form alize th e relationships betw een dom ains beyond th e library of refinem ents defining th e dom ains. A dditionally, Freem an [Fre84] has recognized th a t it w ould be desirable to create new dom ains by “gluing” existing dom ains together, com bining th e syntax as well as sem antics of th e underlying dom ains. However, because D raco does not have m echanism s for dealing w ith th e interactions betw een dom ains at th e level of language boundaries, th e problem of com posing dom ains has been pushed outside of Draco. B oth D raco’s and F reem an’s approach to form alism com position are typical of closed composition of which language extension is sim ply a special case. In closed com position, prim itive form alism s are first designed by a form alism designer. Then certain form alism s are selected to be com posed into a single new form alism . This new form alism , then, m ay be used to specify an application or m ay be com posed w ith o th er form alism s into a still larger form alism . In closed com position, the com position precedes th e application. However, closed com position m ust be done by a form alism designer since it involves m anipulating, even m odifying th e sem antics of th e form alism s in any non trivial com position and com position m ust be repeated each tim e a new form alism is added since some application m ight require capabilities of th e new form alism in com bination w ith old form alism s. Closed com position is nontrivial and is com parable in difficulty, in some cases, to form alism design from scratch (e.g. if the com posed form alism s do not fit well and require significant rew riting). If th e form alism designer genuinely attem p ts to anticipate all possible com binations of form alism s which th e application designer might need, either he has to construct a huge com position of all form alism s or he m ust have a com position of all m eaningful com binations of form alism s in th e dom ain library (order(2n) in num ber w here n is th e num ber of prim itive form alism s). E ither all applications m ust fit w ithin a previously defined form alism , w hatever th eir m ethod of defini tion, or th e activities of form alism and application design m ust be recoupled so th a t th e application designer can call upon th e form alism designer to com bine specific form alism s for specific applications. 4 database domain statistics domain graphics domain F igure 1.1: A pplications and D om ains Finally, closed com position is often, in and of itself, a difficult operation, some tim es requiring th e rew riting of m any previously defined concepts in order to relate independently designed form alism s. C oordinating altern ativ e im plem entations of com m on concepts, alone, is a m ajo r headache. Hence, closed com position is inad equate for general form alism reuse. 1.2 Contribution As previously described applications often will not fall into single dom ains. For exam ple, a p articu lar application m ight involve database, graphics, and statistical operations. In figure 1.1, several applications are classified into th e database, graphics, and statistical dom ains. In those cases w here th e application falls into m ore th a n one dom ain, n either dom ain can adequately describe th e application. T he closed com position approach to solving this problem is to create com posite dom ains by crossing th e features o f each. In order to avoid th e dilem m a of choosing betw een order(2n) com position for m alism s an d a g arg an tu an all-encom passing ever-growing m ega-form alism , the activity of com posing form alism s m ust be moved from th e form alism design ac tiv ity to th e application design activity. This change will enable the com position 5 to be m ade on th e basis of w hat the p articu lar application requires. Form alism s will still be designed in a separate phase, b u t they will not be com bined until a p artic u lar application requires a specific com bination. T he application designer should be able to com pose w ithout involving th e form alism designer. O ne approach proposed by D avid W ile [Wil87a, PW 88] is to m ake th e task of form alism design an d closed com position easy enough to b e an application design activity. A lthough prim itive form alism s m ay still be designed during th e activity of form alism design, th e application designer will create com posed form alism s from selected prim itive form alism s which he needs for a p articu la r application. However, it is d eb atab le how easy the task of closed com position can be m ade since these necessarily entail language design. A nother approach is to defer com position to th e actual specification rath er th a n defining a new form alism as a com position. T h a t is, em pow er th e application designer w ith th e ability to com pose specifications of different form alism s w ithout having to define an interm ediate com posite form alism . T his form of genuine m ulti- form alism specification is called open composition; supporting this activity is th e p rim ary contribution of this thesis to th e problem of form alism com position in a m ulti-form alism specification environm ent. Since th e actu al com bination of form alism s is perform ed by th e application designer and not th e form alism designer, th e dom ain designer m ust allow for a general com bination of form alism s. T his m eans th a t th e form alism designer will n o t know specifically which form alism s will be com posed w ith which. A nd since the activity of dom ain form alism design is ongoing, old form alism s m ust be com posed w ith new form alism s, i.e. new form alism s m ust be usable w ith previously defined form alism s. T his m eans th a t th e m ethod o f com posing form alism s m ust be open- ended since th e older form alism s w ould have no way of knowing th e form of new form alism s to which they m ay ultim ately be com posed. Hence th e term “open com position.” In open com position, applications m ay be broken down into com ponents (e.g. th e d atab ase com ponent and the graphics com ponent) an d dom ains are designed to cap tu re th e application com ponents. For exam ple, an application, a, m ight be divided into application com ponents a .x in the d atabase dom ain, a .y in the statistics dom ain, and a .z in th e graphics dom ain (see figure 1.2). 6 database domain a.x graphics domain statistics domain b.r a.y a.z Figure 1.2: A pplication C om ponents and D om ains If com ponents of a m ulti-form alism specification are to be w ritten in different form alism s, there m ust be an understanding of how th e concepts of different for m alism s m ay be shared by one another. In order to describe th e possible sharing of concepts of different form alism s in an open-ended fashion, open com position allows form alism s to be shared th ro u g h interfaces ra th e r th a n directly w ith one another as in closed com position.2 A n interface abstractly describes a set of form alism concepts w hich m ay be shared betw een form alism s. Form alism s share a subset of concepts w ith a form alism interface. W hen two form alism s share th e sam e concept th ro u g h an interface, then specification com ponents w ritten in those form alism s m ay interact. Since interfaces describe a fixed set of form alism concepts an d since the uni verse of form alism concepts is continually growing w ith each additional form alism , m ultiple interfaces are necessary. Each interface m ay describe a different set of concepts and form alism s m ay share concepts w ith one o r m ore interfaces. A form alism norm ally will not share all its concepts w ith an interface, b u t in stead m ay contain local concepts. T h e designer of a form alism controls which 2Freeman [Fre84] recognized interfacing as an alternative to closed composition ( “gluing”) and noted that a general domain interconnection language would be superior to explicit interfaces between formalisms. 7 concepts are local and which are shared w ith o th er form alism s. O n th e o ther hand, concepts w hich are shared m ay be related to m ore th an one interface. In order th a t a sem antic concept m ay be freely used in b o th th e local context, or th e context of th e several interfaces, different aspects of a sem antic concept m ust be differen tiated . T hese different aspects m ay be denoted by m ultiple a ttrib u te s w here the local context and th e contexts th e interfaces each define different a ttrib u te s of the sam e sem antic concept. In a m ulti-form alism specification environm ent, interfaces are designed first and form alism s are defined p a rtly in term s of zero or m ore interfaces and p artly as unique local concepts. This assures com patibility betw een all form alism s which use an interface since any com patibility constraints m ay be expressed in th e interface and im posed on form alism s w hich use th e interface. Sim ilarly, th is forces consis ten t im plem entation of constructs and allows th e resolution of different physical representations in different form alism s. 1.3 Approach T h e p arad ig m of dividing software developm ent into th e stages of form alism de sign an d application design has been previously studied by Levy and Neighbors. Form alism design and im plem entation is a well researched topic, p articularly in term s of program m ing language design and im plem entation. A m ong th e m ethods of form alism definition is th a t of a ttrib u te gram m ars. A ttrib u te gram m ars have som e characteristics essential to m ulti-form alism specification. T h e approach to form alism com position of this thesis also builds upon w ork in open system s, p ar ticularly o b ject/m essage paradigm s which have th e characteristics of extensibility an d m ultiple inheritance of types. To reiterate, th e process of m ulti-form alism specification, in its p u rest form, is th ree separate activities: interface, form alism , an d application design. T he th ree activities in teract only th ro u g h th e dom ain library. Interfaces are designed first an d th en form alism s are designed in term s of one or m ore interfaces. These form alism s and associated tools are th en saved in th e dom ain library. T he appli cation designer th en selects form alism s from th e dom ain library for a particular application and com bines th em to specify th e application. O nce th e application 8 is specified, an im plem entation is generated using the tools associated w ith the respective form alism s of the specification. Form alism syntax is defined by a gram m ar w hich is used to generate a parser for strings in th e form alism . Form alism sem antics are defined by attribute action sets w hich are an ad ap tio n of a ttrib u te gram m ars. A ttrib u te action sets opera tionally define procedural actions for each form alism concept and a ttrib u te pair. T he execution of these procedural actions defines th e sem antics of th e form al ism . Closed com position is a m ethod of com bining form alism s by creating a new form alism w ith th e features of th e com posed form alism s and therefore m ay be useful to th e form alism designer. T hough not th e p rim ary m ethod of form alism com position, closed com position is essential w hen th e m eaning of com ponents of a com position are context-dependent. O pen com position is th e p rim ary m ethod of form alism com position in the m ulti-form alism specification environm ent described in th is thesis. In open com position, interfaces are defined and form alism s defined in term s of interfaces. Ap plication com ponents in form alism s w hich share an interface m ay directly in ter act. Sem antic concepts, m odeled by a ttrib u te action sets, are divided betw een interfaces an d form alism s. Form alism s extend th e sem antic concepts of explicitly chosen interfaces. A pplication com ponents in different form alism s w hich share an interface are free to in teract through th e sem antic concepts of th e interface. N onterm inals, nonterm inal types, a ttrib u te s of nonterm inals, and d a ta types an d objects are used to m odel sem antic concepts. A nonterm inal roughly corre sponds to a sem antic concept of a form alism while a nonterm inal type corresponds to a sem antic concept of an interface. T h e sharing of interfaces is th e basic m ethod of inter-form alism interaction. In terfaces contain attribute declarations, nonterm inal types, an d global declarations. A ttrib u te declarations identify attrib u te s w hich are shared by all form alism s which use th e interface. N onterm inal types define ab stract nonterm inals to which nonterm inals of for m alism s are associated. A ssociated w ith nonterm inal types in an interface are a subset of th e a ttrib u te s of th e interface. W hen a nonterm inal of a form alism are associated w ith a nonterm inal type of an interface, th e nonterm inal m ust provide 9 actions for th e attrib u tes associated w ith the nonterm inal type. Global decla ratio n s are also m ade in interfaces prim arily for th e purpose of describing d a ta stru ctu res which will contain parse nodes shared betw een com ponents of different form alism s. Two m ethods of open com position are supported: m odular and recursive com position. In m odular com position, specifications are broken dow n into m odules. Each m odule is expressed in a single form alism . A m odular com position m ulti form alism specification consists of one or m ore such m odules, po ten tially in differ ent form alism s. In recursive com position, substrings in different form alism s m ay be interm ixed. T ransitions betw een form alism s in th e tex t of the system specification axe explic itly indicated by m eta-sym bols. W hereas m odular com position requires nam ed declarations to be shared betw een form alism s, recursive com position allows direct sw itching betw een form alism s. F u tu re software developm ent environm ents m ust su p p o rt m ultiple form alism s as sm oothly as to d ay ’s single-language software developm ent environm ents. A- m ong th e advantages a m ulti-form alism specification environm ent offers over con ventional softw are developm ent environm ents are: close fit of m odel to problem , com bination, w ithin a specification, of different m odels to describe an application, an d extensibility of th e m odel base. 10 Chapter 2 Related Work M ulti-form alism specification is not a novel concept. Historically, operating sys tem s co n stitu ted th e software developm ent environm ents available to program m ers. T he origins of m ulti-form alism specification begin w ith the early work in language extension in th e late 60s and early 70s th e objective of which was the ad ap tio n of languages to specific applications. A lthough th e approach of syntac tic extension of languages has long been abandoned, it led directly to the next generation of work in this area. D raco as conceived by Jam es N eighbor, and m etaprogram m ing as proposed by Leon S. Levy, essentially p u t forw ard th e concept of designing application specific form alism s as a separate phase of application developm ent. D raco also introduces th e notion of com bining previously defined form alism s to define new ones. W ile’s local form alism s are an attem p t to m ake th e task of language definition practical for th e application designer. M ulti-form alism specification also builds upon a separate base of research: open system s. Unlike th e language extension an d m etaprogram m ing efforts already discussed, m ulti-form alism specification seeks to com bine form alism s in an open ended m an n er such th a t form alism s m ay be used in arb itra ry ra th e r th a n in fixed com binations as was th e case in D raco. IDL is an exam ple of a relatively open ended form alism com position m echanism . 11 2.1 Language Extension D uring th e late ’60s and early ’70s there were efforts to develop extensible language fram ew orks. These efforts were prim arily intended to su p p o rt th e individual user of th e language. These extensibilities m ay be roughly divided into two categories: those features w hich were later included in th e program m ing language A da (as well as others) including: user defined com plex types, subprogram overloading, o p erato r definition, tasking, and generic definitions, an d those which were all b u t abandoned: collectively, syntactic extension. From th e outset, it was assum ed th a t th e m acro approach of defining new concepts in term s of existing ones would be sufficient to handle th e m ore am bitious extensions; th a t given a sufficiently powerful syntactic extension facility, th a t any m odern p r o g r a m m in g language could be defined in term s of th e extensible base language. W hen this was n o t achieved, th e effort was m ore or less abandoned. A m ong th e extensions th a t were recognized could not be handled by th e m acro approach: • variable argum ent supply (optional param eters w ith defaults, key param e ters); • m ulti-tasking; • backtracking; • access to m achine language facilities; • new storage classes or access m ethods; • adding a real-tim e clock; • file system i/o ; • adding block stru ctu re G PL (G eneral P urpose Language) in [Gar69] introduced th e use of subpro gram overloading and o p erato r definition (as used in A da) and th e use of untyped subprogram s to specify m acros. Algol 69 as described in [MP69] also features op erato r definition and overloading. 12 Basel (a base language) and E lf (an extension facility) [Jor69] introduce func tionals, com plex types, and generic functions. Like C om m on Lisp, functions and procedures are values and, as such, m ay be passed to generic functions. Similarly, Im p [Iro69], using an A PL base, introduces operators as values to generalize other operations such as vector operations. P P L (a Polym orphic P rogram m ing Language) [Sta69], also based on A PL, was som ew hat m ore am bitious. It introduced facilities for extending the d a ta space by constructions later introduced in to Pascal an d Ada: heterogeneous com p ound stru ctu res, hom ogeneous sequential structures, unions of o th er classes, and references to m em bers of o th er classes. It had syntax extension m echanism s: in tro d u ctio n of new m onadic and dyadic operators, syntax m acros, control stru ctu re m acros, and com piler-com piler m echanism s. A nd it h ad control stru ctu re m ech anism s not usually available in program m ing languages a t th a t tim e: parallel processes, continuously evaluating expressions, in terru p ts, an d tra p s. A ddition ally, P P L allowed sem antic extension thro u g h compile routines w hich operate on th e p arse tree of th e P P L source code however these routines required direct m od ification of th e language processor. P ro teu s [Bel69] sought to m inim ize th e core language an d allow m acro tra n s form ations to describe th e m apping of new features into old according to a user defined priority. E P S (E xtensible P rogram m ing System ) [Mac69] is a m acro pre processor w hich is based on assem bler m acro processing. In [Nic69], P L /I is de scribed as an extensible language while [Che69] argues against th e adequacy of w hat he calls th e ‘shell’ approach of P L /I, instead, arguing for ‘n a tu ra l’ dom ain- oriented language extensions. B abel [Sco71] is th e m ost am bitious sem antic extensibility environm ent (and, as such, an exception to th e syntactic language extension tre n d discussed above). B abel is an Algol60 subset for which th e com piler is w ritten in Algol60 and, by th e a u th o r’s argum ent, am enable to m anipulation by th e person extending Ba bel. Possible B abel extensions include: new form s of statem en ts, new types, new stru ctu res, syntax oriented docum entation, and diagnostic aids. By rew riting the com piler, albeit in a p o rtab le language, one can m ake a rb itra ry m odifications to th e language. 13 Algol N [Yon71, S+71] is a cleaned up Algol 60 w ith, prim arily, an abstractio n m echanism for o p erato r definition an d overloading. T he EC L program m ing system , containing th e E L I program m ing language, [Weg71, Pre71, Hol71], was another of th e m ore am bitious efforts in extensible languages. It included syntactic extension, d a ta type extension, o p erato r exten sion, an d ‘control p a th ’ extension (m ulti-tasking). E L I continued th ro u g h th e m id ’80s; its follow-on project E-L continues to espouse syntactic exensibility goals. M cAlgol [Bow71] is another m acro preprocessor for Algol in th e sp irit of as sem bler m acros. C ontext m acros axe introduced in [Gra71]. A context m acro gets inform ation from th e context of its use. G PM [Wod71] is an assem bler m acro processor w hich m aps higher level constructs such as expressions into assem bly lan guage. SY N PR O C [FHI71] is a facility for generating syntactic analyzers which lends itself to syntactic extension by definition of new productions. A nother syn tactic m acro preprocessor is introduced in [Ham71]. A generalized d a ta type extension facility is introduced in [Jor71]. In [Sch71] an extensible in terp reter is offered as a basis for language extensibil ity. For any given extension there are th ree phases: tran slatio n , com pilation, and generation. In th e tran slatio n phase, th e extension is described in term s of base language features; in th e com pilation phase, th e new feature is com piled; and in th e generation phase, th e com piled code is su b stitu ted for th e invocation of th e new feature. In th is way, each extension is on th e sam e level as th e original base features in term s of efficiency. A n argum ent is offered in [Dub71] for dow nw ard extensibility of languages. T h a t is, an ability to extend a language to cover new features in th e object language as opposed to th e source language. As an exam ple he offers th e extension of the P L /I language to handle m ultiple files by th e add itio n of a file p aram eter to file op eratio n calls. In actuality, a new com piler h ad to be released, b u t he argues th a t it m ight have been handled th rough a language extension facility if th e language h ad allowed dow nw ard extension. S tandish [Sta75] divides language extension definition into th ree classes: • paraphrase: An extension defined by p arap h rase m aps th e language extension in to features of th e original language. Generally, such an extension m ay be expressed as a preprocessor to th e original language processor. For exam ple, 14 general op erato r definition such as th a t in th e ADA language m ay be added to Pascal by m apping operator invocations into function invocations. Language extensions defined by p arap h rase axe n o t orthogonal to th e original language. • ortkophrase: A n extension defined by orth o p h rase introduces orthogonal features into th e language. By definition, language extensions defined by o rthophrase are n o t definable by p arap h rase. G enerally, language extensions defined by orth o p h rase m ust be expressed as a m odification of th e original language processor. For exam ple, tasking such as th a t in ADA could only be added to Pascal by orthophrase; sim ilarly, backtracking could only be added to Lisp th ro u g h orthophrase. • metaphrase: A n extension defined by m etap h rase changes th e m eaning of expressions in th e original language. For exam ple, changing scoping rules from dynam ic to lexical would be m etap h rase.1 In practice, th e distinction betw een o rthophrase and m etap h rase depends greatly on th e m eth o d of sem antic definition. It is likely th a t in order to achieve or thophrase, a sem antic extensibility m echanism m ust be capable of m etaphrase. S tandish w rites: In oversim plified term s, th e easy extensions seem to be those th a t use p arap h rase to add new features, w hereas th e h a rd extensions seem to be those th a t use orthophrase or m etap h rase to m odify w hat was th ere before. M ore precisely, in th e case of p arap h rase, th e space of definitions users can give has been provided for explicitly in th e extensible lan guage design...[w hereas, in] o rthophrase an d m etaphrase, one norm ally has to m odify a description of the language processor. T he unsophisticated user could no m ore likely ad d a file i / o facility to an extensible language not having one previously th a n he could add a d ate window to his w ristw atch. 1While, in principal, metaphrase is probably something to be avoided, the distinction between orthophrase and metaphrase can become fuzzy. For example, if a language is extended to allow recursion, the translator would then allocate variables dynamically rather than statically. Is that orthophrase, as is the case with respect to functional run time semantics, or metaphrase, as is the case with translation? 15 N eighbors [Nei81] adds: T he psychological set of [the extensibility research] is th a t it is easy to extend a language into a com fortable m edium for discussing a p articu la r problem in a problem dom ain. T h e a u th o r agrees w ith S tandish th a t this view is m istaken. It is th e lesson of th e developers of dom ain-specific languages and system s analysis techniques th a t th e developm ent of a good m odel of th e objects an d operations of a dom ain is only th e result of a long and intense analysis of th e dom ain. T he extensibility work of o u r research differs from th a t of th e late 60s in some im p o rtan t respects: • orthogonality: W ith few exceptions, extensible languages began w ith base concepts an d built up m acros to m ap th e new constructs into th e old. They were p rim arily p arap h rase extensions, extensions w hich destroyed th e or thogonality of th e base language by introducing new concepts which, by th eir very n atu re, though m ore com pact an d easier to use, were redundant. T his research, on th e o th er h an d , is prim arily concerned w ith orthophrase extensions and, as such, th e extensions preserve th e orthogonality of th e language. • power. T he extensibility work, being prim arily m acro oriented, was a less powerful language extension approach th an th e sem antics-oriented approach since all new constructs h ad to be m apped into th e old ones. O ur approach allows access to th e very low level prim itives u p o n w hich th e original lan guage is built. • orientation: T he extensibility work was oriented tow ard th e individual lan guage user; th a t is, th e individual user was expected to supply th e extensions desired and it was expected th a t th eir cost could be am ortized over a single problem . T he language extension approach of this research, on the other h and, is oriented tow ard a form alism designer w ho is responsible to a num b er of language users all of w hom are w orking in a sim ilar dom ain and, as such, w ould m ake use of th e extensions in a num ber of different projects. 16 • scope: T h e scope of th e extensions in the extensibility work was intended to be global w ithin a single system definition; no facilities for isolating ex tensions to certain p arts of th e program were provided. T his resulted in a num ber of problem s: th e m eaning of an extension m ight m ake sense where th e user intended to use it b u t n o t elsewhere; th e syntactic in terp retatio n of one extension m ight collide w ith another causing an am biguity in th e parse; an d th e sem antic in terp retatio n of one extension m ight be affected by its use in an o th er extension which the designer h ad not anticipated. T h e approach of th is research avoids these problem s to various degrees by localizing th e availability of the extension and its use to p articu lar com ponents. 2.2 Metaprogramming Leon S. Levy [Lev87] studied th e use of a new software developm ent paradigm , meiaprogTamming, in which a p a rt of an application is described in term s of a high-level description w hich is th en in p u t to a m etaprogram , producing th e actual program using th e code generation techniques of com piler technology. T he process of application program developm ent is broken into two phases: developm ent of a m odel of th e application in term s of a code generator and th e description of the application in term s of th e m odel. T he code generator of the first phase, the m etaprogram , th en generates th e application program using th e description of the second phase. Levy notes: T here axe several reasons why metaprogram m ing works: 1. It m akes a program changeable w ithin th e lim its of th e code gen erator. New versions of a program can be expected to be as robust as th e initial releases because no ‘p atch es’ are m ade to the code. It is always recom piled from th e specifications. 2. It provides th e program m er w ith leverage by increasing the ratio of th e size of delivered program to th e size of th e p rim ary program description. In b o th of th e projects [Levy cites], th e com bined size 17 of b o th th e specification files and th e code generation program s are ab o u t one te n th of th e size of th e delivered software. 3. It forces th e program m er to th in k ab o u t th e stru ctu re of th e pro gram an d th e process of softw are creation and th u s focuses a tte n tion on p roductivity and quality. 4. P rogram m ing a t th e m eta-level can b e tte r utilize th e skills of train ed com puter scientists since th e developm ent of th e code gen erato rs is sim ilar to th e construction of o th er program tran slato rs. He su p p o rts these claim s by citing two studies: CA RL, a m edium -sized pro gram of ab o u t 45,000 lines of source code, an d JM O S, a larger program of about 250,000 lines for which m etaprogram m ing techniques were used. Levy also notes th a t a single conceptual m odel is unlikely to be adequate for cap tu rin g th e diverse aspects of large applications. He therefore recom m ends the developm ent of a technology for assem bling m ultiple m odels. M etaprogram m ing, as proposed by Levy, does n o t allow for th e reuse of m odels across applications. His argum ent for th e econom ic advantage of m etaprogram m ing is based solely on th e use of a m odel on a single application. W hatever m erit his argum ent has, a g reater economic re tu rn on th e investm ent of th e design of a m odel w ould accrue if th e form alism were reused on subsequent applications in the sam e way th a t tra d itio n al program m ing languages and tools are used on a variety of applications. A second om ission by Levy was his failure to p u rsu e his proposal for the as sem bly of m ultiple m odels. W hile his approach of using m odels only on a single application does n o t create a strong requirem ent for m ultiple m odels, th e reuse of m odels certainly will. W hen m odels are reused, assem bly of m odels becom es crucial. 2.3 Draco D raco [Nei84a, Nei84b, Fre84, Nei81] is a softw are construction system based on th e form alization of a softw are problem in term s of a dom ain description. F irst, a dom ain analyst exam ines th e needs an d requirem ents of a collection of system s 18 F igure 2.1: D raco DAG of Languages in a p artic u la r dom ain and determ ines the objects an d operations in th a t dom ain. N ext, a dom ain designer specifies a dom ain description w hich em bodies th e objects an d operations determ ined by the dom ain analyst. T h e objects and operations are defined in term s of o th er dom ains already know n to D raco. T hen, for any p artic u la r system requirem ent in th a t dom ain, th e system s analyst describes the system s requirem ents in term s of th e dom ain description. T h e system s designer th en m anually refines th e specification from th e dom ain description to th e target language according to th e sem antics of th e language as specified by th e dom ain designer. A dom ain description consists of the syntax and sem antics of a dom ain lan guage. It com prises a parser, a p retty p rin ter, a set of transform ations w ithin th e dom ain language, an d a set of com ponents, pieces of th e dom ain language w hich are refinem ents of objects and operations into o th er dom ain languages in th e dom ain library. A n exam ple of a D raco DAG (directed acyclic g raph) of dom ains is in figure 2 .1. A n exam ple of D raco transform ations is: (p v a rs x y z) (trans true 95 (compr x x) *true*) 19 (trans false 97 (uneq x x) *false*) (trans not# 95 (negation (uneq x y)) (compr x y)) (trans not= 95 (negation (compr x y)) (uneq x y)) (trans ifeliml 99 (ifthen *true* x) x) (trans ifelim2 99 (ifthen *false* x) *empty*) (trans ifelim3 99 (ifelse *true* x y) x) (trans ifelim4 99 (ifelse *false* x y) y) (trans parenthelim 99 (paren (paren x)) (paren x)) (trans parenthelim2 98 (stmnt (paren x) stmnt) (stmnt x stmnt)) (trans parenthelim3 98 (stmnt (paren x) *ometa*) (stmt x *omega*)) (trans stmnteliml 12 (stmnt *empty* stmnt) stmnt) (trans stmntelim2 12 (stmnt *empty* *omega*) *omega*) (trans bodyelim 12 (body (stmnt x *omega*)) x) (trans bodyelim2 12 (body (stmnt *empty* *omega*)) *empty*) (erasepvars) A n exam ple of a D raco com ponent is: component: *proclist* (procs) purpose: the list of functions known to Draco refinement: lisp function list as a read execution sequence instantiation: inline internal: lisp (lisppgm {{procs}}) end refinement end component D raco assum es: • th e dom ain will be reused to develop sim ilar system s in th e dom ain; • th e dom ain analysis can be done before th e system s are developed; • th e refinem ent of th e system specification m ay be interactive an d guided by th e system s designer. D raco seeks to satisfy six sta n d a rd softw are engineering objectives: • abstraction levels: A bstraction is provided by th e dom ain language an d by th e hierarchy of dom ain definitions. C onnection to higher and lower levels of ab stractio n is provided th ro u g h com ponents. • structure o f products: S tru ctu re is provided by th e dom ain language, the syntax of w hich is specifically designed for th e dom ain. 20 • system atic process: System atic process is provided by th e design/usage phases of th e dom ain description an d th e refinem ent of specifications in the dom ain. • modeling: T h e dom ain languages, by th eir n atu re, m odel th e system s of th e dom ain. C om ponents provide for th e m odeling of external objects and operations. • com partm entalization o f knowledge: T he narrow w id th of th e dom ain lan guages focuses th e atten tio n of th e system s analyst, assum ing th a t the boundaries of th e language correspond to n a tu ra l boundaries of hum an knowledge. • reusability: D om ain descriptions are reused to describe new system s in th e dom ain (as a source language) and to define o th er dom ains (as an interm e d iate language). F reem an notes, however: [Fre84] As we gain m ore experience in creating new dom ain languages, it is becom ing clear th a t one often w ants to create a new language out of existing languages. For exam ple, if you h ad a language for describing statistical calculations and another language for describing tab u lar re p o rt fo rm attin g , you m ight well w ant to create a new language form ed sim ply by ’’gluing” these two languages together. Freem an cites two approaches to com posing languages: • establish interfaces in th e syntax of a new language to th e underlying lan guages (this, however, leads to an n-square problem in interfacing), • design a specific dom ain interconnection language for tying together existing dom ains (an approach th a t has n o t been explored by th e D raco project). However, D raco’s approach to language com position was purely a closed com positional approach. T his requires th a t th e language designer either anticipate w hat com binations of languages th e system designer m ight need or be on standby to provide th e com binations w hich th e system designer requests. 21 2.4 Local Formalisms Dave W ile’s local form alism s [Wil87a, PW88] represent a desire to m ake closed com position easy enough to be done as an application design activity. By elim in atin g th e global scope problem m entioned above, he hopes to allow users to tailor n otations and sem antics to th e problem a t hand. T h e user is not extending languages, b u t ra th er developing very problem -specific m ini-languages over whose sem antics he has toteil control. In a way this is very resonant w ith this th esis’ use of interface concepts: as long as th e user m aps his n o tatio n into (shared) kernel concepts, th e form alism is sem antically grounded. T he interfaces of this thesis are directly descended from W ile’s kernel concepts although th ey are given m ore flexibility in providing local co n stru ct interp retatio n . Local form alism s allows a user to define form alism s an d to relate th e notations of th e form alism to o th er shared form alism s by a set of transform ations. Dave W ile divides a very w ide-spectrum language into local form alism s by separating language constructs into groups. Each local form alism is defined by transform a tion into a lower level form alism b u t th e transform ation process proceeds through shared kernels, groups of constructs which are shared betw een local form alism s such th a t all constructs of a p a rticu lar local form alism can be m apped into th e kernel set of constructs. Since th e kernel is shared betw een form alism s, th e speci fication m ay then be transform ed as if it were in th e lower level form alism . This process continues u n til th e specification has been reduced to th e lowest level local form alism . H um an guidance will be needed in th is process p rim arily in deciding w hich p articu lar in term ed iate form alism s to use, an d th en for m ajo r representation choices betw een form alism s. T h e assum ption th a t local form alism s m akes, th a t language extension is easy, or can be m ade easy, is debatable. Like D raco, local form alism s is based on a tran sfo rm atio n al approach to softw are developm ent; th u s th e task of applica tio n developm ent already includes th e selection of transform ations, w hich m eans th a t th e application designer is necessarily fam iliar w ith transform ations. Local form alism s’ approach to language extension is less defensible in th e context of a co m p iler/tran slatio n approach to language sem antics w here the m echanism of tran slatio n is hidden from th e application designer. In th e la tte r case, th e activity 22 of language design is very different from th e activity of application design using th e language. 2.5 IDL IDL (Interface D escription Language) [Nes81, Nes82, SN87] is a language for spec ifying th e a b stra c t properties of d a ta stru ctu res shared by softw are m odules, possi bly w ritten in different languages, and th e tran slatio n of those ab stract properties into the respective targ et languages. IDL was designed to be used w ith trad itio n al program m ing languages such as FO R T R A N and Pascal b u t introduces m ore ab stra ct concepts of d a ta stru ctu res and processes. T he ab stractio n m odels d a ta stru ctu res as typed, a ttrib u te d , directed graphs w here each node has a collection of attrib u te s and each a ttrib u te can have a prim itive type, a constructor type, a private type, or a node. This a b strac t d a ta stru ctu re m ethodology is then m apped onto the specific d a ta stru ctu res of th e spe cific languages. If th e physical stru ctu re is not identical, then readers and w riters are w ritten which convert d a ta stru ctu res into stream s of text which are passed betw een th e m odules of th e incom patible languages. IDL also has classes (like som e object oriented languages) in order to organize the definitions of attrib u tes. T h e IDL process declaration is used to describe ab stractly com putations p er form ed upon th e declared structures. It is these processes which are im plem ented in p artic u la r program m ing languages and which pass stru ctu res betw een them . For exam ple, p a rt of a billing operation m ight be specified as follows: STRUCTURE customers ROOT customer_list IS customer_list => list : SEQ OF customer ; customer commercial_customer | government.customer ; customer => name : string, address : string, active : boolean, customer.number : integer, balance : rational ; commercial.customer => industry.code : integer ; government.customer ::= state.customer I federal.customer ; state.customer => state.code : integer ; federal.customer => agency.code : integer ; END 23 STRUCTURE transactions ROOT transaction.list IS transaction_list => list : SEQ OF transaction ; transaction ::= credit I debit ; transaction => customer.number : integer ; date : integer ; amount : rational ; tax.status : SEQ OF tax.code ; credit => ; debit => ; tax.code ::= local.sales.tax I state.sales.tax I federal.sales.tax local.sales.tax -> ; state.sales.tax => ; federal.sales.tax => ; END STRUCTURE bills ROOT bill.list IS bill.list -> list : SEQ OF bill ; bill => billee : customer, amount : rational ; customer ::= commercial.customer I government.customer ; customer => name : string, address : string, customer.number : integer ; commercial.customer => industry.code : integer ; government.customer : state.customer I federal.customer state.customer => state.code : integer ; federal.customer => agency.code : integer ; END PROCESS billing IS PRE customers.in : customers ; PRE transactions.in : transactions ; POST customers.out : customers ; POST bills.out : bills ; END PROCESS printing IS PRE bills.in : bills ; END T he process b i l l i n g takes c u sto m e rs and t r a n s a c t i o n s as in p u t and pro duces as o u tp u t c u sto m ers and b i l l s . T he process p r i n t i n g th en m ay take th e b i l l s and p rin t them . IDL allows th e process b i l l i n g and th e process p r i n t i n g to be specified in relatively a rb itrary languages so long as a m apping of IDL d a ta stru ctu res to th e languages can be m ade. In term s of m ulti-form alism specification, IDL is a p artic u lar form alism in terface. However, th e b u rden in interfacing languages using IDL falls upon the application designer in two im p o rtan t ways. F irst, IDL is a fixed m odel of com p u ta tio n , nam ely, d a ta stru ctu res an d processes and language constructs m ust be related to this m odel in order to in teract w hereas in a m ulti-form alism specification environm ent, th ere m ay be any nu m b er of interfaces each of w hich m ay represent an a rb itra ry m odel of com putation. T his is not a significant issue w hen IDL is used to interface conventional program m ing languages like FO R T R A N and Pascal, b u t becom es a problem w ith narrow er, specialized form alism s such as relational d atab ase languages and graphics languages. Second, IDL is an afterthought to language design; if the d a ta stru ctu res of the languages are physically incom patible, th en IDL d a ta stru ctu res m ust be tra n s lated in to tex t strings passed betw een processes of the incom patible languages. Not only does th is place th e b u rden of relating IDL d a ta stru ctu res to language d a ta stru ctu res on th e application designer, b u t it creates an incredible efficiency bottleneck as efficient d a ta stru ctu res are converted into tex t strings and back again. 2.6 Open Systems A ccording to H ew itt [HdJ83, Hew84, Hew85], open system s are system s charac terized by: 1. continuous change and evolution; 2. arm s-length relationships an d decentralized decision m aking; 3. p e rp etu al inconsistency am ong knowledge bases; and 4. inadequacy of th e closed-world assum ption. 25 He argues th a t logic program m ing is inherently unable to represent and reason in such environm ents and proposes, instead, a m essage passing scheme in which m essages derive th eir m eaning operationally. T he crux of his argum ent is th a t open system s, by th eir very n atu re, violate th e closed w orld assum ption (th a t all and only th e relationships th a t can possibly hold am ong objects are those im plied by th e local inform ation). P ro o f is given in [Ips89] th a t open-ended system s are com putationally m ore pow erful th a n a closed-ended system . Evidence is provided in [IW J90, Ips90] th a t such open-ended system s have p ractical applications in the dom ain of softw are developm ent. In m ulti-form alism specification, because th e com position of form alism s is p er form ed during th e application design activity ra th e r th a n th e form alism design activity, form alism s m ust be m odular and openly com patible. Form alism s, as designed, m ust be capable of interacting w ith o th er form alism s which m ay later be designed or w hich m ay change. T he sem antics, therefore, of form alism s m ust be localized and param eterized; in other words, th e m ulti-form alism specification environm ents have th e characteristics which H ew itt calls open system s. T he essential im plication of this sim ilarity is th a t th e m ulti-form alism specifi cation environm ent m ust be built upon open system tools not sim ply as a m atter of convenience b u t as a m a tte r of necessity. In p articu lar, th e m ethod chosen for im plem enting form alism s is th e Com m on Lisp O bject System , a program m ing m ethodology w hich is derived from research in open system s. 26 Chapter 3 Multi-Formalism Specification Methodology T he activity of software developm ent provides a client w ith an im plem entation for inform al requirem ents of a p articu la r application. W ith in th e m ethodology of m ulti-form alism specification, softw are developm ent is divided into th ree inde p en d en t activities: interface, form alism , and application design (see figure 3.1). A lthough a m ulti-form alism specification environm ent is not intended for p ro gram m ing in th e sm all, th e sam e person m ay engage in all activities by changing roles. B ut in a large scale software developm ent environm ent, these activities will be assigned to different persons. T his m ethodology dictates p artic u la r decisions ab o u t th e design an d im plem en tatio n of o u r m ulti-form alism specification environm ent. Therefore, it is im p o rtan t to u n d erstan d th e m ethodology in o rd er to appreciate th e im plem entation and to u n d erstan d th e reasoning behind decisions in its design. Significantly deviating from th e m ethodology w ould inevitably lead to different design decisions, to a different m ulti-form alism specification environm ent. 3.1 Interface Design A m eta-dom ain is an equivalence class of dom ains whose form alism s share com m on sem antic concepts. A dom ain is a set of application com ponents for which a form alism exists th a t contains th e set of specifications of each application com ponent. A n application com ponent is a p a rt of an application. A pplications m ay b e broken dow n in to com ponents each of w hich is a m em ber of a single dom ain. 27 analysis of application domains interface and formalism design formalism definition client applications analysis of formalism usage domain formalism library formalism definition application design application > implementation F igure 3.1: Softw are D evelopm ent A.d A.b A.c A.a ■\ domain library Figure 3.2: Elem ents of Design 28 Together th e com ponents com prise th e application. T here is a one-to-one corre spondence betw een m eta-dom ains and interfaces, dom ains and form alism s, and applications and specifications; in each case, th e form er is m odeled by th e later. For exam ple, a lib rary m ight contain a relational d atab ase form alism , a graph ical operations form alism , an d a statistical operations form alism . T he three of these form alism s m ight be used to describe an application w hich included objects an d operations in all th ree dom ains. T he specification w ould be broken into three m odules each in one form alism , respectively. In order th a t th e statistical com po n en t of th e application m ight in teract w ith the d atab ase or graphical com ponent, interfaces will also exist in th e library. T he sim plest such interface w ould consist of procedures an d functions. If a relation test operation in th e relational database form alism were described as a function call th en any form alism which defined func tio n calls could define tests for th e relation in the relatio n al d atab ase form alism . (T his exam ple is m ore fully described in detail in A ppendix G.) A pplication com ponents of different dom ains m ay only in teract on a pairw ise basis if th e b o th dom ains are m em bers of th e sam e m eta-d o m ain .1 In m eta-dom ain analysis, classes of dom ains are generally identified to be m odeled by an interface in order to allow th e interaction of application com ponents. A specific set of dom ains m ay be used as a basis for identifying a m eta-dom ain. T hereafter the m eta-dom ain is generalized. A m eta-dom ain is m odeled by an interface, a form al d eclaration of sem antic concepts th a t are be shared betw een form alism s in th e m eta-dom ain. Interfaces are designed before the form alism s which use them so each form alism will be defined p artly in term s of th e interface and p artly in term s of local sem antic concepts. Since form alism s are designed after interfaces, form alism sem antic concepts m ay be defined in term s of interface concepts right dow n to th e im plem entation level so th a t definitions of concepts shared betw een different form alism s th ro u g h an interface will be consistent. Previous approaches required th e interface to handle different im plem entations of concepts shared across form alism boundaries. 1The whole question of what is interaction is rather difficult to generally define in the absence of fixed models of semantic definition. In terms o f operational definitions, two components may be said to interact if the underlying interpretation or translation of the specifications requires access to common or shared data. 29 T h e sam e argum ents th a t led to th e a rb itra ry addition of new form alism s to th e dom ain lib rary m ay be used to argue for arb itrarily adding new interfaces to a dom ain library: Since new form alism s will continually be added w hich do not necessarily reflect previously identified sem antic concepts, new interfaces m ay be needed to describe sem antic concepts com m on to th e new form alism s. However, new interfaces m ust obviously be w ritten w ith an eye tow ard form alism s which m ay be u n d er codevelopm ent an d fu tu re form alism s w hich m ay be interfaced to one another. O therw ise you will end u p w ith islands of dom ains w hich have no com m on m et a-dom ain.2 Interfaces are as varied as form alism s them selves as they sim ply contain the sem antic concepts shared betw een form alism s, so it w ould be im possible to create a form al taxonom y of interfaces. However, an inform al taxonom y m ight be built aro u n d th e intended generality of th e interface, th a t is, th e variety of form alism s th a t it is intended to interface. A t one extrem e are very general interfaces w hich are in ten d ed to be used by m ost, if n o t every, form alism . Since th e com putational p arad ig m of procedures, functions, types, and objects is so trad itio n al it is certain th a t every dom ain library will contain a t least one interface based on these sem antic concepts. P ractically all tra d itio n al com puter languages could be com posed th ro u g h such an interface. A dditionally, m any less-traditional com putational paradigm s m ay be easily defined in term s o f procedures, functions, types, an d objects. A m ore specific interface, a relational interface, w ould be used to relate for m alism s w hich define, access, m an ip u late, or display bulk d a ta. T h e interface concepts are relations and operations on relations such as ad d itio n an d deletion of tuples. Also, a graphics device an d p ictu re paradigm , is n o t a com m on com p u ta tio n al paradigm b u t it is exem plary of specific interfaces. Such an interface could be used to relate different graphics description an d g eneration form alism s. T h e relevant shared interface concepts are graphic devices an d graphic operations such as po in t and line draw ing. 2There is a simple method to avoid such isolation which basically would require an ordering of interfaces into a hierarchy where the simplest interfaces are at the root and the more sophisticated and specialized interfaces are toward the leaves. Each new interface would have to be fit into the hierarchy at some point as a child of some previous interface. That way, any two domains would necessarily share some interface even if only the root interface. 30 A n exam ple of a very specific interface is one w hich was intended to interface a decom posed specific program m ing language. A trad itio n al program m ing language such as A da m ay be viewed as a collection of sublanguages, including declarations, statem en ts, packages, tasks, etc. If such a language is to allow th e addition of new sublanguages ra th e r th a n fix th e sublangauges at th e tim e of th e original design, th en som e of th e language concepts will necessarily b e placed in an interface. T h e sublanguages, th en w ould in teract th ro u g h th is interface. Such an interface w ould contain general concepts of declaration (for inter-sublanguage reference) an d execution (for inter-sublanguage execution). 3.2 Formalism Design In th e activity of form alism design, th e form alism designer identifies a p articu lar dom ain, a set of applications or application com ponents, an d attem p ts to define a form alism for it in m uch th e sam e way th a t a program m ing language m ight b e designed for a p artic u lar class of program m ing problem s. W hen a form alism is defined, specific interfaces are selected from th e dom ain library. C oncepts in th e form alism are related to concepts in th e selected interfaces. However, not all concepts of a form alism need be related to an interface. C oncepts of a form alism which are u n related to any used interface are said to be local to th e form alism . T he form alism s draw u p o n specified interfaces to im p o rt an d export sem antic concepts. T h e first phase of th e form alism design activity is th e selection an d analysis of a dom ain. D om ain analysis is th e organization an d categorization of applica tions or application com ponents into dom ains an d th e generalization from exam ple applications in dom ains to other possible applications. In organization, existing applications are exam ined an d those w ith sim ilar characteristics axe grouped to gether in to dom ains. A triv ial exam ple is th e set of d atab ase applications which are grouped together into th e d atab ase dom ain. Sim ilarly, applications involving graphics m ay be grouped together into th e graphics dom ain. In generalization, th e designer tries to proceed from exam ple d atab ase and graphics applications to im agine an d foresee o th er applications in th e sam e dom ain. A nalysis m ay pro ceed either top-dow n or b o tto m -u p by developing com plete m odels or generalizing 31 from exam ple applications, respectively. M ost likely, dom ain analysis will entail a com bination of b o th m ethods. H aving selected and analyzed a dom ain of applications, th e next step in th e form alism design activity is to design a form alism to define th e selected dom ain. A form alism is a set of application specifications for w hich each application or application com ponent in th e dom ain has a corresponding specification in the form alism . W hile dom ains are necessarily ab stract an d inform al, form alism s are b o th concrete and form al in th e sense th a t they specify exact definitions of the dom ain. T he design of a form alism is a tw o stage process. T h e first stage is the de sign of th e syntax of th e form alism . T h e syntax of th e form alism defines th e set of specifications w ithout defining th e m apping from specifications to application im plem entations. D uring this first stage, th ere will only be an inform al correspon dence betw een application specifications and im plem entations. T h e second stage of form alism design is th e definition of form alism sem an tics. T he sem antics of a form alism will define th e m apping from applications specifications in th e form alism to application im plem entations. T h e definition of form alism sem antics is th e construction of a m echanism to effect th a t m apping. Such a m echanism m ay be an in terp reter (as used th ro u g h o u t th is thesis) or a tra n sla to r (as used in th e R eal W orld). W hatever th e m eth o d , th e m echanism m ust autom atically produce an im plem entation. D om ains and form alism s m ay be classified along two, n o t entirely orthogo nal, axes: specific vs. general and narrow vs. b road (see figure 3.3). Specific vs. general is a m easure of th e num ber or range of application com ponents which m ay easily be specified by a form alism . N arrow vs. b ro ad is a m easure of the n u m b er of sem antic concepts contained in the form alism . A form alism is specific if specifications in the form alism succinctly describe applications in th e dom ain. A form alism is general if application specifications are relatively complex. How ever, em pirically speaking, form alism s m ay only be specific w ith respect to certain applications. For applications fu rth er away from the core, specification m ay be difficult or even im possible. For exam ple, a graphics form alism can easily specify graphical operations b u t w ould be difficult or im possible to specify d atabase ap plications. A general form alism , on th e o ther hand, w ould be useful for specifying 32 specific it relational database AP5 narrow broad Ada general Figure 3.3: Form alism Axes m any different applications b u t w ould not easily describe any one of them . For exam ple, program m ing languages like C are general form alism s. A form alism is narrow if it contains only a sm all num ber of concepts. Con versely, a form alism is broad if it contains a large num ber of concepts. For exam ple, b o th C an d ADA are general program m ing languages b u t ADA has a m uch larger num ber of program m ing concepts th a n C. G enerally, th e size of a form alism , and hence th e cost to develop it, is directly proportional to its b read th . In a m ulti-form alism specification environm ent, dom ains and form alism s should be as specific an d as narrow as practical. An extrem e exam ple w ould be a narrow an d specific form alism IT w ith one construct d o i t and w hich specifies exactly one a rb itra ry application com ponent d o in g it. A trad itio n al subroutine library is a dom ain lib rary consisting entirely of such form alism s. However, if a dom ain lib rary is to be som ething m ore th a n a subroutine library, form alism s m ust have som e generality an d b re ad th to them . T his is necessary in order to cap tu re a general space of application com ponents. 33 3.3 Application Design A pplication design is th e activity of converting application requirem ents into a w orking application im plem entation. T he application designer is th e person who converts th e application requirem ents into an application im plem entation in a' m ulti-form alism specification environm ent. H aving received th e application re quirem ents from th e client, th e application designer selects one or m ore form alism s from th e dom ain lib rary for use in specifying th e application. T h e selection of for m alism s is to tally a t th e discretion of th e application designer except th a t the ability of application com ponents in one form alism to interface w ith the applica tion com ponents of an o th er form alism will depend on th e existence and form of interfaces shared by th e form alism s. T he application designer has no direct control over th e design of form alism s nor th e design of interfaces; these are fixed by the form alism designer since form alism s will be reused over several applications. T h e application designer th en w rites a m ulti-form alism specification of th e application in term s of th e selected form alism s. As in dom ain analysis, th e appli cation designer m u st break th e application down in to com ponents each of which m ay be specified in a single form alism . A pplication com ponents m ay only interact th ro u g h concepts contained in interfaces shared by th e form alism s of th e applica tio n com ponents. T his b o th dictates and lim its th e division of applications into com ponents. For exam ple, a client wishes to p rin t graphic pie an d b a r ch arts from d a ta he has collected ab o u t people’s education an d incom e. A m ong th e form alism s w hich th e application designer selects from the dom ain lib rary are th e database form alism an d a graphics form alism . T he d atab ase form alism will be used for describing th e education an d incom e d atab ase w hile th e graphics form alism will b e used to describe th e pie an d b a r charts to be generated. T h e specification is m ulti-form alism because different com ponents of th e application are specified in different form alism s. A n application im plem entation is th en autom atically generated by th e form al ism definitions from th e specification. T he definition of each form alism is used to generate an im plem entation of th e specification of each application com ponent. 34 In teractio n betw een application com ponents is m anaged by th e definition of in terfaces. T he m ulti-form alism specification environm ent produces a single unified application im plem entation from the m ulti-form alism specification. T he final ap plication im plem entation is th en delivered to the client. 3.4 Summary T h e activity of m ulti-form alism specification is divided into th ree sub-activities: interface, form alism , and application design. E ach activity is assigned to a spe cialist w ho is responsible only for his p artic u la r activity. T h e interface designer m ust continually: 1. identify a m eta-dom ain; 2. design an interface to m odel th e m eta-dom ain which: • defines sem antic concepts to be shared by form alism s using th e in ter face; • m ay be extended by form alism s to m odel dom ains in th e m eta-dom ain; 3. deposit th e interface in th e dom ain library. T h e form alism designer m ust continually: 1. identify a dom ain; 2. design a form alism to m odel th e identified dom ain which: • draw s one or m ore interfaces from th e dom ain library; • extends th e selected interface(s) by adding sem antic concepts local to th e form alism ; 3. define th e form alism including those interface concepts produced by th e for m alism ; 4. deposit th e form alism and its definition in th e dom ain library. T h e application designer m ust continually: 35 1. receive application requirem ents from th e client; 2. w rite a specification of th e application which: ! • draw s one or m ore form alism s from th e dom ain library; i • satisfies th e application requirem ents 3. execute th e form alism definitions on th e specification to autom atically gen erate an im plem entation of th e application; 4. deliver th e application im plem entation to th e client. T h e activities of interface design, form alism design, and application design are , strictly asynchronous. 36 Chapter 4 Formalism Design A form alism is defined by its syntax and sem antics. Form alism sy n tax is a rela tively settled issue. G enerally, the syntax of a form alism is defined by a gram m ar w hich m ay b e used to specify a parser. W hile various m ethods of parsin g exist, th e differences betw een even top-dow n vs. b o tto m -u p parsing are u n im p o rtan t to th e specification environm ent. Form alism sem antics, on th e o th er h an d , is anything b u t settled and th e p artic u la r m eth o d chosen can greatly influence the specification environm ent.1 A dditionally, closed com position m ay be considered an issue of form alism de sign. W hereas open com position allows th e application designer to directly com pose form alism s, closed com position entails th e design of a new form alism out of existing form alism s. It is, therefore, a m ethod of com position w hich m u st be u n d ertak en by th e form alism designer as ra th e r th a n th e application designer. 4.1 Formalism Syntax A g ram m ar specifies th e syntax of a form alism and a parser of strings in th e form alism . T he syntax of a form alism is defined by a gram m ar. A g ram m ar consists of a set of productions. E ach prod u ctio n defines a nonterm inal in term s of o th er nonterm inals an d term inals, reserved w ords or lexemes (for exam ple, ’’B E G IN ” an d i d e n t i f i e r , respectively). *For technical details of formalism implementation, see Appendix A. 37 4 .1 .1 R e la te d W ork I T here are m any existing m ethods of defining form alism syntax. A m ong th e m ore fam ous an d com m on is Yacc. Yacc (Yet A nother C om piler Com piler) [Joh75, i Joh78, Joh79] is a U nix facility w hich produces th e front end of a com piler from an an n o tated g ram m ar and a set of C functions. Yacc m ay also be used to specify form alism sem antics b u t th e sem antic definition is entirely procedural. A Yacc an n o tated g ram m ar is of th e form: declarations * /.* /. translation rules supporting c-routines In a Yacc gram m ar: • th e declarations are C declarations and declarations of g ram m ar tokens; • th e tra n slatio n rules are a set of production rules and associated sem antic actions and a g ram m ar expression is a sim ple sequence of nonterm inals and term inals; and • th e su p p o rtin g C routines are routines used by th e tran slatio n rules and the lexical analyzer. However, while Yacc provides a m ethod of specifying th e p arser in term s of a gram m ar, th e tra n slatio n and code generation phases of com pilation m ust still be m anually coded in C. T h e following is an exam ple of a Yacc description of an expression interpreter: u #include <stdio.h> #include <ctype.h> int regs[26] ; int base ; * / . } ftstart list •/.token DIGIT LETTER ‘ /.left ’ I > 38 ‘ /.left '&> ’ /.left » + » ‘ /.left »*> ■'/.left UMINUS • / .* / . V ’ >•/> list /♦null*/ list stat >\n > list error ’ \n’ {yyerrok ;} stat expr expr {printf ("*/d\n" ,$1) ;} letter * = ’ expr {regs[$l] = $3 ;} »)* {$$ = $2 ;} expr {$$ = $1 + $3 ’(’ expr expr ’+ * Bjipx expr *-* expr {$$ = $1 - $3 expr >* > expr {$$ = $1 * $3 e x p r e x p r expr */* expr {$$ = $1 / $3 expr > '/,> expr {$$ * $1 * / . $3 expr {$$ * $1 * / . $3 expr expr {$$ = $1 & $3 expr >I * expr {$$ = $1 I $3 i expr {$$ = $1 I q>o i — expr */*prec UMINUS {$$ = - LETTER {$$ = regs[$l] ;} number > > > > > > > $2 5 3 - number : DIGIT {$$ = $1; base « ($1==0) ? 8 : 10 ;} I number DIGIT {$$ = base * $1 + $2 ;} * /. * /. yylesC) { int c; while ((c=getchar()) « ’’) if (islower(c)) { yylval = c - ’a.’ ; return (LETTER) ;> if (isdigit(c)) { yylval = c-*0’ ; return (DIGIT) return (c) ;} However, w hile a Yacc g ram m ar defines a parser, it is entirely left to the w riter of th e g ram m ar to design an a b stra c t syntax and to generate a parse tree in parsing. P o p a rt, on th e o th er h an d , provides g reater facilities in this area. 39 P o p a rt [Wil87a] (P ro d u cer of P arser and R elated Tools) is a language definition system which supports: lexical analysis, parsing, p retty p rin tin g , tran slatio n , and i transform ation. A g ram m ar is specified in a B N F like syntax an d a parser is i constru cted w hich tran slates strings in th a t language into a com pact parse tree: O th er tools th en work from th a t com pacted parse tree. P O P A R T em phasizes tran sfo rm atio n al tran slatio n . ' For exam ple: e x p r e s s io n := b lo c k I o p e r a tio n ; b lo c k := ’b e g in { d e c la r a tio n “ ’ ; ’ ;} e x p r e s s io n ~ ’ ; { ’ ;} ’ end ; d e c l a r a t i o n := d e c la r a tio n ty p e i d e n t i f i e r ’ , ; d e c la r a tio n ty p e := ’r e a l I ’ i n t e g e r ; o p e r a tio n := < ( ’ + I ’ - ; ) , ( ’ * I ’/) > o p eran d ; o p eran d :* { p lu so p } p r im i t i v e ; p lu so p := ’+ I ’ - ; p r im i t i v e :* i d e n t i f i e r { ’ ( { e x p re s s io n ~ s e p a r a to r } ’ )} I i n t e g e r ’ . i n t e g e r | i n t e g e r I ’ ’ LEXEME ; s e p a r a to r := ’ , I ’ ; ; is a P O P A R T expression gram m ar. T h e sem antics of a P O P A R T language are defined by defaction routines such as th e following: ( d e f a c t i o n - r o u t i n e i n t e r p r e t - o p e r a tio n :grammar exp :n o n te rm in a ls ( o p e ra tio n ) :r u l e s ( ("+ !p r im itiv e " ( i n t e r p r e t - o p e r a t i o n p r im i t i v e ) ) ( " ! i d e n t i f i e r ( ! ! e x p r e s s io n ) " :==> (a p p ly (lexem e i d e n t i f i e r ) (mapcan ( f u n c tio n i n t e r p r e t - o p e r a t i o n ) e x p r e s s io n ) ) ) (o p e ra n d :==> ( i n t e r p r e t - o p e r a t i o n o p e ra n d )) I ( o p e r a tio n :==> ( f u n c a l l ( p o e :o p e r a to r o p e r a tio n ) ( i n t e r p r e t - o p e r a t i o n (p o e : o p e ra n d # l o p e r a tio n ) ) ( i n t e r p r e t - o p e r a t i o n (p o e :o p e ra n d # r o p e r a t i o n ) ) ) ) ( ( v a r i a b l e ) " ! i d e n t i f i e r " :==> (lexem e p o e : p t r e e ) ) ) ) 40 4 .1 .2 S y n ta x Following in th e tra d itio n of Popaxt, th e m ethod of syntax definition chosen to im plem ent m ulti-form alism specification is an u n an n o tated g ram m ar w hich gen-| erates an a b strac t syntax and a p arser w hich generates p arse trees in th e ab stract syntax from strings in th e form alism . T h e p arser generated is b o tto m up and directly in tera cts w ith th e sem antic analysis tools.2 F or exam ple: GRAMMAR exp IS LEXEME identifier ; LEXEME mimber_literal ; START expression ; expression_sequence IS [expression_sequence#sub expression ; expression IS ["N0T"#not] logicand ; logicand IS [logicand#sub logical_operator] relation ; logical_operator IS "AND"#and I "OR"#or ; END exp ; defines an expression formalism, EXP, w ith the following productions: <expression-sequence> :* <t0> <expression> <t0> := <expression-sequence> <t0> := <expression> := <tl> <logicand> <tl> := "NOT" <tl> := <logicand> := <t2> <relation> <t2> := <logicand> <t2> <logical-operator> := "AND" , <logical-operator> := "OR" 2For technical details of formalism grammar, see Appendix B. 41 The following classes axe defined: (defclass identifier nil lexeme) (defclass expression-sequence nil expression-sequence expression) (defclass expression not logicand) (defclass logicand logicand#sub logical-operator relation) (defclass logical-operator nil and or) The parsing of the expression: a*b+c is equivalent to: (expression (logicand (relation (simple.expression (term (term (simple_term (simple_term (factor (primary (identifier "a"))) (factor (primary (identifier "b"))))) 1t + 1» (simple_term j (factor i (primary j (identifier " c" ))))))))) i w hich says som ething for concrete syntax. | | 4 .1 .3 M eta v a ria b les A strin g is a sequence of sym bols (e.g. ascii characters) generable in a form alism g ram m ar from a s ta rt sym bol of th e gram m ar. A su b strin g is a sequence of symbols generable from some nonterm inal in th e gram m ar. A form alism , th en , is th e set of strings. A m etavariable, as introduced by P o p art, is an unexpanded lexeme or nonterm inal in th e g ram m ar of th e form alism . Strings in th e form alism , therefore, m ay include unexpanded sym bols from th e g ram m ar of th e form alism . For exam ple: is a statement m etasym bol and a substring of GROG and x := ; is an o th er sub strin g of GROG containing a e x p re ssio n m etasym bol. A m etavariable m ay contain a substring in an o th er form alism which defines th e m etavariable. For exam ple: is a m etasym bol and a substring of GROG which is defined by a substring in STMT starting at sta te m e n t. 4.2 Formalism Semantics T h e dom ain library contains th e im plem entation, either a tra n sla to r or an in ter p reter, of each form alism . In ad d itio n to syntax, th e im plem entation of a form alism requires th e definition of its sem antics. T he sem antics of a form alism defines its m eaning operationally either in term s of an in terp reter or a tran slato r. 43 4 .2 .1 S y n ta x D ir e c te d D efin itio n s i A syntax-directed definition, also know n as an attribute gram m ar, is a generaliza- i » • 1 I tio n of a context-free g ram m ar in which each g ram m ar sym bol has an associated ; set of a ttrib u te s [ASU86, Kos84]. In addition to th e syntactic fields of parse nodes derived from th e parsing of a string in a p artic u la r gram m ar, a ttrib u te s define ad d itio n al sem antic fields. T he values of th e sem antic fields are determ ined by the; i | sem antic rules associated w ith th e productions of th e g ram m ar in a syntax-directed definition. j T he value of each a ttrib u te at a p artic u la r p arse node is determ ined by a n : a ttrib u te rule associated w ith th e prod u ctio n of th e parse node o r its p aren t de p ending u p o n w hether th e a ttrib u te is synthesized o r inherited. In an a ttrib u te rule, an a ttrib u te is denoted by: x . a w here a is th e nam e of th e a ttrib u te and x is a n o n term in al occurrence in th e associated production. A n a ttrib u te rule is given in th e form of an assignm ent: th e value of an a ttrib u te appearing on th e left-hand side is specified in term s of o th er a ttrib u te s appearing on th e rig h t-h an d side. E xactly one a ttrib u te rule m ay be given for each synthesized a ttrib u te of the left-hand side nonterm inal an d for each inherited a ttrib u te of a rig h t-h an d side n o n term in al of th e associated production. T his guarantees th a t th ere is exactly one a ttrib u te rule applicable to each a ttrib u te of th e p arse tree. For exam ple: INHERITED ATTRIBUTES a , c SYNTHESIZED ATTRIBUTES b , d x ::■ y z ; y . a * f l ( x . a ) y .c = f 2 ( x . c , z .d ) z . a * f 3 ( x .d ) z . c = f 4 ( x .a ) x .b = f 5 ( z .d ) x .d = f 6 ( y . b , z .b ) y ::= t ; t . a * f 7 ( y .a ) t . c » f 8 ( y . c) j y .b * f 9 ( t . b ) 1 y .d = f 1 0 ( t . a , t . d ) j z ::= ; I z ::= x ; 44 x.a = fll(x.a) x.c = fl2(x.c) z.b = fl3(x.a) z.d = fl4(x.b,x.d) defines an syntax directed definition w ith four nonterm inals, tw o synthesized a t trib u tes, tw o inherited a ttrib u te s, and four productions. Since syntax directed definitions are declarative, n o t procedural, an a ttrib u tio n of a parse tree m ust m ake th e necessary assignm ents exactly once and only after th e p aram eters of the j functions have been assigned values. A n evaluator is a procedure th a t evaluates a ttrib u te s in a parse tree by exe cuting assignm ents to a ttrib u te s of parse nodes in accordance w ith th e a ttrib u te rules. If th e syntax directed definition is well defined, th e re exists a sequence of assignm ents th a t results in an a ttrib u te d parse tree w ith all a ttrib u te s evaluated. In p artic u lar, it is easy to define an a ttrib u te g ram m ar w hich is circular and, th ere fore, n o t well form ed. T h e distinguishing features of an evaluator is th e order in w hich it evaluates th e a ttrib u te s of a given parse tree. For exam ple, pass-oriented evaluators assign values to a ttrib u te s during one or m ore traversals (or "passes” ) th ro u g h th e parse tree. However, th ere are m any approaches to syntax directed definition evaluation. 4 .2 .2 R e la te d W ork Irons [Iro63] defined th e sem antics of a language by associating a single a ttrib u te w ith each nonterm inal an d sem antic rules w ith each production. T he tra n sla tion, th en was described as th e recursive application of th e sem antic rule on the a ttrib u te s o f each of its nonterm inals: a synthesis. S yntax directed definitions in th e current form w ere in tro d u ced by [Knu68]. K n u th added m ultiple attrib u te s an d inherited a ttrib u te s to Iro n ’s m ethod. A stu d y of syntax directed definition p racticality is offered in [KRS82] along w ith a design proposal for understandability. T hey observe th a t an syntax directed definition should be w ritten w ith concern for nonterm inals an d th e attributes! th ereo f ra th e r th a n on productions and th e association of sem antic rules w ith them . In an analysis of tim e and space th e a ttrib u te g ram m ars process an average 420 tokens p er second (P ascal) and 350 tokens p er second (C -E uclid) w hereas th e 45 h a n d w ritten com piler processes an average 2500 tokens p er second. In term s of space th e syntax directed definitions handle an average 18 an d 14 tokens per kilobyte, respectively, while th e h an d w ritten com piler takes no significant am ount since it does n o t build a parse tree. A specification of th e static sem antics of A d a in [D U P+ 82, U D P +82] w ritten in an syntax directed definition covers lexical analysis, parsing, an d sem antic analysis w ith a m axim um of th ree visits to each node from an ancestor. j A p ro d u ctio n com piler front end for P ascal w ritten in an sy n tax directed defini-j tio n is described in [Far84]. T h e com piler is Intel C o rp o ratio n ’s Pascal-86 com piler w hich generates code for th e ir iAPX-8086. T he syntax directed definition was orig inally m anually com piled to produce th e first version of th e P ascal com piler b u t was la te r au to m ated by Linguist-86. T h e syntax directed definition was im ple m ented in an altern atin g pass evaluation w ith th e P ascal com piler requiring b o th a left-to-right and a right-to-left pass. In order to avoid th e space requirem ent problem , since th e 8086 has a ra th e r lim ited am ount of m em ory available, th e com piler w rote th e in term ed iate inform ation to files. A m ong th e conclusions of th e w ork was th a t th e com piler was com petitive, th a t it spent h alf of its tim e in file i/o , an d th a t th e altern atin g pass evaluation strateg y was m ore restrictive th an was originally anticipated. A n syntax directed definition is m ap p ed to a one pass (during L R parse) com piler in [Lor77j. B ecause of th e one-pass arch itectu re th e a ttrib u te rules had com patibility co n strain ts basically in th e form th a t a n expression could depend only on inform ation from th e left an d th a t were choices exist in a production, the a ttrib u te s of th e choices m ust be identical. Different values w ere m ain tain ed in parallel for each altern ativ e in th e g ram m ar u n til a decision is m ade (in a reduc tion) a t w hich tim e th e dead ends w ere discarded. In [Wal88] th e syntax directed definition is applied to increm ental com pilation. To organize th e evaluation, certain a ttrib u te s are m arked as “g ated .” Every cycle in an a ttrib u te d g ram m ar m ust have a “gate” a ttrib u te th a t specifies th e location in th e cycle a t w hich evaluation is to sta rt. Strongly connected com ponents are defined w ith a gate an d any changes inside th e SCC schedule th e gate of th e SCC for reevaluation. T his schem e allows for circular dependency. j In [Mad80] th e following syntax directed definition problem s are addressed: circularity, order of evaluation, storage of th e syntax tree and a ttrib u te s, evaluation' of som e a ttrib u te s during parsing, an d allowing th e attrib u te s to influence parsing) i _ _ I I He offers, as a solution, th e DAG evaluator which: works for all sy n tax directed i definitions, represents th e parse tree in a right-parse, an d constructs th e DAG, either by a single scan of th e right-parse or durin g an L R parse. A fter construction,! th e DAG is trav ersed to decorate th e parse tree w ith a ttrib u tes. T h e m eth o d is based on K n u th ’s observation th a t any syntax directed definition m ay be expressed in term s of synthesized attrib u te s only. T h e use of syntax directed definitions to affect p arsing is discussed in [MKR79]. M UG2 [GG82, GRW77] is a com piler generating system w hich su p p o rts all phases o f in terp re te r program m ing language im plem entation. It uses an syntax directed definition general pass evaluation schem e which p erm its any depth-first tree traversal w here the order of visits to th e subtrees of a given node is fixed and know n a t com piler generation tim e. T h e syntax directed definition is organized in to such parses. ATG [Nes83] is an syntax directed definition based on th e n o tatio n of th e d a ta description language IDL. T h e syntax is specified by an ID L description of the parse tree ra th e r them by a gram m ar. A set of a ttrib u te definitions are assigned d a ta types an d m arked as either synthesized or inherited. A ttrib u te equations define th e values of th e attrib u tes. H L P [RSSST78] is an syntax directed definition com piler g en erato r w hich pro duces an L A L R (l) p arser from a g ram m ar description an sem antic analysis from an syntax directed definition. T he code generation, th en , is described in term s of th e a ttrib u te s of th e decorated p arse tree. T h e syntax directed definition m ay require m ultiple traversals (d ep th first scans of th e p arse tree) b u t th e first pass, alw ays a synthesized a ttrib u te evaluation, is always done during th e construction of th e p arse tree. T h e com piler first constructs th e p arse tree during LA LR parsing an d m akes i th e first a ttrib u te g ram m ar pass of th e p arse tree concurrently. N ext, additional 1 passes are m ade over th e parse tree to decorate th e tree w ith a ttrib u te s u n til all a ttrib u te s are defined. Finally, object code is produced from th e a ttrib u te s in a . final scan of th e p arse tree. I 47 FO LD S [Fan82] is an syntax directed definition based com piler generator sys-; ■ ! : tem w hich takes a syntactic definition in term s of a g ram m ar an d a sem antic | definition in term s of an syntax directed definition and produces a p arser an d aj j tra n slato r. T h e tra n slato r s in terp reted in a parallel fashion in order to handle1 ! am biguous gram m ars. 1 GAG [KHZ82] (G enerator based on A ttrib u te G ram m ars) is an sy n tax directed definition based com piler generator w hich is w ritte n in P ascal an d tra n slates A1-! adin (A L anguage for A ttrib u te d D efinitions) program s into Pascal. 1 ; i 4 .2 .3 A ttr ib u te A c tio n S et In th e general case, syntax directed definitions are not only difficult to evaluate, b u t som etim es im possible if th e definitions is circular. A m ong th e possible restric tions on syntax directed definitions is th e L-attributed definition. A n L -attrib u ted definition allows in h erited a ttrib u te s to depend only on p aren t an d siblings to th e left of th e nonterm inal. In th is way, it is gu aran teed th e definition can be evaluated in a single depth-first traversal of th e parse tree.3 A ttrib u te action sets are a fu rth er restrictio n on L -attrib u ted definition. T here are four basic differences betw een a ttrib u te action sets and L -a ttrib u ted definitions: 1. A ttrib u te action sets allow side effects in th e actions defining a ttrib u te defi n itio n w hereas L -attrib u ted definitions are generally declarative. 2. In an a ttrib u te action set in h erited a ttrib u te definitions m ay only be defined in term s of th e p aren t, w hereas L -a ttrib u ted definitions allowed inherited a ttrib u te s to be defined in term s of th e p aren t an d th e left siblings. 3. A ttrib u te action sets p erm it only a single in h erited a ttrib u te definition per n o n term in al w hereas L -attrib u ted definitions allowed a different definition for each occurrence of a nonterm inal in th e rig h t-h an d side of a production. 4. A ttrib u te action sets introduce dynam ic a ttrib u te s w hereas all a ttrib u te s in L -a ttrib u te d definitions axe static. 3For technical details of formalism grammar, see Appendix C. 48 static dynamic synthesized synthesized static attributes synthesized dynamic attributes inherited inherited inherited static dynamic attributes attributes F igure 4.1: Axes of A ttrib u te Classification T h e principle resu lt of th e first th ree differences is th a t a ttrib u te action sets can be evaluated as a side effect of LA LR parsin g w ithout recourse to gram m ar tran sfo rm atio n s. T he attach m en t of in h erited a ttrib u te actions to nonterm inals ra th e r th a n to occurrences of th e nonterm inal on th e rig h t h an d side of productions allows a sim pler definition of sem antics. D ynam ic a ttrib u te , as intro d u ced by a ttrib u te action sets, is an a ttrib u te w hich is recom puted each tim e its value is required. In a a ttrib u te action set a ttrib u te s are classified along tw o axes: synthe sized /in h erited and static/d y n am ic (see figure 4.1). Each a ttrib u te is classified as synthesized or inherited an d again as static o r dynam ic. T hus, th ere are four classes of attrib u tes. Synthesized a ttrib u te s pass values up th e tree from th e leaves to th e root. T he value o f a synthesized a ttrib u te for a given p arse node is defined in term s of th e im m ediate children of th e parse node. T he value of th e a ttrib u te is th en available to th e p aren t of th e parse node. Synthesized attrib u te s generally m odel results of co m putations in th e form alism . In h erited a ttrib u te s pass inform ation down th e tree from th e root to th e leaves. T h e value of an in h erited a ttrib u te for a given parse node is copied from th e p aren t unless an explicit definition of its value is provided. Generally, an explicit definition 49 of value a t a p artic u la r nonterm inal will define a p o in ter to a d a ta stru ctu re which will th en be u p d a ted by side effect of synthesized a ttrib u te s in descendants of parse nodes of th e nonterm inal. T he copying dow n of th e value of th e a ttrib u te , then, causes th e d a ta stru c tu re to be shared am ong every descendant. Inherited ' a ttrib u te s generally m odel scope of declarations in th e form alism . S tatic a ttrib u te s are executed during a single recursive descent (left to right) pass of th e p arse tree. T h e result of static a ttrib u te execution is stored in a slot of th e p arse node for fu tu re reference by o th er static a ttrib u te s and by dynam ic a ttrib u tes. W hen a static a ttrib u te is referenced, th e stored value is retu rn ed . S tatic a ttrib u te s are useful for m odeling static sem antics of a form alism in terp reter such as declarations an d declaration references. D ynam ic a ttrib u te s axe executed upon dem and. W hen a dynam ic a ttrib u te is referenced, th e associated action is executed. D ynam ic a ttrib u te s axe useful for m odeling dynam ic sem antics of a form alism in te rp re te r such as expressions and p aram eter stacks. T he process of executing an a ttrib u te action set consists of executing th e static a ttrib u te s in a single recursive descent of th e p are tree an d th en th e execution of th e s ta rt action. E ith er th e static a ttrib u te actions, th e s ta rt action, or dynam ic a ttrib u te actions m ay in itiate execution of dynam ic a ttrib u te s. E xecution of sta tic a ttrib u te s follows th ree steps for each parse node: 1. If th e p arse node has an explicit inherited a ttrib u te action th en th a t action is executed and th e result stored. O therw ise, th e value is copied from th e p aren t of th e parse node. 2. T hen th e children of th e parse node are each visited left to right. 3. A fter th e children have been visited, th e functions associated w ith th e syn thesized a ttrib u te s of th e nonterm inal of th e p arse node are executed on th e parse node an d th e results stored. In th e process of parsing a string or substring, th e p arser creates a parse tree. T he a ttrib u te g ram m ar o f th e form alism is th en executed on th e p arse tree to p roduce th e desired side effects and values. T h e a ttrib u te action set consists of a ttrib u te s w hich are executed on th e p arse nodes o f th e parse tree. Each a ttrib u te defines a function for each nonterm inal of th e form alism gram m ar. 50 W hen th e value of a synthesized static a ttrib u te o f a parse node is referenced, th e value stored in process of visiting th e p arse node is retu rn ed . W hen th e value of a in h erited static a ttrib u te of a p arse node is referenced, th en value stored in th e process of visiting th e parse node, or th e nearest p aren t w ith a definition for th e a ttrib u te is retu rn ed . W hen th e value of a in h erited static a ttrib u te o f a parse node is set (p articu larly w ith an inherited a ttrib u te ) th e stored value is altered. W henever a dynam ic synthesized a ttrib u te of a parse node is referenced then: 1. th e functions associated w ith th e in h erited dynam ic a ttrib u te s of th e non term in al of th e parse node are executed on th e p arse node an d th e results stored. 2. th e function associated w ith th e referenced synthesized dynam ic a ttrib u te of th e n o n term in al of th e parse node are executed on th e p arse n ode (often th is execution will, in tu rn , invoke th e sam e or o th er synthesized dynam ic a ttrib u te s of children of th e parse node). Individual actions are defined in C om m on Lisp (w ith a slight v ariation on syntax) extended to include a ttrib u te references. For exam ple: p ro g n ( s e t f ( x , * [ a , b , c ] ) , d o i t ( x ) ) w ould, in C om m on Lisp, be: (p ro g n ( s e t f x *(a b c ) ) ( d o it x ) ) A ttrib u te reference is signified by a n o tation, nam ic a n d in h erited o r synthesized a ttrib u te s are not For exam ple: x .e x e c u te is a reference to th e e x e c u te a ttrib u te of th e variable x. In an action, th e parse node of th e g ram m ar p ro d u ctio n ’s left-hand side and p arse nodes o f th e rig h t-h an d side are available as variables of th e sam e nam e as th e nonterm inals. For exam ple: References to static or dy- syntactically distinguished. 51 r e l a t i o n . d e c l a r a t i o n IS s e t f ( r e l a t e _ f r a m e _ o b j e c t ( r e l a t i o n _ d e c l a r a t i o n .f r a m e ) , g e t h a s h ( i d e n t i f i e r . d e c l a r e , r e l a t io n _ o b j e c t _ t a b l e ) ) , s e t f ( r e l a t e .f r a m e _ v a l u e s ( r e l a t i o n _ d e c l a r a t i o n .f r a m e ) , r e l a t e _ f r a m e _ v a l u e s ( r e l a t i o n .d e c l a r a t i o n . r e la t e _ f r a m e ) ) , cond( [ r e l a t i o n _ d e f i n i t i o n , r e l a t i o n _ d e f i n i t i o n . a s s e r t ] , [ t , g e t h a s h ( ’u s e r : : b a s e ,im p l e m e n t a t i o n _ t a b l e ) .a s s e r t] ) ; is th e definition of th e a s s e r t a ttrib u te on th e r e l a t i o n _ d e c l a r a t i o n n o n term i nal. W hen th e a s s e r t a ttrib u te of a DDL r e la tio n _ d e c la r a tio n is evaluated, the above action is executed which: 1. looks u p th e object associated w ith th e relation in th e global vari able r e l a t io n _ d e c l a r a t i o n _ t a b l e , using th e d e c la r e a ttrib u te of the i d e n t i f i e r (w hich is a lisp sym bol o b tain ed by interning th e lexem e of th e identifier) as a key, and stores th a t in th e r e l a t e _ f ra m e _ o b je c t slot of an object stored in th e inherited dynam ic a ttrib u te fram e, 2. copies th e actu al p aram eters (w hich were stored as a list in th e r e la te _ fr a m e _ v a lu e s slot of th e o bject stored in th e r e l a t e _ f ram e by the caller) from th e inherited dynam ic a ttrib u te r e l a t e .f r a m e to th e inherited dynam ic a ttrib u te fram e, 3. depending u p o n w hether th e relatio n has a r e l a t io n _ d e f i n i t i o n subtree, it (a) evaluates on r e l a t io n _ d e f i n i t i o n , th e synthesized dynam ic a ttrib u te a s s e r t , or (b) evaluates th e synthesized dynam ic a ttrib u te a s s e r t of th e p arse node in th e global variable im p le m e n ta tio n _ ta b le u n d er th e key ’’base” A n a ttrib u te action set m ay be used to specify an in terp reter for a form alism . See A ppendix F for exam ples of in terp reters defined by a ttrib u te action sets. T he synthesized dynam ic a ttrib u te EVALUATE is defined for a lo g ic a n d to evaluate th e expression: 52 cond( [logicand#sub, funcall( logical.operator.evaluate, logicand#sub.evaluate, relation.evaluate)] , ct, relation.evaluate]) W hen a lo g ic a n d # su b is present, th e LISP function re tu rn e d by th e synthe sized dynam ic a ttrib u te for th e lo g ic a l_ o p e r a to r is applied to th e result of the lo g ic a n d # su b an d th e r e l a t i o n . N ote th e co n trast betw een th e behavior of th e e v a lu a te an d code a ttrib u te s on th e nonterm inal lo g ic a n d in th e tra n slato r and in terp reter, respectively. T h e in terp reter defines an a ttrib u te th a t did not have a corresponding a ttrib u te in th e tran slato r: th e in h erited dynam ic a ttrib u te c a l l _ f rame w hich is defined on th e f u n c tio n _ in v o c a tio n nonterm inal. W henever a f u n c t i o n . c a l l is encoun tered, a fram e d a ta stru c tu re is stored w ith th e parse node. W hen th e param eters of th e f u n c t i o n . c a l l are evaluated, th e result is stored in th e fram e. Since this is a in h erited dynam ic a ttrib u te , references to th e c a l l _ f ram e during th e execu tion of th e a ttrib u te s associated w ith th e function will reference th is fram e (unless an o th er f u n c t i o n . c a l l is encountered). 4 .2 .4 Im p le m e n ta tio n T h e C om m on Lisp O bject System (CLO S) [BDG+88] is an object-oriented pro gram m ing p arad ig m consisting of objects, classes, generic functions, an d m ethods. A n object is a d a ta stru c tu re which m ay have slots in w hich values are stored. Each object is an instance o f a class. A class defines th e slots of objects which are instances of th e class. A class is a subclass of zero o r m ore o th er classes from w hich it inherits th e characteristics of those o th er classes including th eir slots. A generic fu n ctio n is a definition of a function nam e an d th e p aram eters of th e function b u t not of the com putation of th e function. A m ethod is a definition of th e co m p u tatio n of a generic function w hich is applicable to specified classes of objects. A m eth o d m ay specify th e class of p aram eters to w hich th e m ethod is applicable. 53 For exam ple: ( d e f c l a s s p o in t () ((x r i n i t a r g :x ) (y : i n i t a r g : y ) ) ) defines th e class p o in t w ith tw o slots x and y. ( s e t f o b je c t (m a k e -in s ta n c e ’ p o i n t ) ) creates an o bject of class p o in t an d stores it in th e variable o b je c t. ( s e t f ( s l o t - v a l u e o b je c t ’x ) 13) sets th e x slot of th e object stored in th e variable o b je c t to 13. If we in tro d u ce a new class: ( d e f c l a s s p o l a r - p o i n t () ( ( r : i n i t a r g : r ) (a n g le : i n i t a r g : a n g le ) ) ) th en th e generic function ra n g e m ay be defined w ith m ethods for each class: ( d e f g e n e r ic ra n g e ( o b j) ) (d efm eth o d ra n g e ((o b j p o i n t ) ) ( w i t h - s l o t s (x y) obj ( s q r t (+ (e x p t x 2) (e x p t y 2 ) ) ) ) ) (d efm eth o d ra n g e ((o b j p o l a r - p o i n t ) ) ( s l o t - v a l u e obj ’r ) ) thus: (ra n g e (m a k e -in s ta n c e ’p o in t :x 3 :y 4 )) =>5.0 (ra n g e (m a k e -in s ta n c e ’p o l a r - p o i n t : r 7 : a n g le 2 )) => 7 Unlike o th er object oriented system s such as Flavors in w hich th e first argu m ent signifies th e object for purposes of selecting th e m eth o d an d th e rem aining argum ents signify additional values available to co m putation, any CLOS p aram eter can be used to select th e m eth o d an d m ore th a n one p aram eter m ay be co n strain ed to determ ine th e applicable m ethod. SYNTHESIZED DYNAMIC ATTRIBUTE e v a lu a te ; w ould tra n sla te to: 54 (defgeneric evaluate (parse-node)) INHERITED DYNAMIC ATTRIBUTE call.frame ; w ould tra n sla te to: (defgeneric call-frame (parse-node)) (defmethod call-frame ((parse-node (eql nil))) nil) (defmethod call-frame ((parse-node parse-node)) ;look at terminal of parent formalism ) If an inherited a ttrib u te is requested of a nil par'se-node, nil is returned. If an in h erited a ttrib u te is requested of a a parse node for w hich there is no action (m ethod) th en th e p aren t form alism is consulted (th is m eans th a t requests for in h erited a ttrib u te s are passed u p w hen not handled by th e cu rren t form alism ). logicand IS cond( [logicand#sub, funcall( logical_operator.evaluate, logicand#sub.evaluate, relation.evaluate)], [t, relation.evaluate]) ; w ould tra n slate to: (defmethod evaluate (parse-node) (cond ((logicand#sub parse-node) (funcall (evaluate (logical-operator parse-node)) (evaluate (logical#sub parse-node)) (evaluate (relation parse-node)))) (t (evaluate (relation parse-node)))) References to static a ttrib u te s are tra n slate d as d a ta accesses to th e parse node. References to dynam ic a ttrib u te s are tra n slated as calls to th e generic function defined by th e a ttrib u te. 55 4.3 Closed Composition A lthough a form alism designer m ay ad d to th e dom ain library a t any tim e by creating new form alism s from scratch, th ere m ay exist situ atio n s w here w hat is needed an d desired of a form alism for a p a rtic u la r problem is sim ilar enough to one o r m ore existing form alism s. In th a t case, it w ould be desirable to sim ply to define th e new form alism by extension, fu sio n , or reduction of form alism s w hich already exist in th e dom ain library. In each case, a new form alism g ram m ar specification is defined in term s of one or m ore old form alism g ram m ar specifications. Form alism extension is th e ad d itio n of new features to an existing form alism . Usually, th e additional features are sm all relative to t'he en tire form alism so th a t th e problem of fittin g th e new features to th e old is easier th a n th e creation of a new form alism containing th e old an d add itio n al features from scratch. Form alism reduction is th e opposite of extension: it is th e rem oval of features from a form alism . R eduction is useful in an d of itself w hen a sim pler language is needed either for g reater efficiency or for constraining th e system s analyst in his selection of features. R eduction m ay also be used in conjunction w ith com posi tion in order to rem ove red u n d an t or conflicting features from a form alism before com posing it w ith an o th er to rem ove features which d o n ’t com pose well w ith the new ones. Form alism fusion is th e fusion of separately specified form alism s. N onterm inals of form alism s are shared as directed by equation statem en ts in th e new com posing form alism . A ssum ing th a t th e redundancies and conflicts are m anageable, syn tac tically, a com position m ay directly utilize th e com posed form alism s. If, however, th e com posed form alism s are red u n d an t or conflicting, th en th e com position for m alism m ay have to reduce th e com posed form alism s first. A dditionally, a new form alism m ay be defined by modification of an o th er for m alism . Form alism m odification is th e redefinition of features of a form alism to change th e m eaning of th e form alism . T h e m eth o d presented here, closed com position, is a generalization of exten sion, com position, and reduction. Closed com position form alism s use two addi tional g ram m ar features: use statem en ts an d equate statem en ts. A use statem en t 56 im p o rts th e p roductions of th e specified g ram m ar possibly rem oving certain pro ductions. N onterm inals of used form alism gram m ars are presum ed to be different. A n equate statem en t declares certain nonterm inals to be th e sam e overriding the presum ed difference. E ach of th e above m ethods is a special case of closed com position using those tw o features. T h e real problem w ith closed com position is th a t a naive approach creates syntactic am biguity w hich cannot be resolved except by significant restru ctu rin g of th e com posed form alism s. T h u s in no n triv ial instances, closed com position becom es as difficult as form alism design from scratch. It is n o t a useful tool for th e naive application designer b u t requires th e specialization of a form alism designer. 4 .3 .1 A p p lic a tio n s Closed com position is a m ethod for defining a new form alism out of previously de fined form alism s. A ssum ing th a t th e form alism s to be com posed are sem antically com patible a new form alism m ay be created by eith er m erging th eir syntax and sem antics o r by defining a new syntax w hich m ay be m ap p ed onto th e com posed form alism features. T h e m ost effective application of closed com position is in th e m odular design of large form alism s. T he syntax, alone, of a form alism like ADA is huge and com plex com prising som e six pages of tw o colum ns of productions in [Ada83]. T he associated sem antics, w hatever th e m eth o d of definition, is considerable. A n altern ativ e to a m onolithic description of a form alism is a m odular approach w herein several subform alism s are described and th en th e full form alism is defined as a com position of th e subform alism s. For exam ple, ADA can be broken into th e following p arts: declarations and types, nam es and expressions, statem en ts, subprogram s, packages, tasks, program stru ctu re, exceptions, generics, representation clauses, an d progm as in m uch the sam e way th a t th e ADA m anual is divided in to chapters. Each of these for m alism m odules could be fu rth er divided. For exam ple, statem en ts could be divided in to sim ple an d com plex statem en ts an d com plex statem en ts could be fu rth er divided in to loop statem en ts (including th e productions lo o p .s ta te m e n t, 57 ite r a tio n .s c h e m e , an d lo o p _ p a r a m e te r_ s p e c ific a tio n ) , case statem en ts (in cluding th e productions c a s e , s ta te m e n t an d c a s e , s ta te m e n t . a l t e r n a t i v e ) , etc. T hese groupings of sem antics, th en w ould be independently developed and defined. G enerally, any group of productions w hich, together, m ake relatively few refer ences to productions outside th e group are candidates for a subform alism m odule. T h e m ethodology of breaking a form alism dow n in to subform alism s is directly analogous to th e process of dividing a program into packages or m odules. C om position provides th e ability to com bine sep arately defined subform alism s in different ways (provided th e com binations are carefully planned). Such reuse has tw o advantages. F irst, form alism design is facilitated by th e inclusion of a previously defined subform alism . Second, form alism m aintenance, m odification, an d evolution is facilitated by m inim izing th e red u n d an cy th a t would exist if th e subform alism s w ere separately defined. T h e com position m echanism , as will be la te r described, p erm its paraphrase, orthophrase, an d metaphrase extension of form alism s. T his feature m ay be used to ad d new features or m ake changes to a form alism by defining a new form alism w hich w ould ad d th e necessary productions and a ttrib u tes. T h e com position m echanism m ay be used for form alism evolution, replacing an d extending th e sem antics of th e form alism as desired. However, th is is not advised for long term form alism m aintenance because th e increasing layers of evo lu tio n becom e ever m ore com plicated to u n d erstan d . A n altern ativ e is to use th e com position m echanism for p ro to ty p in g form alism changes an d to th en fold those changes into th e base form alism definition w hen th ey are accepted. 4 .3 .2 P r o c e d u r e A GRAMMAR specification m ay im p o rt th e nonterm inals of a previously defined form alism in to its definition. T h e definition of im p o rted nonterm inals m ay be ex ten d ed or changed. N onterm inals of different GRAMMAR specifications are unique by definition unless explicitly equated in w hich case th ey acquire each others def initions as syntactic alternatives. 58 As previously noted, a gram m ar consists of nonterm inals, term inals, w hich are defined by pro d u ctio n declarations and lexem e declarations. In order to m ake inter-gram m ar references, nonterm inals m ay be prefixed w ith th e nam e of th e g ram m ar w hich contains th e nonterm inal. Tw o ad d itio n al decla ratio n s, th e use declaration and th e equate declaration, are used to m anage in ter g ram m ar references. T h e no n term in al prefix is sim ply th e nam e of th e g ram m ar w hich contains th e nonterm inal. For exam ple: e x p :e x p re s sio n is th e e x p re s s io n nonterm inal of th e g ram m ar for th e EXP form alism . By de fau lt, nonterm inals w ith no prefix are of th e g ram m ar in w hich they are contained so th a t a reference to e x p re ss io n in th e g ram m ar of EXP is to a reference to e x p : e x p re ssio n . T h e use declaration identifies a g ram m ar whose nonterm inals m ay th en be referenced by th e current gram m ar. For exam ple, th e declaration: USE exp ; in th e g ram m ar definition of EXP FULL w ould allow the EXP FULL g ram m ar access to th e nonterm inals of EXP. A use declaration m ay explicitly d ro p certain n o n ter m inals (an d th eir productions) or explicitly include only p artic u la r nonterm inals. For exam ple, th e declaration: USE e x p _ fu ll WITHOUT b in d in g _ e x p re ssio n ; w ould drop th e nonterm inal e x p . f u l l :b in d in g _ e x p re s s io n and include all other nonterm inals (and th eir productions). Conversely, th e declaration: USE e x p _ fu ll WITH id e n tifie r _ s e q u e n c e , i d e n t i f i e r ; w ould include only th e nonterm inals id e n tif ie r _ s e q u e n c e and i d e n t i f i e r and w ould drop all others. T h e eq u ate declaration identifies tw o or m ore nonterm inals, usually from dif ferent gram m ars, w hich are to be considered th e sam e nonterm inal. W hen no n ter m inals are equated, a reference to one of th e equated nonterm inals is a reference to all of th e nonterm inals. For exam ple, th e declaration: 59 E Q U A T E ex p ressio n , exp :exp ression ; in th e g ram m ar definition of EXP FULL w ould cause all reference to th e nonterm inal e x p _ f u l l : e x p r e s s io n to also be reference to th e nonterm inal e x p : e x p re s s io n an d vice versa. A pro d u ctio n w ith th e nonterm inal e x p _ f u l l : e x p r e s s io n on th e rig h t h an d side could be expanded w ith eith er ex p _ f n i l : e x p r e s s io n or e x p :e x p re s s io n . N onterm inal equation is transitive. 4 .3 .3 M e th o d s C om position m ay be used to define a form alism by extension. In extension a new form alism is created by using a single existing form alism an d adding features to th e existing form alism . For exam ple: a form alism designer m ay define EXP FULL as an extension of EXP. EXP g ram m ar is defined in Section 4.1.2. EXP FULL gram m ar: GRAMMAR exp.full IS USE exp ; START expression ; expression IS binding.expression ; binding.expression IS "[" [object.binding.sequence] [function.binding.sequence] "I" expression "]" ; object_binding_sequence IS [object_binding_sequence] object.binding ; object.binding IS identifier expression ";" ; function.binding.sequence IS [function.binding.sequence] function.binding ; function.binding IS identifier "(" [identifier.sequence] ")" "=" expression " ; identifier.sequence IS [identifier.sequence identifier ; EQUATE expression, exp:expression ; END exp.full ; T h e form alism EXP FULL is an o rth o p h rase extension of EXP w hich adds to it th e definition of a binding expression as an o th er form of prim ary. T h e extension 60 is n o t a p arap h rase extension because binding expressions is not m ap p ed into EXP expressions. T h e extension is n o t a m etap h rase extension of EXP because all substrings in EXP have th e sam e sem antics in EXP FULL. A reduction is a form alism extension w herein certain productions an d th eir associated a ttrib u te definitions are dropped (not included in th e new form alism ). W hen a rig h t h an d no n term in al of a p ro d u ctio n has been dropped, th e alternative in w hich th e no n term in al occurs is no longer a valid alternative. A dditionally, pro d u ctio n s w ith nonterm inals on th e left h an d side w hich can no longer can be reached from th e sta rt sym bol will be dropped. For exam ple, a form alism designer m ay also define EXP 2 as a reduction of EXP FULL by rem oving th e binding expression p ro d u ctio n (w hich indirectly rem oves the binding sequence an d binding productions since th ey are n o t reachable w ithout binding expression. EXP 2 gram m ar: GRAMMAR exp_2 IS USE exp_full WITHOUT binding.expression ; START exp.full .-expression ; END exp_2 ; T his definition w ould be valid w hether EXP FULL was defined as an extension of EXP, or as a full equivalent definition on its own. Since all th e nonterm inals a n d p roductions of EXP FULL outside of EXP can no longer be reached, they are dropped. Fusion is th e com position of m ultiple form alism s. For exam ple, a form al ism designer m ay define GROG as a fusion of EXP, as previously defined, and th e g ram m ars defined below: STMT is a form alism describing sim ple sta te m ents: i f . s t a t e m e n t , lo o p .s ta te m e n t, e x i t .s t a t e m e n t , r e t u r n .s t a t e m e n t , an d p r o c e d u r e .in v o c a tio n . Unlike EXP, STMT is not syntactically self-contained. STMT refers to e x p re s s io n , e x p r e s s io n .s e q u e n c e , an d o b j e c t . i d e n t i f i e r w hich, of course, w ere defined in EXP. T herefore, each of these is given stu b declarations. STMT gram m ar: GRAMMAR stmt IS expression ; 61 expression.sequence ; object.identifier ; statement.sequence IS [statement.sequence] statement ; statement IS assignment.statement I if.statement I loop.statement I exit.statement I return.statement I procedure.invocation ; assignment.statement IS object.identifier expression ; if.statement IS "IF" expression "THEN" st at ement _ s equence ["ELSE" statement.sequence#else] "END" "IF" ; loop.statement IS "LOOP" statement.sequence "END" "LOOP" ";" ; exit.statement IS "EXIT" ; return.statement IS "RETURN" expression ; procedure.invocation IS identifier ["(" expression.sequence ")"] ";" ; END stmt ; DECL is a form alism describing declarations. A gain, it includes several stub declarations of nonterm inals which are used in the definition of DECL. DECL gram m ar: GRAMMAR decl IS statement.sequence ; expression ; subprogram.declaration IS function.declaration I procedure.declaration ; function.declaration IS "FUNCTION" identifier formal.parameter.part "IS" declaration.part "BEGIN" statement.sequence 62 "END" identifier#again »;" ; procedure_declaration IS "PROCEDURE" identifier formal.parameter.part "IS" declaration_part "BEGIN" statement.sequence "END" identifier#again ";" ; formal_parameter_part IS ["(" formal_parameter_sequence ")"] ; formal.parameter.sequence IS [formal_parameter_sequence identifier ; declaration.part IS [obj ect.declaration.sequence] [subprogram_declaration_sequence] ; object_declaration_sequence IS [object.declaration.sequence] object.declaration ; object.declaration IS identifier expression] ";" ; subprogram.declaration.sequence IS [subprogram.declaration.sequence] ’subprogram.declaration ; END decl ; T he GRAMMAR specification of GROG is sim ply th e fusion of EXP, STMT, and DECL. GROG gram m ar: GRAMMAR grog IS USE exp ; USE stmt ; USE decl ; EQUATE exp:expression, stmt:expression, decl:expression ; EQUATE exp:expression.sequence, stmt:expression.sequence ; EQUATE exp:obj ect _ ident if i er, stmt:object.identifier ; EQUATE stmt:statement.sequence, decl:statement.sequence ; 63 START subprogram.declaration ; END grog ; GROG combines the used formalisms by the equation of the obvious nonterm i nals from the respective formalisms. M odification allows u n p lan n ed changes to a form alism definition. A nonterm i n al of a subform alism m ay be redefined b u t a nonterm inal w hich has been redefined in th e GRAMMAR specification m ust be given a new definition in th e ATTRIBUTE ACTION SET specification. For exam ple, generalized assignm ent such as th a t of th e LISP setf m ay be added to GROG by a m etap h rase extension of GROG called GROG X w hich redefines th e a ssig n m e n t.sta te m e n t. GROG X gram m ar: GRAMMAR grog.x IS USE grog ; START subprogram.declaration ; stmt:assignment_statement IS stmt:expression#left ":=" stmt:expression#right ; END grog_x ; N ote th a t th e corresponding sem antics w ould also require a new definition for s tm t : a s s ig n m e n t.s ta te m e n t. 4 .3 .4 Im p le m e n ta tio n Closed com position is th e definition of a com posing form alism in term s of opera tions upon th e com posed form alism s. Syntactically, th e sim plest im plem entation m erely m anipulates th e g ram m ars of th e com posed form alism s as directed by th e com position form alism to produce a full com posing g ram m ar w hich is th en tre ated as any o th er gram m ar. A n altern ativ e is to increm entally co n stru ct th e syntactic tools such as th e p arser.4 Sem antically, given an unam biguous gram m ar as a resu lt of com position, th e sem antic a ttrib u te s and th eir associated actions m ay be chosen in exactly th e sam e m an n er as w ith a sim ple form alism . O f course, th e trick is to rem ove th e syntactic increm ental parser construction has been researched by [Hor88] but is not pursued in this thesis. 64 am biguities. If th ere are no syntactic am biguities in th e com posed form alism , the objects, generic functions, and m ethods, of th e respective form alism s com posed m ay sim ply be throw n together. 4.4 Summary Form alism design involves th e design of form alism syntax, form alism sem antics, a n d possibly, th e closed com position of previously defined form alism s. Form alism syntax is defined by a g ram m ar w hich generates a p arser for th e form alism . For m alism sem antics are defined by a ttrib u te action sets w hich m odel b o th tra n slato rs an d in terp reters. Closed com position creates new form alism s out of previously de fined form alism s. B u t am biguity rem ains a m ajo r sem antic problem w hich m ust be resolved by careful elim ination an d m odification of conflicting syntactic form s. 65 Chapter 5 Open Composition O pen com position is a m eth o d of com posing form alism s d u rin g th e application design activity ra th e r th a n during th e form alism design activity as was th e case w ith closed com position. O pen com position obviates th e need to create interm e diary com posing form alism s. Instead, th e application designer directly composes different form alism s w ithin th e specification of a p artic u la r application. 5.1 Applications O pen com position is essential in m ulti-form alism specification environm ents w ith eith er a large dom ain lib rary o r a continually expanding one. M ore precisely, if th e ratio of form alism s available to form alism s used in p a rtic u la r system s is large, th en closed com position will be burdensom e requiring order (2n) com positions, w here n is th e num ber of uncom posed, prim itive form alism s, if th e com positions are to precisely fit th e applications for w hich they are intended. If th e dom ain lib rary is continually expanding, u n d er closed com position each new form alism will require th e creation o f order(2n_1) new com positions. Since closed com position o f form alism s is often as difficult as th e design o f a form alism from scratch, th e overhead is unacceptable. O pen com position allows th e form alism designer to continually ad d new for m alism s to th e form alism d atab ase an d requires only th a t these form alism s be tied to one o r m ore interfaces an d to occasionally define of new interfaces. T hus, in an environm ent of large or expanding form alism d atab ases, open com position is the preferred m eth o d of com position. 66 5.2 Related Work Interface D escription Language (ID L), as described in C h ap ter 2, is a m odel for interfacing m odules of different languages. However, while IDL placed th e burden on th e m atin g m odules of different form alism s on th e w riter of th e m odule (th e application designer), our approach is to place th e b u rd en on th e form alism de signer. ID L provided a single m odel in term s of which th e d a ta stru ctu res shared betw een application com ponents w ould be w ritten . O ur interfaces, on th e o ther h an d , allow th e design of a rb itra ry m odels in term s of th e sam e sem antic defi n ition facilities available for defining form alism s them selves so th a t by th e tim e th e application com ponents are w ritten , th e interfacing m echanism s are as hidden as sem antic concepts of th e form alism s, them selves. Interfaces are w ritten first, an d th e form alism s second w hereas th e IDL m odel is superim posed over exist ing program m ing languages w hich som etim es required ID L d a ta stru ctu res to be converted into ascii strings to be shared betw een m odules of different languages. T his ordering b o th solves th e problem s of form alism definition com patability and allows a m ore a rb itra ry com position of form alism s. T h e m ethodology of interfacing form alism s draw s from th e concept of open system s in th e sense th a t they share th e objective of localized inform ation and system extensibility and flexibility. T h e correspondence betw een th is approach to form alism interfacing an d open system s can be seen m ore clearly in term s of o bject system s. C om m on Lisp O bject System (CLO S) is chosen as th e base of im plem entation of interfaces an d form alism s essentially because of its open system characteristic. As previously described in Section 4.2.4, a ttrib u te action sets are defined in term s of CLOS. T he interface serves to define an ab stra ct n o n term in al class which som e form alism s will use to define th eir nonterm inals and w hich oth er form alism s will use to an ticip ate th e a ttrib u te s of sh ared nonterm inals. T h e interface also serves to define th e generic functions underlying th e attrib u tes. 5.3 Interfaces T h e key to open com position is th e interface. A n interface is an encapsulation of sem antic concepts w hich are to be shared betw een form alism s. 67 T he process of dom ain form alism design (and, hence, th e process of a ttrib u te creation) is ongoing. If it were th e case th a t th e nu m b er of form alism s were fixed, th e n th e a ttrib u te s th a t were intended to be shared w ould be know n to all form alism s an d these could all be used by all form alism s. However, since each form alism m ay find itself interactin g w ith form alism s which were created later, eith er using or providing pieces of code, th ere m ust be a facility for lim iting th e scope of interaction. A dditionally, lim iting th e scope of in teractio n betw een for m alism s facilitates th e m odularization of softw are although it lim its interaction. Therefore, form alism s m ust have som e m eth o d of fixing th e a ttrib u te s th a t they m u st supply an d w hich they m ay use in sharing parse nodes betw een form alism s. Interfaces provide a specific an d finite facility for sharing. New form alism s m ust in teract w ith older form alism s th ro u g h form alism s interfaces w hich th e old for m alism already uses. T h e new form alism m ay create new a ttrib u te s an d m ay use new interfaces b u t it m ay n o t use these in in teractin g w ith th e old form alism . T h e overall objective of an interface is to define sem antic concepts w hich will be shared by form alism s w hich use th e interface. Form alism s will explicitly use specific interfaces and, thereby, have access to th e sem antic concepts of th e in terface. However, th e interface will only list th e sem antic concepts in th e m ost general w ay leaving th e form alism to exactly specify th e definition of sem antic concepts. Sem antic concepts are m odelled by th e following declarations, described in m ore d etail later: nonterm inals, no n term in al types, a ttrib u te s of nonterm inals, and d a ta types an d objects are used to m odel sem antic concepts. T h e sharing of interfaces is th e basic m ethod of inter-form alism interaction. Interfaces con ta in attribute declarations, nonterm inal types, and global declarations. A ttrib u te declarations identify a ttrib u te s which are sh ared by all form alism s w hich use the interface. N onterm inal types define ab stra ct nonterm inals to which n o nterm inals of for m alism s are associated. A ssociated w ith nonterm inal types in an interface are subsets of th e a ttrib u te s of th e interface. W hen a nonterm inal of a form alism is associated w ith a n o n term in al ty p e of an interface, th e no n term in al m u st provide actions (m ethods) for th e a ttrib u te s associated w ith th e nonterm inal type. G lobal 68 declarations are also provided in interfaces prim arily for th e purpose of describ ing d a ta stru ctu res which will contain p arse nodes shared betw een com ponents of different form alism s. For exam ple, in th e interface DATABASE INTERFACE described later, a ttrib u te s are declared to m odel operations on relations, such as insert a n d retrieve; a non term in al ty p e is declared to m odel relation declarations w hich m ay be shared be tw een form alism s; an d a tab le is declared w hich will hold th e relatio n nonterm inals shared. 5.3.1 A ttr ib u te s Since no n term in al types refer to specific a ttrib u te s an d since form alism s w hich use th e n o n term in al types m ust be guaran teed to be using th e sam e a ttrib u te (and using it in th e sam e w ay), some characteristics of a ttrib u te s are specified in th e interface such as th e class of th e a ttrib u te in w hat are called attribute declarations. A dditionally, an interface m ay specify th a t an a ttrib u te retu rn s a p articu la r type w hich is defined in th e interface although in th e cu rren t im plem entation, th e typing of a ttrib u te s is inform al. In o rd er to share a ttrib u te s across form alism s, a ttrib u te declarations are in serted into th e interface w hich is used by th e form alism s w hich are to share th e a ttrib u te s. A ttrib u te declarations of an intrface declare w hich a ttrib u te s w hich m ay be shared by form alism s th a t use th e interface an d w hich m ay be used in the definition of nonterm inal types. T he form of an a t t r i b u t e _ d e c l a r a t i o n is: attribute„declaration IS (“SYNTHESIZED" I "INHERITED") (“STATIC" I “DYNAMIC") "ATTRIBUTE" identifier [body] ";" ; A n a t t r i b u t e _ d e c l a r a t i o n in an interface will have no body. For exam ple DATABASE INTERFACE is used as an interface by DDL an d DML (see A ppendix G ). T h e DATABASE INTERFACE contains th e following: INHERITED DYNAMIC ATTRIBUTE relate_frame ; SYNTHESIZED DYNAMIC ATTRIBUTE assert ; 69 SYNTHESIZED DYNAMIC ATTRIBUTE retract ; SYNTHESIZED DYNAMIC ATTRIBUTE test ; SYNTHESIZED DYNAMIC ATTRIBUTE generate ; These a ttrib u te s becom e shared by each form alism w hich uses th e DATABASE IN TERFACE. 5 .3 .2 N o n te r m in a l T y p e s N onterm inal types define an u ltra -a b stra c t g ram m ar of nonterm inals w hich are associated w ith a p artic u la r set of a ttrib u te s. N onterm inal types identify w hat a ttrib u te s are required of an d available from such nonterm inals. W hen a non term in al of a form alism is associated w ith a n o n term in al type of an interface the form alism m u st define, and is g u aranteed to provide, actions on th e nonterm inal for each of th e a ttrib u te s of th e nonterm inal type. An interface is specified by an a ttrib u te action set like a form alism . However, unlike a form alism it has no associated concrete syntax. F urtherm ore, attrib u te s w hich are declared have no actions associated w ith th e interface. Instead, in ter faces contain declarative inform ation w hich is used by form alism s w hich use the interface an d th e form alism s th a t use th e interface define th e actions. In o rd er for one form alism to use a no n term in al of an o th er form alism it m ust have som e inform ation ab o u t th e a ttrib u te s of th e nonterm inal. N onterm inal types essentially define a m inim al set of a ttrib u te s w hich any nonterm inal classified as th e ty p e is g u aran teed to have. T his allows th e designer of a form alism to antic ip ate th e a ttrib u te s of a nonterm inal w hich is consum ed from an o th er form alism even if the other form alism has not been defined yet, as will frequently be the case. W hen th e o th er form alism is defined, any nonterm inals w hich it produces m ust provide th e m inim al a ttrib u te s of th e n o n term in al types by w hich they are classified. T h u s w hen a nonterm inal is sh ared betw een tw o form alism s, produced by one and consum ed by an o th er, th e interface an d th e nonterm inal types of th e interface exactly determ ine w hat a ttrib u te s o f th e n o n term in al th e consum er can access an d th e producer m ust provide. A no n term in al ty p e declaration is of th e form : nonterminal_type_declaration IS 70 "NONTERMINAL" "TYPE" identifier "IS" identifier.sequence ; identifier.sequence IS [identifier_sequence ","] identifier ; w here th e identifier sequence is a list of nam es of a ttrib u te s. For exam ple, th e a ttrib u te action set of DATABASE INTERFACE contains the following no n term in al type: NONTERMINAL TYPE relation IS relate.frame, assert, retract, test, generate ; w hich defines a n o n term in al type r e l a t i o n w ith five a ttrib u te s. 5 .3 .3 G lo b a l D e c la r a tio n s G lobal declarations in interfaces are used to describe tables w hich will be used to share p arse nodes betw een m odules of form alism s. A n interface m ay declare a tab le in to w hich m odules of form alism s w hich use th e interface m ay insert parse nodes. O th er m odules of form alism s which also use th e interface m ay th en access th e inserted parse nodes. A dditionally, global declarations in an interface are a catch-all for th e residual sem antic concepts not adequately m odeled by nonterm i n al types and a ttrib u te declarations. Since interface are defined before form alism s w hich use th em , form alism s m ay freely utilize global d eclarations in th e interface. For exam ple, a global declaration m ight define a C om m on Lisp defstruct and allow form alism s w hich use th e interface to m an ip u late an d pass aro u n d instances of the stru c tu re an d to use th e access functions provided. In this sense, interfaces estab lish a sta n d a rd for com m unication betw een application com ponents in different form alism s w hich use th e interface. O nly p arse nodes of a no n term in al w hich has been associated w ith a nonterm i nal type of th e interface m ay be shared betw een form alism s (otherw ise, there is no way for one form alism s to know w hat a ttrib u te s a n o th er form alism s has provided for th e n onterm inal). T h e form alism s w hich use th e interface will th en place parse nodes into th e d a ta stru ctu re and call for a ttrib u te s of th e parse nodes. A com m on global declaration in an interface is a variable declaration such as a h ash table. For exam ple, in th e DATABASE INTERFACE, a global variable containing a hash table, is used to store relation nonterm inals h ash ed by th eir nam e. 71 defvarCrelation.table, make.hash.tableO) ; — hash table of nonterminal type relation In DDL th e d e c la r e a ttrib u te on th e r e l a t i o n _ d e c l a r a t i o n nonterm inal stores th e parse node in to th e r e l a t i o n . t a b l e using th e n am e of th e relation as th e key during th e static pass over th e m odule in p rep aratio n for dynam ic com putation: SYNTHESIZED STATIC ATTRIBUTE declare IS relation.declaration IS setf(gethash(identifier.declare,relation_table), relation.declaration) ; END declare ; T h e assert .statement no n term in al of th e execute a ttrib u te is defined for dynam ic com putation: SYNTHESIZED DYNAMIC ATTRIBUTE execute IS assert.statement IS when(parameter.expression.sequence, parameter.expression.sequence.execute), gethash(identifier.symbol,relation_table).assert ; END execute ; W hen evaluated, it causes th e evaluation of th e a s s e r t a ttrib u te of th e r e l a t i o n n o n term in al ob tain ed from th e r e l a t i o n . t a b l e by hashing o n th e i d e n t i f i e r of th e a s s e r t .s t a t e m e n t . W hile d a ta stru ctu res for containing an d sharing nonterm inals m ay be m ore com plex, w ith o th er associated inform ation, th e essential m echanism of attrib u tes, n o n term in al types, nonterm inals, an d p arse nodes is th e sam e. G lobal declarations are also necessary in interfaces because passing values be tw een form alism s will necessarily en tail ad d itio n al shared co n stru cts such as access functions an d shared variables to contain parse tree stru ctu res. In o rd er to share functions an d variables betw een form alism s global declarations m ay be included in th e form alism s interface. G lobal declarations of an interface m ay be shared by form alism s w hich use th e interface. 72 For exam ple, d a ta shared betw een form alism s m ay be defined in one of four ways: 1. by th e underlying in te rp re te r/tra n sla to r im plem entation language: prim itive types such as strings m ay be shared freely betw een form alism s 2. by declaration in th e interface: an object type m ay be defined in th e interface an d shared w ith o th er interfaces; 3. by declaration in th e form alism s: an object type concept m ay b e defined in th e interface and th en an instance m ay be defined in a form alism ; 4. by declaration in th e m odules: an object type concept m ay be in stan tiated in th e specification an d shared; Usually, rep resen tatio n will be determ ined by som e com bination of th e above. For exam ple, th e underlying im plem entation, Lisp, has record stru ctu res th a t m ay be used to represent d a ta types defined in an interface. T hese d a ta types could allow variations defined in th e th e form alism to allow variations to be defined in th e m odules, them selves. T his m eth o d works because th e direction of v ariation con stra in t is th e sam e as th e direction of developm ent: underlying language, interface, form alism , m odule; m odule d a ta stru c tu re types are defined in term s of form alism d a ta stru ctu re types which are defined in term s of interface d a ta stru ctu re types w hich are defined in term s of underlying im plem entation language d a ta stru ctu re types. 5*3.4 U sin g In terfa ces H aving defined interfaces, th e next step is to use th em in th e definition of a form alism . A form alism explicitly declares th a t it will use specific interfaces. T he n o n term in al types, a ttrib u te declarations, and global declarations of th e interface th en becom e available for use in th e a ttrib u te action set of th e form alism . T he form of a u s e _ d e c la r a tio n is: use_declaration IS "USE" identifier " ; 73 w here identifier is th e nam e of an interface. For exam ple, th e a ttrib u te action set of DDL declares: USE relation_interface ; A form alism w hich is declared to use an interface m ay classify certain non term in als as instances of nonterm inal types of th e interface. Such declarations allow th e sharing of nonterm inals betw een form alism s w hich otherw ise have no know ledge of one another. A form alism m ay provide a ttrib u te s for a n o n term in al beyond those required by a no n term in al type b u t these m ay only be used w ithin th e form alism . T h e form of a n o n te r m in a l.d e c la r a tio n is: nonterminal.declaration IS "NONTERMINAL" identifier "IS" identifier#type ; w here i d e n t i f i e r is th e nam e of a n o n term in al defined in th e g ram m ar of th e form alism an d i d e n t i f i e r t t y p e is th e nam e of a no n term in al ty p e defined in an interface used by th e a ttrib u te action set of th e form alism . T h e a ttrib u te action set of DDL declares: NONTERMINAL relation_declaration IS relation ; w hich is a prom ise to provide actions for th e five a ttrib u te s of th e interface on th e nonterm inal r e l a t i o n . d e c l a r a t i o n of DDL. T h e DDL form alism m ay place r e l a t i o n . d e c l a r a t i o n p arse nodes (w hich are now also r e l a t i o n parse nodes) into d a ta stru ctu res in DATABASE INTERFACE from w hich o th er form alism s such as DML m ay access these p arse nodes as r e l a t io n s . A ttrib u tes declared in th e a ttrib u te action set of th e form alism and of interfaces used by th e form alism w hich have th e sam e nam e are, in fact, th e sam e a ttrib u te . T hus, actions m ay b e added to an a ttrib u te of an interface on specific nonterm inals sim ply by nam ing th e attrib u te . For exam ple, th e interface DATABASE INTERFACE declares th e a ttrib u te a s s e r t. T h e form alism DML th en declares: SYNTHESIZED DYNAMIC ATTRIBUTE assert IS relation.declaration IS 74 setf(relate_frame.object(relation.declaration.frame), gethash(identifier.declare,relation.obj ect.table)), setf(relate.frame.values(relation.declaration.frame), relate.frame.values (relation.declaration. relate.frame) ) , cond( [relation.definition, relation.definition.assert], ct, gethashOuser: : base, implement at ion.t able) .assert] ) ; END assert ; W hen th e nonterm inal r e l a t i o n . d e c l a r a t i o n is p roduced an d used by another form alism , th a t o ther form alism will a t som e p oint reference th e a s s e r t a t trib u te of th e nonterm inal. T his definition and th a t reference axe to th e sam e a ttrib u te because th e a ttrib u te was defined in a com m on interface (and because r e l a t i o n . d e c l a r a t i o n was ty p ed as a r e l a t i o n an d because r e l a t i o n was de fined to have th e a ttrib u te a s s e r t ) . 5 .3 .5 P r o d u c e r /C o n s u m e r R e la tio n sh ip s T h e sharing of p arse nodes betw een form alism s th ro u g h interfaces m ay be viewed as a p ro d u cer/co n su m er relationship. However, since form alism s define only object ty p e classes an d operations on those classes, th e p ro d u cer/co n su m er relationship is a ra th e r com plex. G iven an interface Q, two form alism s A an d B which b o th use Q a n d tw o m odules x .a and y .b in form alism s A an d B respectively, a producer relationship m ay exist betw een th e form alism s or th e m odules. Interface Q defines certain ab stra ct nonterm inal types an d req u ired /ex p ected a ttrib u te s of th e nonterm inal types. Form alism A m ay be a p ro d u cer of nonterm i nals an d actions for a ttrib u te s of nonterm inals from th e interface by classifying one of its nonterm inals as a nonterm inal type of th e interface an d defining a ttrib u te actions on th a t nonterm inal. Form alism B m ay be a consum er by referring, in its own a ttrib u te actions, to a ttrib u te s of nonterm inals o b tain ed from d a ta stru ctu res of th e interface. T h e p ro d u cer/co n su m er relationship betw een A and B, however, is entirely theoretical an d exists only th ro u g h th e interface Q. In p artic u la r, there is no 75 reason to expect th e form alism s ever to be used together in a m ulti-form alism specification or, if they are b o th used in th e sam e specification, to actu ally produce an d consum e respectively. T he p ro d u cer/co n su m er relationship betw een A an d B th ro u g h Q m erely defines a pipeline th ro u g h w hich m aterial m ay o r m ay n o t flow depending u p o n w h at m odules w ritten in A an d B do. In order for th ere to actually be p ro d u ctio n /co n su m p tio n , th e m odules of the m ulti-form alism specification m ust actually produce and consum e p arse nodes of th e no n term in al previously discussed. It m ay be th e case th a t m odule x_a never in serts any p arse nodes in to th e global d a ta stru ctu res defined in th e interface if th e syntactic nonterm inal associated w ith th e no n term in al type never occurs in th e p a rtic u la r specification. Sim ilarly, x_b m ight never actually reference th e global d a ta stru ctu res. However, if x _ a does, in fact, produces a parse node by p u ttin g it in to th e global d a ta stru ctu res of th e interface w hich x_b th en consum es then th e p o ten tial p ro d u cer/co n su m er relationship of th e form alism s A an d B will have been fulfilled. For exam ple, DATABASE INTERFACE is used by DDL a form alism w hich describes th e declaration of relations and DML a form alism w hich describes d atab ase m anip ulation. DATABASE INTERFACE also defines th e global variable r e l a t i o n . t a b l e w hich is a hash tab le of r e l a t i o n p arse nodes. T he m odule ml declares two relations an d m2 describes some operations on those relations. T h e interface DATABASE INTERFACE defines a nonterm inal ty p e r e l a t i o n w hich DDL produces by m atch in g its r e l a t i o n . d e c l a r a t i o n to it an d p u ttin g r e l a t i o n . d e c l a r a t i o n s in to th e r e l a t i o n . t a b l e . DDL th en defines th e required a ttrib u te s on th e non term in al r e l a t i o n . d e c l a r a t i o n . Conversely, th e form alism DML, w hich also uses DATABASE INTERFACE, consum es th e no n term in al r e l a t i o n by referenc ing r e l a t i o n . t a b l e . A dditionally, th e m odule ml produces a p a rtic u la r relation p e rs o n w hich is inserted into th e r e l a t i o n . t a b l e as previously described. Con versely, th e m odule m2 consumes th e relation p e rso n by accessing it from th e r e l a t i o n . t a b l e . 76 5 .3 .6 C o m m u n ica tio n B e tw e e n F orm alism s In a very real sense, interfaces axe used to allow different m odules of different form alism s to com m unicate w ith one another. G iven th a t th e producer supplies b o th th e p arse node an d th e action perform ed by th e p arse node, th e facility for com m unication is n o t in th e sharing of th e p arse node b u t on th e operations on th e paxse node. T here axe four basic m ethods of com m unication betw een m odules of different form alism s: 1. a ttrib u te reference: a consum er m odule can o b tain a value from a producer m odule sim ply by requesting th e a ttrib u te of a paxse node w hich it supplies; 2. in h erited dynam ic a ttrib u te value: th e consum er sets one or m ore inherited dynam ic a ttrib u te s (defined in a shared interface) an d th en invokes a syn thesized dynam ic a ttrib u te ; th e producer of th e paxse node, th en , com putes th e value of th e a ttrib u te w ith access to th e in h erited a ttrib u te s supplied by th e consum er; 3. m u tu al exchange of parse nodes: two m odules can tra d e inform ation by accessing each others p arse nodes th ro u g h an interface d a ta stru ctu re; 4. side effect on global variables: m odules m ay affect global variables in in ter faces w hich th eir respective form alism s share. If an a ttrib u te is declared in an interface th e n form alism s w hich use th e in terface m ay nam e th e a ttrib u te . In order to get a node w ith th a t a ttrib u te , th e form alism has to refer to a tab le declared in th e interface. 5.4 Modular Composition M odular com position is distinguished from recursive com position by th e m o d u lar ization of sy ntactic u n its of th e specification. In recursive com position, a specifi cation is m ore or less free to sw itch form alism s w ith in lexical scope. In m odular com position, lexical scope is kept w ithin a single form alism . However, like recur sive com position, dynam ic scope m ay sw itch form alism s. In o th er words, recur sive com position m ixes b o th static an d dynam ic sem antics of form alism s w hereas 77 1, F igure 5.1: M odular C om position P arse Trees m o d u lar com position m ixes only dynam ic sem antics alth o u g h it has access to the results of static execution of o th er m odules. A module is a com plete string in a p a rticu lar single form alism . A m odular com position m ulti-form alism specification consists of one or m ore m odules. Each m odule m ust be w ithin a single form alism b u t different m odules o f th e sam e spec ification m ay be in different form alism s. M odules in teract w ith one an o th er th ro u g h inter-form alism references (see fig ure m odular-com position-parse-tree). In th e diagram , th e m odules ml, m2, m3, and m4 are each in different form alism s as indicated by th e shape of th e parse nodes. T h e arrow s represent inter-m odule references th ro u g h th e single interface, i l . For exam ple, in a tra d itio n a l program m ing language, a procedure declared in one m odule m ay be invoked from an o th er m odule even if th e m odules are in different form alism s. T h e co n strain t on such inter-form alism references is defined by interfaces. O nly typed nonterm inals m ay be sh ared betw een form alism s and only th e a ttrib u te s of th e types m ay be referenced outside th e m odule of th e parse node. 78 5.4.1 E x a m p le A client wishes to p rin t graphic pie an d b a r charts from d a ta he has collected ab o u t people’s education and incom e. T h ree interfaces have been defined by th e dom ain designer an d are contained in th e dom ain library: • STANDARD INTERFACE is an interface of p ro c e d u re _ d e c la ra tio n s and f u n c tio n _ d e c la r a tio n s w ith execution and evaluation operations. • DATABASE INTERFACE is an interface of r e l a t io n _ d e c la r a t io n s w ith query, u p d ate, an d generate operations. • DEVICE INTERFACE is an interface of d e v ic e _ d e c la r a tio n s w ith graphic operations. A m ong th e form alism s w hich th e dom ain designer has previously provided in th e dom ain lib rary are: • DDL is a form alism for defining relational datab ases w hich p ro duces r e l a t io n _ d e c l a r a t i o n s for DATABASE INTERFACE an d consum es p r o c e d u re _ d e c la ra tio n s an d f u n c tio n _ d e c la r a tio n s from STANDARD INTERFACE. • DML is a relational d a ta m an ip u latio n form alism w hich produces p r o c e d u re _ d e c la ra tio n s and f u n c t io n .d e c l a r a t i o n s for STANDARD IN TERFACE and consum es r e l a t io n _ d e c l a r a t i o n s from DATABASE INTER FACE. • STAT is a statistics calculation form alism w hich b o th produces and con sum es p r o c e d u re _ d e c la ra tio n s an d f u n c tio n _ d e c la r a tio n s from and for STANDARD INTERFACE. T h e STAT c r o s s ta b _ d e c la r a tio n s and r e g r e s s io n _ d e c la r a tio n s and th e i n i t .. d e c l a r a t i o n are tre a te d as f u n c tio n _ d e c la r a tio n s an d p ro c e d u re _ d e c la ra tio n s , respectively, for purposes of interfacing th ro u g h STANDARD INTERFACE. • GRAPH is a graphics generation language w hich produces p r o c e d u r e .d e c la r a tio n s an d f u n c t io n .d e c l a r a t i o n s for STANDARD IN TERFACE consum ing d e v ic e _ d e c la r a tio n s from DEVICE INTERFACE. T he 79 GRAPH g ra p h .d e c la ra tio n s are treated as p ro c e d u re .d e c la ra tio n s for purposes of interfacing through STANDARD INTERFACE. • DEVICE is a graphics device description language w hich produces d e v ic e _ d e c la ra tio n s for DEVICE INTERFACE. • GROG: a general purpose program m ing language. M odules use and define p ro c e d u re s an d f u n c tio n s from and for STANDARD INTERFACE. T he system ’s designer w rites a specification to solve th e problem w hich th e client has presented in six m odules using th e above form alism s from th e dom ain library. M odule ml in form alism DDL: DDL ml IS RELATION person (name:string, education:integer, income:real) ; RELATION education (education:integer) :* PROJECT person (education) ; RELATION income (education:integer, income:real) := PROJECT person (education, income) ; END ml ; declares th re e relations: p e rso n , e d u c a tio n , an d incom e, th e second two as p ro jections on th e first. N otice th a t DDL is a very sim ple language used only to describe relatio n al schem a. M odule m2 in form alism DML: DML m2 IS PROCEDURE nev_person (name, education, income) := ++ person (name, education, income) ; FUNCTION education.enumeration :« LISTOF education ; FUNCTION income.enumeration := LISTOF income ; 80 END m2 ; defines a procedure new _person to add persons to th e relation p e rso n , an d two functions e d u c a tio n _ e n u m e ra tio n an d in c o m e .e n u m e ra tio n for obtaining the tuples of th e pro jected relations. N otice, th e relations are p a rt of a global nam e space provided by m odule ml to anyone sharing th e DATABASE INTERFACE in ter face. M odule m3 in form alism STAT: STAT m3 IS CROSSTAB education.crosstab (education) := INIT calculate_education_crosstab DATA education.enumeration ; REGRESS income.regression := (education, income) INIT calculate.income.regression DATA income.enumeration ; END m3 ; defines tw o functions; e d u c a tio n .c r o s s ta b and in c o m e .r e g r e s s io n to reference a crosstab an d a linear regression using th e functions e d u c a tio n .e n u m e ra tio n and in c o m e .e n u m e ra tio n , and two procedures; c a lc u la te _ e d u c a tio n _ c r o s s ta b and c a lc u la te _ in c o m e _ r e g re s s io n to com pute th e crosstab an d linear regression, respectively. A gain, th e STAT language is tailored to m ake statistical inform ation concisely specifiable. M odule m4 in form alism GRAPH: GRAPH m4 IS GRAPH make.education.graph := ON main.terminal BAR education.crosstab (0:4) HEADING "Education LABEL ("Grade School", "High School", "College", "Graduate School") ; 81 GRAPH make.income.graph := ON plotter_10a LINE income.regression (0:4,0:100000) HEADING "Education and Income" LABEL ("Education", "Income") ; END m4 ; defines two procedures m ak e .e d u c a tio n .g ra p h and m ake.incom e.graph to gen erate graphics using the functions e d u c a tio n .c r o s s ta b and in c o m e .re g re ssio n using the devices m a in .te rm in a l and p lo tte r .lO a . M odule m5 in formalism DEVICE: DEVICE m5 IS TYPE terminal (start.address) := DISCRETE HOR 0:300 VER 0:360 ADDRESS start.address ; TYPE plotter := CONTINUOUS HOR 0:36 VER 0:40 PEN UP plotter.pen.up DOWN plotter.pen.down MOVE plotter.move REFRESH plotter.refresh ; main.terminal := terminal(36042) ; plotter.lOa := plotter ; END m5 ; which provides the devices: m a in .te rm in a l and p lo tte r .lO a . M odule m6 in form alism GROG: GROG m6 IS PROCEDURE main := — load up database 82 calculate.education.crosstab (), make.education.graphO, calculate.income.regression (), make.income.graphO ; END m6 ; w hich defines th e procedure m ain to in itiate th e ro u tin es in th e various o th er m od ules. E xecution begins w ith th e m ain procedure in th e procedure tab le of STAN DARD INTERFACE. (T his exam ple is m ore fully described in detail in A ppendix G.) 5 .4 .2 In te r -M o d u le R efe r e n c e s A n inter-m odule reference is any tran sfer of execution of dynam ic a ttrib u te s from one m odule to another. In a m ulti-form alism specification, inter-m odule references m ay be m ade betw een m odules of th e sam e or different form alism s. In each case th e m eth o d is th e sam e: pointers to parse nodes o f one form alism axe saved in a global d a ta stru c tu re in an interface w hich are th e n available to o th er form alism s w hich use th e interface. In th e case of a tra d itio n a l program m ing language, these m ay be procedures w hich axe defined in one m odule an d invoked in another. In general, any interface concept m ay be shared betw een m odules of form alism s which use th e interface. Inter-m odule references m ay be im plem ented by saving a pointer to a paxse node of a m odule in a tab le of an interface. For exam ple, th e interface RELATION INTERFACE, w hich defines relation concepts th a t are shaxed betw een DDL and DML, defines a global d a ta stru c tu re w hich holds r e l a t i o n . d e c l a r a t i o n p arse nodes from any form alism . T hese parse nodes are inserted into th e tab le during the evaluation of static a ttrib u te s in DDL. L ater, during th e evaluation of dynam ic a ttrib u te s in DML, th e r e l a t i o n . d e c l a r a t i o n paxse nodes axe retrieved and ex ecuted. 5 .4 .3 E x e c u tio n A m o d u lar com position m ulti-form alism specification is executed by first parsing an d executing th e static a ttrib u te s of each m odule of th e specification and then 83 executing th e sta rt block of th e each m odule in the order th a t is determ ined by the application designer. T he essential and only difference betw een th e execution of a m o d u lar com position m ulti-form alism specification and th e execution of several uni-form alism specifications is th a t in th e later case, th ere axe no cross references betw een th e m odules w hereas, in th e form er case, th ere m ay be. In execution o f th e dynam ic attrib u te s, th e dynam ic stack will contain parse nodes from different form alism s w hereas th e static stack will contain only th e p arse nodes of a p artic u la r form alism . S tatic a ttrib u te s of a substring, therefore, will refer to th e lexical context of th e substring, w hereas dynam ic a ttrib u te s of a su b strin g will be sensitive to th e dynam ic context w hich will cross form alism s. In th e m odular com position exam ple th ere are six m odules. Execu tio n of th e exam ple m ulti-form alism specification proceeds as follows. Be fore execution, each m odule is processed to co n stru ct th e parse tree an d evaluate th e sta tic a ttrib u te s of th e associated form alism s. In ml, th e relations p e rso n , e d u c a tio n , and incom e are inserted into th e h ash tab le r e l a t io n _ d e c l a r a t i o n _ t a b l e of RELATION INTERFACE. In m2, th e procedure n ew sperson, and th e functions e d u c a tio n .e n u m e ra tio n an d in c o m e .e n u m e ra tio n are in serted into p r o c e d u r e .d e c l a r a t i o n .t a b l e an d f u n c t i o n .t a b l e , respectively, of STANDARD INTERFACE. In m3, th e functions e d u c a tio n .c r o s s ta b an d in c o m e .r e g r e s s io n an d th e procedures c a l c u l a t e .e d u c a t i o n .c r o s s t a b and c a lc u la te .in c o m e .r e g r e s s io n are in serted in to f u n c t i o n . t a b l e and p r o c e d u r e .d e c l a r a t i o n .t a b l e , respectively, of STANDARD INTERFACE. In m4, th e procedures m a k e .e d u c a tio n .g ra p h and m ak e.in c o m e .g raph are in serted in to p r o c e d u r e .d e c l a r a t i o n .t a b l e of STAN DARD INTERFACE. In m5, th e devices types device types te r m in a l an d p l o t t e r are inserted into d e v i c e .t y p e .t a b l e o f DEVICE an d devices m a in .te r m in a l and p l o t t e r . l O a axe inserted in d e v i c e .t a b l e of DEVICE INTERFACE. Finally, in m6, th e procedure m ain is inserted into th e p r o c e d u r e .d e c l a r a t i o n .t a b l e of STANDARD INTERFACE. D ynam ic execution begins w ith th e evaluation of th e e x e c u tio n synthesized dynam ic a ttrib u te of th e m ain procedure of STANDARD INTERFACE which was de fined in m6. A fter loading up th e d atab ase defined in ml, m ain proceeds to call the 84 procedure c a l c u l a t e .e d u c a t i o n .c r o s s t a b . C alling an external procedure en tails settin g th e dynam ic inherited a ttrib u te c a l l .fra m e to th e param eters (which in th is case are null) an d th en executing th e e x e c u te a ttrib u te on th e paxse node of th e c a l c u l a t e .e d u c a t i o n .c r o s s t a b procedure w hich was defined by m3. Exe cution of th e e x e c u te a ttrib u te of c a l c u l a t e .e d u c a t i o n .c r o s s t a b executes the e v a lu a te a ttrib u te of the function e d u c a tio n .e n u m e ra tio n which was defined in m2. E xecution of th e e v a lu a te a ttrib u te of th e function e d u c a tio n .e n u m e ra tio n causes a list of th e th e tuples of th e relation e d u c a tio n to be constru cted by executing th e g e n e r a te a ttrib u te of th e relatio n incom e which was defined in ml. T h e list of tuples is retu rn ed to th e execution of th e e x e c u te a ttrib u te of c a l c u l a t e .e d u c a t i o n .c r o s s t a b . T he e d u c a tio n .c r o s s ta b is com puted and th e results saved. Execution retu rn s to m ain. N ext, th e execution of th e e x e c u te a ttrib u te of m ain proceeds to th e execution of th e e x e c u te a ttrib u te of m a ie _ e d u c a tio n .g r aph w hich is defined in m4. T he e x e c u te a ttrib u te of m a ie _ e d u c a tio n .g raph, executes th e e v a lu a te a ttrib u te of th e function e d u c a tio n .c r o s s ta b w hich re tu rn s th e results of th e education crosstab, an d executes th e graphics a ttrib u te s on th e device m a in .te r m in a l which was defined in m5. Sim ilarly, th e execution of th e e x e c u te a ttrib u te of m ain executes th e e x e c u te a ttrib u te of th e procedures c a lc u la te .in c o m e .r e g r e s s io n an d m a ie .in c o m e .g ra p h . 5.5 Recursive Composition R ecursive com position is th e tra n slatio n of specifications involving m ultiple for m alism s w ith o u t th e definition of a com posing form alism as in closed com position. T h e basic u n it of recursive com position is th e substring. In any string o r substring of a specification, certain nonterm inals, in stead o f being expanded in th e form alism of th e nonterm inal, m ay be replaced w ith a su b strin g of an o th er form alism . A recursive com position m ixes b o th sta tic and dynam ic elem ents of the re spective form alism s. T h e m ixing of form alism s is controlled by n o n term in al types which describe th e a ttrib u te s of th e interface nonterm inal. Each form alism identi fies specific nonterm inals w hich axe s ta rt an d term in al nonterm inals and specifies 85 Figure 5.2: Recursive C om position P arse Tree th e interface o f those nonterm inals. A nonterm inal ty p e defines a set of a ttrib u te s w hich are required an d available a t a no n term in al of th e interface. R ecursive com position is controlled by interfaces. O nce an interface is defined, form alism s m ay be defined to use th e interface an d , thereby, share sem antics w ith o th er form alism s w hich use th e interface. Since th e interface com pletely controls th e in teractio n betw een strings an d substrings of form alism s, th ere is no need to define a com posing form alism . Tw o form alism s w hich share an interface m ay be used to g eth er in a specification w ith no ad d itio n al processing of th e form alism s. In recursive com position, th e system specification m ixes different form alism s w ithin th e sam e tex t. In term s of a p arse tree, th is m eans th a t different parse nodes of th e p arse tree will be from different form alism s (see figure recursive- com position-parse-tree). In th e diagram , th e circles, squares, and triangles rep re sent p arse nodes from different form alism s each designated by a different shape. T h e connections betw een th em indicate paren t-ch ild relationships. T h e b arred connections indicate a sw itch of context betw een form alism s. T ransitions betw een form alism s in th e tex t of th e system specification are explicitly indicated by m eta variables. 86 5.5.1 E x a m p le For example, the GROG program : PROCEDURE main IS VAR a := 1 ; FUNCTION factorial (n) IS BEGIN IF n > 0 THEN RETURN n*factorial(n-l) ; ELSE RETURN 1 ; END IF ; END factorial ; BEGIN print(a) ; a := 3 ; print(a) ; print(factorial(5)) ; END ; can be expressed as a m ulti-form alism composition of three formalisms: EXP, STMT, and DECL: PROCEDURE main IS VAR a :* ; FUNCTION factorial (n) IS BEGIN <Istatement_sequence:stmt:statement.sequence [ print() ; IF 0]I> THEN RETURN ; ELSE RETURN ; END IF ;]|> END factorial ; BEGIN <|statement.sequence:stmt:statement.sequence[ print() ; a := ; print(<(expression:exp:expression[a] I>) ; print() ;] l> END ; 87 EXP is a form alism for describing expressions, STMT is a form alism for describ ing statem en ts, an d DECL is a form alism for describing declarations. T h e m ulti- form alism program begins in DECL. 5 .5 .2 In ter-F o rm a lism T ra n sitio n It w ould b e a chaotic situ atio n , indeed, if any nonterm inal in one g ram m ar could be used as th e s ta rt sym bol for a su b strin g being su b stitu te d in to an o th er gram m ar for any a rb itra ry nonterm inal. For one th in g , th e designer of th e form alism w ould have to an ticip ate such in terru p tio n s an d provide for tran sitio n s a t any point. T his w ould be an incredible b u rd en p articu larly w hen th ere is a large num ber of a ttrib u te s w hich m ay or m ay n o t have m eaning for each n o n term in al in th e gram m ar. For an o th er th in g , th e space of possible a ttrib u te s is infinite; some m echanism m u st be defined to lim it possible inter-form alism a ttrib u te references o th er th a n tria l an d error. Unlike in m o d u lar com position w here inter-form alism tran sitio n s are dynam ic changes in form alism , inter-form alism references in recursive com position m ay be achieved th ro u g h syntactic connections betw een form alism s. Like m odular com position, though, inter-m odule references are regulated by interfaces. In stead , th e com patibility of nonterm inals for su b stitu tio n is explicitly con trolled th ro u g h th e judicious use of n o n term in al types an d typing of nonterm inals. A form alism designer will carefully select certain nonterm inals in th e form alism to be s ta rt term inals an d others to be term in al nonterm inals an d will type these according to th eir in ten d ed usage w ith respect to selected interfaces. A sta rt non term in al m u st define actions for all of th e a ttrib u te s of th e n o n term in al type since th e form alism designer has no way of m ore closely an ticip atin g how it m ay b e used (w ith in a form alism , of course, th e form alism designer can know for certain if a c ertain a ttrib u te of a certain no n term in al is ever accessed). A term in al nonterm i nal, on th e o th er h and, m ust be w ithin th e context of a definition of a nonterm inal w hich defines an action for each in h erited a ttrib u te of th e n o n term in al type, again, since th e form alism designer has no way to an ticip ate w hat su b stitu te d form alism s m ight reference. T h e nonterm inal typing m echanism , then, provides a b o u n d on 88 th e a ttrib u te references to s ta rt and term in al nonterm inals th u s insuring some level of consistent usage. T h e com patibility of nonterm inals betw een form alism s is determ ined by the ty p e of th e nonterm inal sym bols. N onterm inal sym bols which are declared to be of th e sam e ty p e axe com patible. A dditionally it is required th a t th e ro o t parse node o f a su b stitu tin g p arse tree be a s ta rt nonterm inal an d , sim ilarly, th a t a leaf p arse node for w hich th e p arse tree is su b stitu ted be a term in al nonterm inal. T his ap p aren tly contradictory term reflects th e fact th a t a term in al nonterm inal is a term in al in th e g ram m atical sense th a t it m ay be a leaf node b u t it is still a n o n term in al in th e sense th a t it m ay not. In o th er w ords, a term in al n o n term in al m ay or m ay not term in ate; it if term in ates, it does so in a m etasym bol (as opposed to a lexem e), if it does n o t, it is tre ate d like any o ther nonterm inal. A ny term in al nonterm inal of th e g ram m ar of a form alism w hich has been ty p ed m ay be used as a sta rt tra n sitio n point. T here m ay be any num ber of term inal d eclarations w ith in a single form alism g ram m ar an d a term in al n o n term in al m ay be freely used on b o th th e left an d rig h t h an d side of th e p roductions of the g ram m ar (as opposed to lexem es w hich m ay ap p ear only on th e rig h t h an d side of p roductions). For exam ple, in th e g ram m ar of STMT is th e declaration: TERMINAL e x p r e s s io n ; W hile in th e a ttrib u te action set of STMT is th e declaration: NONTERMINAL e x p r e s s io n IS e v a lu a tio n ; N ote th a t e x p r e s s io n is being classified as b o th a term in al an d a nonterm inal. T his is because, w ith respect to th e g ram m ar of STMT it is, in fact, a term inal sym bol. However, in th e larger scope of m ulti-form alism specification, it is a n o n term in al (w hich happens to be on th e borderline betw een form alism s). T hus, syntactically it is a term inal, sem antically, it is a nonterm inal. A ny term in al nonterm inal of th e g ram m ar of a form alism for w hich has been ty p ed m ay be used as a term in al tra n sitio n point. T h ere m ay be any num ber of s ta rt declarations w ithin a single form alism g ram m ar an d they m ay be freely used on b o th th e left an d rig h t h an d side of th e p roductions of th e g ram m ar. For exam ple, in th e g ram m ar of EXP is th e declaration: 89 START expression ; W hile in th e a ttrib u te action set of EXP is th e declaration: NONTERMINAL expression IS evaluation ; 5 .5 .3 E x e c u tio n A specification in one form alism m ay tra n sitio n in to a n o th er form alism a t selected nonterm inals by use of m eta sym bols w hich describe th e exiting nonterm inal, th e form alism being entered, an d th e n o n term in al of entry. T he sy n tax of th e m eta sym bol is: < lx:y :z[t] |> It explicitly alerts th e p arser to a change of form alism . T h e identifier x designates th e n o n term in al of th e exited form alism w hich th e enclosed te x t will replace, y designates th e form alism th a t is being entered, z designates th e nonterm inal of th e entered form alism a t w hich parsin g is to begin, an d t is th e actu al tex t of the entered form alism . E xcept for points of tran sitio n betw een form alism s (and th e sharing of global declarations in form alism interfaces) recursive com position specifications are ex ecuted exactly like uniform alism specifications. W hen th e process of execution reaches an inter-form alism tra n sitio n th e a ttrib u te action of parse node a m ay ref erence a ttrib u te s of parse node b and, sim ilarly, th e a ttrib u te action of p arse node b m ight reference in h erited a ttrib u te s whose value was defined by parse node a (or above). These are th e two basic form s of inter-form alism attribute references. Since th e no n term in al of parse node b an d th e n o n term in al for which it was su b stitu te d w ere ty p ed to th e sam e no n term in al type, th ere is a specific set of a ttrib u te s to w hich th e inter-form alism a ttrib u te references are restricted , i.e. th e a ttrib u te defined in th e interface. Synthesized a ttrib u te references to ty p ed non term in als are lim ited to th e a ttrib u te s of th e no n term in al ty p e.1 T hus, so long as th e n o n term in al typing is enforced, inter-form alism tran sitio n s m ay be freely m ade. 1An alternative would be to provide a test to determine whether the nonterminal referenced is in or out of the formalism making the reference. 90 E xecution of th e above procedure, m ain, begins w ith th e DECL form alism . As p arsing proceeds to th e first m etasym bol, th e parsing of m ain is suspended and a new parse is begun in th e EXP form alism to parse th e num eric value 1. W hen p arsing of th e EXP substring is finished, parsing of th e DECL strin g is resum ed. P arsin g of th e m ulti-form alism specification continues in th is m anner, evaluating sta tic a ttrib u te actions along th e way, u n til th e en tire specification has been parsed. A t th a t point, dynam ic execution is begun on th e m ulti-form alism parse tree created by th e parse. 5.6 Module Interface Formalisms A m odule interface form alism (M IF) is a form alism w hich m anages inter-form alism references in a m odularly com posed m ulti-form alism specification. W hereas m od u lar com position as previously described has a single im age of each interface to w hich every m odule of a form alism w hich uses th e p a rtic u la r interface has access, a m odule interface form alism defines m ultiple im ages of interfaces and describes w hich m odules have access to which interface im age. A n interface image is a copy of th e tables of p arse nodes and o th er d a ta stru ctu res of a n interface. T h e p artic u lar m odule interface form alism described below is b u t one possibility. In fact, it w ould n o t be unreasonable for a dom ain library to contain several different m odule interface form alism s. In a m ulti-form alism specification of five or even te n m odules, m anaging inter- form alism references is n o t a significant issue. However, for specifications involving a larger nu m b er of m odules, p articu larly w hen th e in teractio n of m odules is com plex, m anagem ent becom es essential. As th e nu m b er of m odules in a system specification increases, an d as th e interconnection becom es m ore com plex, th e need increases for a m eth o d to m anage th e com plexity. C ontinuing th e m o d u lar com position exam ple, an MIF specification w ould look like: MODULE a IS INTERFACE standard.interface ; MODULE b IS INTERFACE relation_interface ; MODULE ml : ddl ; 91 MODULE m2 : dml ; END b ; module m3 : stat ; MODULE c IS INTERFACE device.interface ; MODULE m4 : graph ; MODULE m5 : device ; END c ; module m6 : grog ; END a ; N otice th a t th e scope of RELATION INTERFACE is lim ited to ml an d m2 w hich axe th e only m odules w hose form alism s use th e interface. A nd DEVICE INTERFACE is sim ilarly lim ited to m4 and m5. B ut th e scope of STANDARD INTERFACE spans th e en tire system . If an o th er d a tab ase were introduced, it could be sep arated as follows: MODULE a IS INTERFACE standard.interface ; MODULE b IS INTERFACE relation.interface ; MODULE ml : ddl ; MODULE m2 : dml ; END b ; MODULE bb IS INTERFACE relation.interface ; MODULE m7 : ddl ; MODULE m8 : dml ; END bb ; module m3 : stat ; MODULE c IS INTERFACE device.interface ; MODULE m4 : graph ; MODULE m5 : device ; END c ; module m6 : grog ; END a ; In this case, relations shared betw een ml a n d m2 could not be shared w ith m7 and m8. M odule interface form alism s are designed to: organize m odules, control in terfaces betw een m odules, and direct system execution of m odules. A m odule 92 interface form alism organizes th e m odules an d th e d a ta stru ctu res shared betw een m odules as described in each interface by syntactically describing an organization of m odules. In th e second exam ple above, m odule a is com posed of three m odules: b, bb, an d c. M odule b, in tu rn , is com posed of m odules ml an d m2 which are, in tu rn described by a specification in th e form alism s DDL an d DML, respectively. A m odule interface form alism controls interfaces betw een m odules by explicitly creating im ages of th e interfaces used by th e form alism s of th e m odules and by controlling w hich m odules have access to w hich interface im age. Needless to say, if two m odules of form alism s w hich share a com m on interface do n o t share the sam e interface im age, th ey will not in teract. T h u s, th e scope of interfaces m ay be determ ined by th e a m odule interface form alism specification. In th e second exam ple above, th e re are tw o RELATION INTERFACE im ages, one in th e m odule b an d an o th er in th e m odule bb. T he relatio n declarations of m odule ml will not be accessible to m8. Instead, th e relation declarations of m odule ml will be accessible only to m2 an d th e relatio n declarations of m odule m7 will be accessible only to m odule m8. A m odule interface form alism m ay direct system execution of m odules by deter m ining th e order of parsing an d execution of th e sta tic a ttrib u te s of each m odule. If one m odule m akes declarations w hich an o th er will need in its own execution, th en th e first m odule m u st be executed first. A m odule interface form alism m ay describe such an ordering of execution. In th e second exam ple above, th e m odules are p arsed and sta tic a ttrib u te s executed in th e order of th e ir appearance in th e MIF specification. 5.7 Summary O pen com position is th e p rim ary m eth o d of com posing form alism s into m ulti form alism specifications. U nlike closed com position, o pen com position does not create a new form alism s b u t directly com bines form alism s in a specification. In ter faces define sh ared sem antic concepts an d form alism s are defined as orthophrase extensions of specific interfaces. T here are tw o basic m ethods of open com posi tion, m o d u lar an d recursive. M odular com position com bines dynam ic sem antics of form alism s w hereas recursive com position com bines b o th static an d dynam ic 93 sem antics. M odule interface form alism s describe th e organization of m odules and controls th e relationships betw een them . 94 Chapter 6 Conclusion F u tu re softw are developm ent environm ents should su p p o rt m ultiple form alism s as sm oothly as to d a y ’s single-language softw are developm ent environm ents. A m ong th e advantages a m ulti-form alism specification environm ent offers over conven tional softw are developm ent environm ents are: close fit of m odel to problem , com b ination, w ithin a specification, of different m odels to describe an application, and extensibility of th e m odel base. 6.1 Evaluation of Contributions Generally, th e objective set fo rth in th e in tro d u ctio n has been achieved by the m ulti-form alism specification environm ent described herein. To recap, th ere are th ree m ajo r objectives of a m ulti-form alism specification environm ent: F irst, such an environm ent should p erm it a close fit of m odel to application, since each of th e form alism s narrow ly describes a p artic u la r set of objects an d operations. Second, th ere m ust be an ability to com pose form alism s in such an environm ent to allow th e selection of only th e form alism s necessary for a p artic u la r application. T h ird , th e entire base of m odels m ust be extensible sim ply by adding new form alism s. T his m eans th a t as new specification concepts are invented— w hether o u t of a th e oretical o rien tatio n o r a recognition of a p a tte rn of application requirem ents-these concepts m ay be used in conjunction w ith previously defined specification con cepts. A m ong th e su b o rd in ate issues of m ulti-form alism specification are practical m ethods of designing form alism s and different m ethods for com posing these for m alism s. T h e n a tu re of open com position, th e preferred m ethod of com position in 95 a m ulti-form alism specification environm ent, relates closely to object-based sys tem s. 6 .1 .1 F ittin g th e M o d e l to th e D o m a in T h e difference betw een p arap h rase an d o rth o p h rase definition m ay be described as follows: in p arap h rase, relationships are described betw een sem antic concepts of a base form alism B an d a new form alism C. O n th e o th er h an d , in orthophrase definition, relationships are described betw een th re e form alism s, a base form alism A, an original form alism B an d a new form alism C. Now obviously, if A an d B axe very sim ilar, o rth o p h rase degenerates in to p arap h rase. However, in th e typical case, A is a relatively low level form alism and B and C are b o th relatively high level form alism s. In p arap h rase, explicit relationships are described betw een B an d C b u t in o rth o p h rase, th e explicit relationships are described betw een A an d B and betw een A a n d C; th e relationships betw een B an d C in o rth o p h rase definition are entirely im plicit an d u n sta te d (actually, interfaces describe som e m inim al aspects of this relationship). T h u s th e difference betw een p arap h rase and o rth o p h rase definition is p ro p o rtio n al to th e difference betw een high an d low level form alism s. It should be equally obvious th a t o rth o p h rase is b o th m ore arduous an d m ore pow erful th an p arap h ra se definition. In a tran sfo rm atio n al definition of form alism s, each form alism is defined in term s of an o th er form alism in th e dom ain lib rary by a set of transform ations. T h e relationship betw een form alism s is exactly cap tu red in th e transform ations betw een them . By co n trast, in a tran slatio n al definition o f form alism s, all for m alism s are defined in term s of a com m on low level form alism (eith er by tra n s latio n o r in terp retatio n ). E ach new form alism re tu rn s to th e com m on low level form alism . Several previous approaches to softw are specification, in flu ding D raco an d Local Form alism s, w ere b u ilt u p o n a tran sfo rm atio n al approach to form alism definition. T ranslational definition (including b o th tra n slato rs an d in terp reters) is differ ent from tran sfo rm atio n al definition in tw o ways. F irst, tra n slatio n al definition sep arates high/low form alism issues from form alism b re a d th issues. H igher level 96 form alism s necessarily sacrifice capabilities o f th e lower level form alism s in order to gain sim plicity of specification. For exam ple, in order to ad d backtracking to PASCAL you w ould have to ad d c h o ic e an d f a i l statem en ts to th e language. T hese constructs could not be described by sim ple transform ations; a tran sfo rm a tional description w ould require co n stru ctin g an entirely new language processor on to p of PASCAL w hich in terp rets all of th e old PASCAL con stru cts an d th e new c h o ic e an d f a i l statem ents. A ssum ing th a t these statem en ts could be added by o rth o p h rase (th a t they do not require m etap h rase), only th e corresponding tra n sla tio n or in terp retatio n of each statem en t need be added. O n th e o ther h and, o rth o p h rase definition, in and of itself is arduous, w hich is w hy it m ust be m anaged by a th e form alism designer ra th e r th a n th e application designer. T hus, th ere is a tra d e off. Second, tran sfo rm atio n al definition diverts certain form alism issues in to choice of tran sfo rm atio n . A n im plem entation derived from a transform ationally defined form alism reflects not only th e specification b u t also th e choices of tran sfo rm a tions by th e application designer. W hile these choices of tran sfo rm atio n s m ay be c ap tu red in developm ent histories, such histories are by design outside th e form al ism since th ey are not form ally represented in th e specification. In tran slatio n al definitions, by co n trast, since th e tran slatio n is au tom atic, th e specification ex actly defines th e im plem entation. T he high to low level relationship hidden in th e tra n slatio n is fixed and constant. T h u s a specification exactly defines w hat an application does although th e exact m eth o d m ay be hidden in th e tra n sla tion. However, th e tran sfo rm atio n p arad ig m intentionally separates th e choice of tran sfo rm atio n s o u t of th e specification on th e assum ption or philosophy th a t they reflect im plem entation decisions ra th e r th a n design decisions. A gain, th ere is a tra d e off. O f course, w here p arap h rase definition is desirable, autom atically applied sets of tran sfo rm atio n s co n stitu te a m ore precise, elegant, declarative rep resen tatio n for th e au to m atic com pilation activity. B u t since tran sfo rm atio n s and tra n slatio n are essentially equivalent in expressibility, it is possible to use transform ation-based system s to im plem ent o rthophrase definition, b o th by closed and open com posi tion. 97 D raco, w ith its DAG of form alism levels, essentially im plem ents a transform ation-based closed com position. However, in th e process of transform ing a closed com position form alism into th e lower level form alism s, th e specification will actually include strings from different form alism s. D raco takes great liberty in assum ing th a t tran sfo rm atio n s can be w ritten w hich axe unaffected by this. Local Form alism s, on th e o th er h an d , depending on how th ey are defined, use kernels to unify th e sem antic concepts w hich, unless th e kernel is a low level for m alism , m eans th a t Local Form alism s ten d to be parap h rase-o rien ted , though it should be no ted th a t th e b ro ad er definition of Local Form alism s does not have th is characteristic. C onsider a tree w here every node in th e tree is a form alism an d every non-leaf node is a kernel. A set of transform ations exists for each node w hich describes a m ap p in g from th a t node to its p aren t. In term s of such a form alism tree, th e objective of m ulti-form alism specification is to allow a n application designer to select an a rb itra ry subset of form alism s from the tree to specify an application. In closed com position, a new form alism w ould be defined in term s of th e selected sub set of form alism s. T hus, closed com position tu rn s th e tree in to a DAG and leaves to th e design of transform ations th e problem of fittin g th e different form alism s together. In open com position, on th e o th er h an d , th e form alism s axe directly used together in th e specification and th en transform ed according to th eir respec tive form alism . In b o th cases, an d p articu larly in th e case of open com position in a transform ation-based system , interfaces w ould have to be defined w ith each bran ch in th e tree to regulate th e usage of descendants and these interfaces could be of a form very sim ilar to w hat we presented for in te rp reter/tran slato r-b a se d definition of form alism s defining which nonterm inals are interchangeable. A ttrib u te action sets, on th e o th er h an d , axe an expressive yet efficient m ethod for specifying th e sem antics of form alism s by tra n sla tio n or in terp retatio n . Ju st like a ttrib u te gram m ars, a ttrib u te action sets provide facilities for describing for m alism sem antics in term s of a ttrib u tes. By allowing th e co m p u tatio n of attrib u te s to be procedural, w ith side-effects, we avoid some of th e problem s w ith previous syntax-directed m ethods of definition while sacrificing form ality an d elegance. 98 In p artic u la r, a ttrib u te action sets are nonterm inal-oriented ra th e r th a n production-oriented. In a trad itio n al syntax-directed definition of form alism se m antics, inherited a ttrib u te values are determ ined by functions or procedures a t tach ed to nonterm inals of th e rig h t-h an d side of each production. T hus, an in h erited a ttrib u te value will depend on a single definition ra th e r th a n on different definitions scattered th ro u g h th e rig h t h an d sides of various productions. A ttrib u te action sets introduce dynam ic a ttrib u tes. D ynam ic a ttrib u te s p er m it th e direct description of form alism sem antics an d are essential for specifying in terp reter-b ased form alism sem antics. T hey w ould also be useful for specifying tran slato r-b ased form alism sem antics. A side from th e advantages a ttrib u te action sets offer in th e design of single form alism s, th ey are p articu larly useful for th e design of form alism s suitable for interface-based com position. Because sem antics are organized aro u n d n o n term i nals an d a ttrib u te s, they m ay be used to specify b o th form alism s an d interfaces. Since each nonterm inal m ay have any nu m b er of attrib u te s, sem antics of a non term in al m ay be distinguished betw een w hat is local to th e form alism , w hat is shared, an d w ith w hom it is shared, sim ply by controlling w hich a ttrib u te s are shared. Since each a ttrib u te m ay be im plem ented by any nu m b er of nonterm inals, interfaces m ay be specified in term s of shared a ttrib u te s an d n o n term in al types w hich each form alism using th e interface m ay im plem ent as it chooses. A ttrib u te action sets offer a n a tu ra l m echanism for dividing and sharing sem antics betw een form alism s of a m ulti-form alism specification environm ent. 6 .1 .2 M e th o d s o f C o m p o sitio n Interface-based com position allows form alism s w hich use th e interface to be a r b itrarily com posed by th e user of th e form alism . Interface-based com position singularly provides for th e capability of open com position an d is th e m ajo r con trib u tio n o f th is dissertation. By com parison, closed com position is a very lim ited m eth o d of com bining form alism s. O pen com position represents a significant im provem ent over closed com posi tio n for several reasons. F irst, it allows th e application designer to do th e actu al 99 com position of form alism s lim ited only by th e form of th e interface shared by re spective form alism s. T he im portance of this capability cannot be overem phasized. By allowing th e application designer to m ake th e com positions w hich he chooses for a p artic u la r application, open com position a t once alleviates th e form alism de signer of th e incredible b u rd en of designing “cross-product” form alism s and allows a closer fit of specification com ponents to application dom ains. Second, open com position allows a m ore general com bination of form alism s, constrained only by th e b rea d th of previously defined interfaces. T his m eans th a t form alism s m ay be com bined in ways th a t th e designer of th e interface an d th e form alism s m ay n o t even have anticipated. Indeed, it absolves th e form alism an d interface designers of having to consider how th e form alism s m ight be com posed in m uch th e sam e w ay th a t procedure param eters absolve th e w riter of a procedure from having to consider th e context in w hich a procedure m ight be called. T h ird , it allows th e form alism designer to ad d new form alism s to th e dom ain lib rary w ithout having to reevaluate every existing form alism w hich m ight be com bined w ith it. T his is essential in an environm ent w here a large num ber of form alism s will be m ain tain ed an d new form alism s will occasionally, or frequently be added. M odular an d recursive com position m ay b o th be im plem ented by open com position, b u t each has p ractical considerations th a t im ply very different usage. Essentially, m o d u lar vs. recursive com position tra d e s tightness of in teg ratio n for generality of reuse. In th e case of m odular com position, m odules m ay be archived an d reused in different applications w hereas recursive com ponents of a specification are, by th eir very n atu re, specific to th e context of th eir use. M odular com position requires th e lexical sep aratio n of different form alism s in specifications. T his m eans th a t interactio n betw een different form alism s m ust be effected by explicit use of shared declarations. In recursive com position, on the oth er h an d , different form alism s m ay be lexically m ixed w ithin th e sam e specifi cation allowing a m ore liberal m ix of sem antic concepts. 100 6 .1 .3 E x te n sib le R e u se T h e m ulti-form alism specification environm ent of th is thesis was b u ilt on CLOS, an object-oriented subsystem of C om m on Lisp. W hile th e object system was b uried b en eath th e sem antic m odel of nonterm inals an d a ttrib u te s such a pro gram m ing system was essential to th e n atu re of open com position. In fact, the necessity of th e object system was selected only after it was discovered th a t the earlier im plem entation of th e m ulti-form alism specification environm ent was d u p licating its capabilities to im plem ent open com position. O bject-based system s w ere developed to m odel open system s so it should be no surprise th a t they are closely related to open com position. G iven th e close n a tu re of object-based system s an d open com position in a m ulti-form alism specification environm ent, it w ould m ake sense to regard m ulti form alism specification as a refinem ent of th e object-based system program m ing for several reasons: F irst, m ulti-form alism specification is a user-efficient m ethod of creatin g objects. G iven a set of form alism s w hich define th e form of objects, a user can easily generate a set of objects w ith specific qualities w hich are partially determ ined by th e form alism and p artly by th e specification. T h e form alism m ay b e reg ard ed not only as a declaration of object classes b u t also as a form for which th e specification sim ply fills in certain blanks. Second, th e form alism itself is an efficient m eth o d for describing object classes and form s for object generation an d for describing th e connections betw een them . A form alism specification (g ram m ar an d a ttrib u te action set in terp reter) m ay be regarded as a high level description of object classes. T h ird , although a rb itra ry connections betw een th e objects (parse nodes) of a specification m ay be established, th e p arse tree provides a pregenerated set of connections betw een objects upon w hich m ore com plex connections m ay be established. In trad itio n al object- oriented program m ing environm ents, only the p aren t an d global objects are im m ediately available to a new o bject b u t in a specification, each parse node has access to its p aren t, its children, an d all th eir a ttrib u te s. 101 6.2 Future Directions T h e results an d im plications of this research lead in m any directions b u t exploring those directions will undoubtedly require an accum ulation of experience in design ing actu al interfaces, form alism s, and applications. Therefore, th e next logical step in this line of research is to apply th e m ulti-form alism specification environm ent as described herein to th e im plem entation of actu al applications. A lternatively, th ere are som e lines of research th a t m ay be p u rsu ed on a m ore theoretical basis form alizing th e underlying concepts of m ulti-form alism specification. 6 .2 .1 F orm alism an d In terfa ce D e sig n T he field of form alism design is largely restricted to general purpose program m ing languages an d self-contained dom ain-specific form alism s. T h e area of form alism s designed to be used in th e context of a m ulti-form alism specification is largely unexplored. W h a t dom ains should form alism s a tte m p t to directly m odel and w hich should they m odel only indirectly? W h at aspects of a form alism m ake it a good can d id ate for reuse in m any contexts? Is th ere an identifiable m ethodology to th e design of form alism s th a t will predict interactions? Should such a m ethodology proceed from several exam ple applications to a form alism o r from a theory of a class of applications? A m ore form al analysis of th e relationship betw een th e ad hoc interfaces we described and th e fixed interface m ethodologies such as CM U ’s IDL w ould help illum inate th e n a tu re of interfaces. T he design of interfaces of th e form presented herein is also largely unexplored. Should interfaces be designed as com panions to specific form alism s or should in ter faces be designed aro u n d fam ilies of form alism s? How does an interface designer an ticip ate fu tu re use of an interface by form alism s w hich will be designed later or w hich will be designed by o th er persons? Should interfaces be organized in to a flat stru c tu re w here each interface is directly used by form alism s an d for w hich no interfaces uses an o th er or a hierarchy w ith th e m ost general interfaces being used by m ore specific interfaces an d only th e m ost specific interfaces being used by form alism s? W h at if tw o different form alism s use two different interfaces w hich b o th share an interface? W h at if tw o form alism s share red u n d an t interfaces? 102 Also, th e m ethod of interface declaration we presented was essentially an ab stra c t syntactic approach. A great deal can be said in favor o f attach in g m ore sem antic inform ation to interfaces in order to convey m ore inform ation ab o u t th e relationships betw een form alism s w hich use th e interface. For exam ple, th e m ethod of defining parse nodes shared betw een com ponents in different form alism s was by insertion into a global table, b u t certainly a m ore form al characterization of which parse nodes are shared w ould go a long way tow ard form alizing th e relationship betw een form alism s. U nfortunately, deciding which p arse nodes are sh ared is nec essarily dynam ic, b u t th a t need n o t prevent a declarative statem en t describing m ore precisely w hich classes of parse nodes will be shared. 6 .2 .2 S em a n tic D e fin itio n A lthough a ttrib u te action sets precisely characterize th e concepts of m ulti- form alism specifications, th ey are som ew hat ad_ hoc. It w ould be a w orthw hile exercise to define a m ulti-form alism specification environm ent in term s of declara tive syntax-directed, definitions or in term s of a declarative object-oriented system . A m ong th e problem s th a t w ould be encountered w ould be th e declarative defini tio n of w hich parse nodes are produced an d consum ed by m odules of different form alism s (in th e im perative im plem entation, these w ere explicitly inserted into tables of th e interface by side-effect of actions on th e p arse nodes, them selves). How does m ulti-form alism specification work in a tran slato r-o rien ted environ m ent as opposed to an interpretive environm ent? A serious application of this research w ould have to be based on tran slatio n ra th e r th a n in terp retatio n . O ne essential difference betw een in terp reter- an d tran slato r-b ased form alism definition is th a t in th e form er case, dynam ic a ttrib u te s directly described th e behavior of th e form alism an d p arse nodes were shared betw een m odules of a specification in order to gain access to th e dynam ic a ttrib u te s of th e respective form alism s. In th e case of tran slato r-b ased form alism definition, however, parse nodes will still be shared a t th e point of tran slatio n , b u t since th e objective is to produce object code w ith a given behavior ra th e r th a n to produce directly th e in ten d ed behavior, it will be static a ttrib u te s of those p arse nodes w hich are 103 evaluated. These static a ttrib u te s will share chunks of previously com puted object code. However, th e exact form of these chunks of object code is difficult to determ ine a t th is point. Should they be self-contained or should they contain unresolved references? O ne approach to this w ould be to use dynam ic a ttrib u te s for any m acro-expansions and to use static a ttrib u te s w here whole chunks of code are shared. For exam ple, if a function declaration can b e represented by sharing the nam e (or address) of th e function betw een m odules, th e n a static a ttrib u te w ould be used, b u t if a function were intended to be expanded inline, th en a dynam ic a ttrib u te w ould be used to com pute th a t inline expansion. W ith in closed com position, distinguishing o rth o p h rase an d m etap h rase ex tension and defining th e concepts concretely is an extrem ely difficult problem . D epending upon th e basis of sem antic definition, certain extensions m ay be or th o p h rase or m etaphrase; w hat is m etap h rase in an ad hoc p rocedural definition of sem antics m ight b e orth o p h rase in a d en o tatio n al sem antic definition. M oreover, even w ithin a form al definition such as d en o tatio n al sem antics, a p a rtic u la r exten sion m ight be described either as a m etap h rase o r a o rth o p h rase extension. Is the definition of each necessarily relative to th e p a rtic u la r basis of sem antic definition or is th ere som e absolute m ethod of distinguishing betw een them ? If th ey are nec essarily relative, is th ere som e reason to give a preference to one p artic u la r basis over an o th er (e.g. d en o tatio n al sem antic) w hich could serve as a definitional b a sis? Intuitively, an d practically, given a p artic u la r m eth o d of sem antic definition, th e differences betw een them are very real b u t th e relative n a tu re of definition is som ew hat distu rb in g . T his issue needs to be addressed. 6 .2 .3 C lo sed v s. O p en C o m p o sitio n A lthough closed com position is lim ited relative to open com position, it still has a place as a tool o f form alism design. Closed com position will alm ost necessarily en tail o rth o p h rase ra th e r th a n m etap h rase com position, if needed. A m ore precise ch aracterizatio n o f th e dividing line betw een o rth o p h rase an d m etap h rase com po sition should be developed. If com posing tw o form alism s requires changes to one o r b o th , th en th e com poser m ust take responsibility for th e changes; b u t it m ight 104 be possible for th e original designer of th e form alism to organize nonterm inals in such a way as to m ake changes to some easier while discouraging changes to oth ers. T his w ould be an im p o rtan t consideration in th e closed com position of large com plex form alism s. T h e p rim ary focus of this research has been on open com position, b u t there several questions have been raised. W ill it be, in practice, a noticeable im prove m en t over closed com position? To w hat extent does th e necessity to interface affect an d lim it form alism designs? How different can new form alism s be consid ering th a t they m ust use existing interfaces? W h at h ap p en s w hen a new interface is introduced? A lthough interfaces can b e introduced m onotonically, w hat loss of efficient representation occurs w ithout review ing existing form alism s? R esearch in interface-based, open com position could proceed in several direc tions. A theory should be developed to describe precisely th e differences betw een closed and open com position. P ractical work should be done in open com posi tio n an d closed com position to firm ly establish the differences betw een th e two m ethods. A nd experience w ith interface-based open com position should be accu m u lated from such p ractical work. T he m odule interface form alism (M IF ) presented is extrem ely unsophisticated ✓ a n d m erely scratches th e surface in this area. A re different m odule interface for m alism s needed or will one suffice? How m uch inform ation should a M IF convey? How m uch control should a M IF have over m odules and interfaces? C an interfaces be handled m ore im plicitly? Do interfaces have to be designed to work w ith a p artic u la r m odule interface form alism ? 6.3 Final Remarks T his research represents th e convergence of two im p o rtan t concepts in com puter science: softw are design an d open system s. In th e area of softw are design, this work directly extends th e ideas and concepts of Levy an d N eighbors w ho introduced th e concept of sep aratin g softw are developm ent into stages of form alism design and form alism use, an d W ile w ho form ulated th e concept of local form alism s, in w hat w ould seem to be an obvious direction: th e com position of form alism s to solve a 105 single problem . T he m ethod of com position chosen here takes previous language extension work to its logical conclusion: o rth o p h rase definition. T he m ulti-form alism specification environm ent is an open, extensible system w herein it is hoped th a t inform ation m ay be arb itrarily added to th e environm ent in th e form of new form alism s. As m ore form alism s are added, th e environm ent becom es m ore “intelligent” . T h u s th e concept of open com position is im p o rtan t, allowing form alism s to be m ore o r less arb itrarily added to th e environm ent. T h e test, of course, is w hether form alism s m ay, in fact, be arb itrarily added, for if adding a form alism thro u g h open com position is no easier th a n adding one th ro u g h closed com position th en no advantage has been gained and th e en tire environm ent m ust be redesigned w ith each new form alism . B ut we believe th a t if interfaces are carefully and continually designed, form alism s can be m ore or less a rb itrarily added to th e environm ent w ith o u t having to go back and redesign older form alism s. O nly m ore experience w ith actu al interfaces, form alism s, and applications will tell if th is is th e case. 106 BIBLIOGRAPHY [Ada83] [ASU86] [Bal85] [Bar82] [BCG83] [BDG+88] [Bel69] [BN84] [BO80] [Boo83] U nited S tates D epartm ent of Defense. Reference M anual fo r the Ada Programming Language, 1983. Alfred V. Aho, Ravi Sethi, an d Jeffrey D. U llm an. Compilers: P rin ciples, Techniques, and Tools. A ddison W esley P ublishing Com pany: R eading, M assachusetts, 1986. R o b ert Balzer. A 15 year perspective on au to m atic program m ing. IE E E Transactions on Software Engineering, S E -11(11), Novem ber 1985. G. O cto B arn ett. T he com puter an d clinical judgem ent. The New England Journal o f M edicine, 37(8), A ugust 19 1982. R o b ert Balzer, T hom as E. C h eath am , and Cordell G reen. Softw are technology in th e 1990’s: U sing a new paradigm . C om puter M aga zine, 1983. D aniel G. Bobrow, L inda G. DeM ichiel, R ichard P. G abriel, Sonya E. Keene, G regor Kiczales, an d D avid A. M oon. C om m on Lisp Object System Specification, M ay 1988. Jam es R. Bell. T ransform ations: T h e extension facility of proteus. In Proceedings o f the Extensible Languages Sym posium . ACM SIG- PLA N , 1969. A. D. B irrell and B. J. Nelson. Im plem enting rem ote procedure calls. A C M Transactions on C om puter S ystem s, 2(1), Ja n u a ry 1984. D. B jorner and 0 . N. O est, editors. Towards A Form al D escription O f Ada. Springer-V erlag, 1980. G rady Booch. Software Engineering W ith Ada. T h e B en jam in /C u m m in g s P ublishing C om pany, Inc., M enlo P a rk California, 1983. 107 [Bor85] [Bow71] [Bud83] [Bud84] [Cha71] [Che69] [Coh87] [Def68] [Def83] [DeM79] [Dic71] [DP82] [Dre79] [Dub71] G ary C. B orchardt. E vent calculus. In N in th International Joint Conference on A rtificial Intelligence. In tern atio n al Jo in t C om m ittee on A rtificial Intelligence, 1985. H enry J. Bowlden. M acros in higher-level languages. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. T im o th y A. B udd. A n A PL com piler for th e UNIX tim esharing system . In A P L 8 S Conference Proceedings, 1983. T im othy A. B udd. A n A PL com piler for a vector processor. A C M Transactions on Programming Languages and System s, 6(3), Ju ly 1984. G erald D. C handler. M E T A PI - a language for extensions. In Pro ceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. T . E. C heatham . M otivation for extensible languages. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1969. D on Cohen. A P 5 M anual. U S C /In fo rm atio n Sciences In stitu te , 4676 A dm iralty Way, M arina del Rey, CA , 90292, 1987. D ep artm en t O f Defense. Specification Practices, 1968. D ep artm en t O f Defense. D efense S ystem Software D evelopm ent, 1983. Tom D eM arco. Structured Analysis A n d S ystem Specification. Your- don P ress, 1979. B. N. D ickm an. S ubroutine interface prim itives for E T C . In Pro ceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. Frank D eR em er and T hom as Pennello. Efficient co m p u tatio n of L A L R (l) look-ahead sets. A C M Transactions on Programming Lan guages and S ystem s, 4(4), O ctober 1982. H u b ert L. D reyfus. W hat C om puters Can’t Do: A Critique o f A r ti ficial Reason. New York: H arper an d Row, 1979. J. J. Duby. E xtensible languages: A p o ten tial u ser’s p o in t of view. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. 108 [DUP+82] [E1186] [Fan82] I [Fax82a] [Far82b] [Far84] [Fea85] [FHI71] [Fic85] [Fre84] i • [Fro89] l [Gar69] I [Geo83] S. D rossopoulou, J. Uhl, G. Persch, G. Goos, M. D ausm ann, and G. W interstein. A n a ttrib u te g ram m ar for A da. In Proceedings Of The Com piler C onstruction Sym posium . ACM SIG PLA N , 1982. I \ Jo h n R. Ellis. Bulldog: A Compiler fo r V L IW Architectures. M IT P ress, 1986. ' Isu Fang. FO LD S, a declarative form al language definition system . Technical R eport STAN-CS-72-329, C o m p u ter Science D epartm ent, Stanford U niversity, 1982. 1 R odney Farrow . Experience w ith an a ttrib u te gram m ar-based co m -. piler. S IG P L A N N otices, Ja n u a ry 1982. R odney Farrow . Linguist-86: Yet an o th er tra n sla to r w riting sys tem based on a ttrib u te gram m ars. In Proceedings O f The Com piler C onstruction Sym posium . ACM SIG PLA N , 1982. R odney Farrow . G enerating a p ro d u ctio n com piler from an a ttrib u te gram m ar. IE E E Software, O ctober 1984. M artin S. F eather. Language su p p o rt for th e specification and de velopm ent of com posite system s. 1985. A. F ernandez, J. C. H eliard, and J. D. Ichbiah. Overview of the syn tax processor generator SY N PR O C . In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. S. Fickas. A u to m atin g th e tran sfo rm atio n al developm ent of software. IE E E Transactions on Software Engineering, S E - l l ( l l ) , Novem ber 1985. P eter Freem an. A nalysis of th e D raco approach to constructing soft w are system s. Technical R ep o rt 85-07, U niversity Of California, Irvine, C om puter Science D ep artm en t, O ctober 1984. R. A. Frost. A pplication program m ing as th e construction of lan guage in terp reters. S IG P L A N Notices, 24(9), Septem ber 1989. I J a n V. G arw ick. G PL , a general p u rp o se language. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1969. M ichael Georgeff. C om m unication an d in teractio n in m ulti-agent planning. In Proceedings o f A A A I-8 8 . A m erican A ssociation for A r tificial Intelligence, 1983. ' 109 [Geo84] [Geo85a] [Geo85b] [GG82] [Gil71] [GLS84] [GPP68] [GR74] [Gra71] [GRW77] [GS88] [GW80] [GWAEB83] [Ham71] M ichael Georgeff. A th eo ry of action for m ultiagent planning. In Proceedings o f A A A I-8 4 . A m erican A ssociation for A rtificial Intelli gence, 1984. M ichael Georgeff. A procedural logic. In Proceedings o f IJC A I-85. In tern atio n al Jo in t Council on A rtifial Intelligence, 1985. M ichael Georgeff. A theory of process. In Proceedings o f D istributed A I W orkshop. A m erican A ssociation for A rtificial Intelligence, 1985. H araid G anzinger an d R o b ert Giegerich. A tru ly generative sem antics-directed com piler generatror. In Proceedings O f The S ym posium On Com piler Construction. ACM SIG PLA N , 1982. Teun Van Gils. S yntactic definition m echanism s. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. J r. G uy L. Steele. C om m on Lisp: The Language. D igital Press, 1984. R. E. G risw old, J. F . Poage, and I. P. Polonsky. The S N 0 B 0 L 4 Programming Language. P ren tice Hall, Inc, Englew ood Cliffs, New Jersey, 1968. L eonard G ilm an and Allen J. Rose. A P L : A n Interactive Approach. Jo h n W iley A nd Sons, New York, 1974. C harles A. G rant. Syntax tra n sla tio n w ith context m acros, or m acros w ith o u t argum ents. In Proceedings o f the Extensible Languages S y m posium . ACM SIG PLA N , 1971. H araid G anzinger, K n u t R ipken, an d R einhard W ilhelm . A utom atic generation of optim izing m ultipass com pilers. In Proceedings O f Ifip Conference. Ifip, 1977. C. G enillard an d A. Strohm eier. G RA M O L: A g ram m ar descrip tio n language for lexical an d sy ntactic parsers. S IG P L A N Notices, 23(10), 1988. Neil M. G oldm an and D avid S. W ile. G ist language description. 1980. G. Goos, W . A. W ulf, Jr. A. Evans, and K. J. B utler, editors. Diana: A n Interm ediate Language For Ada. Springer-V erlag, 1983. M ichael H am m er. A n altern ativ e approach to m acro processing. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. 110 [HCW82] [HdJ83] [Hew84] [Hew85] [Hol71] [Hol87] [Hor88] [HP83] [Ips86a] [Ips86b] [Ips89] [Ips90] [Iro63] [Iro69] R .C . H olt, J.R . Cordy, and D.B. W ortm an. A n in troduction to S/SL: S y n tax /sem an tic language. A C M Transactions on Program m ing Languages and System s, 4(2), A pril 1982. C arl H ew itt and P eter de Jong. A nalyzing th e roles of descriptions and actions in open system s. In Proceedings o f the N ational Con ference on A rtificial Intelligence. A m erican A ssociation for Artificial Intelligence, 1983. C arl H ew itt. Tow ards new foundations for artificial intelligent sys tem s. 1984. C arl H ew itt. T h e challenge of open system s. B yte, A pril 1985. G lenn H. Holloway. In terp reter/co m p iler in teg ratio n in ECL. In Pro- ceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. R .C . H olt. D a ta descriptors: A com pile-tim e m odel of d a ta an d a d dressing. A C M Transactions on Program m ing Languages and Sys tem s, 9(3), Ju ly 1987. R. Nigel H orspool. Increm ental generation of L R parsers. Technical R ep o rt D CS-79-IR, D epartm ent of C om puter Science, U niversity of V ictoria, M arch 1988. A. Nico H aberm ann and Dewayne E. Perry. Ada For Experienced Programmers. Addison-W esley P ublishing Com pany, R eading M as sachusetts, 1983. E dw ard A. Ipser, Jr. A schem e for th e recursive elaboration of gist specifications. 1986. E dw ard A. Ipser, Jr. W hy gist doesn’t work. 1986. E dw ard A. Ipser, J r. T he infinite sta te acceptor an d its application to AI. S IG A R T Newsletter, (107), Ja n u a ry 1989. E dw ard A. Ipser, Jr. Toward A M ulti-F orm alism Specification E n vi ronm ent. P hD thesis, U niversity of S outhern C alifornia, C om puter Science D ep artm en t, 1990. U niversity of S o u th ern C alifornia Infor m atio n Sciences In stitu te. E. T . Irons. Tow ards m ore versatile m echanical tran slato rs. Pro ceedings O f The Sym posium On Applied M athem atics, 1963. E dgar T . Irons. T he extension facilities of Im p. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1969. I l l [IRS 78] [IWJ90] [Joh75] [Joh78] [Joh79] [Jor69] [Jor71] [Kai84] [Kai87] [KF86] [KF87a] [KF87b] [KG86] P. M. Lewis II, D. J. R osenkrantz, and R. E. S tearns. Compiler D e-j sign Theory. A ddison Wesley P ublishing Com pany: R eading, Mas-i sachusetts, 1978. ; I E dw ard A. Ipser, Jr., D avid S. W ile, an d D ean Jacobs. W hy g istt doesn’t work. S u b m itted to th e 1990 ACM S IG S O F T W orkshop,! 1990. | I S. C. Johnson. Y A C C -yet an o th er com piler com piler. Technical R ep o rt C om puting Science Technical R ep o rt 32, A T& T Bell Labo rato ries, 1975. S. C. Johnson. A p o rtab le com piler: th eo ry an d practice. In Sym-\ posium on Principles o f Programming Languages. ACM SIG PLA N , 1978. S. C. Johnson. A to u r th ro u g h th e p o rta b le C com piler. Technical rep o rt, A T& T Bell L aboratories, 1979. j P hilippe Jo rran d . Some aspects of Basel, th e base language for an extensible language facility. In Proceedings o f the Extensible Lan guages Sym posium . ACM SIG PLA N , 1969. P h ilip p e Jo rran d . D a ta types and extensible languages. In Pro ceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. G. K aiser. IE: A n Im p lem en to r’ s E nvironm ent fo r Developing Language-O riented Editors. PhD thesis, Carnegie-M ellon U niver sity, C o m p u ter Science D ep artm en t, 1984. N asar S. G ail E. K aiser. Strategies in M ARVEL: O bject-oriented and rule-based. 1987. J G ail E. K aiser and P eter H. Feiler. A u to m ated softw are m anage m ent: A daptive planning th ro u g h h isto ry analysis. 1986. | G ail E. K aiser an d P eter H. Feiler. A n arch itectu re for intelligent assistance in softw are developm ent. In 9th International Conference on Software Engineering, 1987. G ail E. K aiser and P eter H. Feiler. Intelligent assistance w ithout artificial intelligence. In Thirty-Second IE E E C om puter Society In-, ternational Conference, 1987. I G ail E. K aiser an d D avid G arlan. Synthesis of program m ing envi ronm ents from reusable building blocks. 1986. [KG87a] [KG87b] [KH89] [KHZ82] [KM71] [Knu68] [Kos84] [KR78] [KRS82] [Kru71] [Lee87] [Lev87] [LJG82] G ail E. K aiser an d D avid G arlan. C om posing softw are system s from reusable building blocks. In Tw entieth Hawaii International Confer ence on S ystem Sciences, 1987. G ail E. K aiser an d D avid G arlan. M ELD : A declarative n o tatio n for w riting m ethods. In Sixth A nnual International Phoenix Conference on Com puters and C om m unications, 1987. M ichael K arr and G lenn H. Holloway. Beyond th e read-eval loop: A rchitecture of th e E-L environm ent. A ugust 1989. Uwe K astens, B rig itte H u tt, and Erich Zim m erm ann. GAG: A Prac tical Com piler Generator. Springer-V erlag, 1982. J. K atzenelson and E. M ilgrom . A sh o rt p resen tatio n of th e m ain features of A E PL. In Proceedings o f the Extensible Languages S ym posium. ACM SIG PLA N , 1971. D. E. K n u th . Sem antics of context free languages. M ath. Syst. The ory, 2(2):127-145, 1968. K ai Koskim ies. A specification language for one-pass sem antic analy sis. In Proceedings O f The Com piler C onstruction Sym posium . ACM SIG PLA N , 1984. B rian W . K ernighan and D ennis M. R itchie. The C Programming Language. Prentice-H all Softw are Series, 1978. K ai K oskim ies, K ari-Jouko R aiha, an d M a tti Sarjakoski. Com piler construction using a ttrib u te gram m ars. In Proceedings O f The Com piler C onstruction Sym posium . ACM SIG PLA N , 1982. R udolph A. K ru tar. C onversational system s program m ing. In Pro ceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. P eter Lee. The A u to m a tic G eneration o f Realistic Compilers from High-Level Sem antic D escriptions. P hD thesis, U niversity of M ichi gan, C om puter an d C om m unication Sciences, 1987. Leon S. Levy. Tam ing the Tiger: Software Engineering and Software Econom ics. Springer-V erlag: New York, 1987. R udolf L andw ehr, H ans-S tephan Jan so h n , an d G erh ard Goos. Ex perience w ith an au to m atic code g en erato r generator. In Proceedings O f The Com piler C onstruction Sym posium . ACM SIG PLA N , 1982. 113 [Lor77] [Mac69] [Mad80] [MBW80] [Mcc83] [McD83] [Mck76] [MKR79] [Mos86] [MP69] [MP84] [Nei81] [Nei84a] [Nei84b] B ernard Lorho. Sem antic attrib u tes processing in the system Delta. In A. Ershov, editor, M ethods O f Algorithm ic Language Im plem en tation. Springer-V erlag: Berlin, 1977. M. D onald M acLaren. M acro processing in E P S . In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1969. Ole L ehrm ann M adsen. O n defining sem antics by m eans of extended a ttrib u te gram m ars. Technical R eport D aim i Pb-109, C om puter Sci ence D ep artm en t, A arhus University, Ja n u a ry 1980. J. M ylopoulos, P.A. B ernstein, and H .K .T . W ong. A language facil ity for designing database-intensive applications. A C M Transactions on Database System s, 5(2):185-207, Ju n e 1980. C. Kevin M ccabe. F O R T E Fundam entals. D ilithium Press, Beaver to n , O regon, 1983. J. M cD erm ott. E x tractin g knowledge from ex p ert system s. In Pro ceedings o f the Eighth International Joint Conference on A rtificial Intelligence. IJC A II, 1983. W . M. M ckeem an. P rogram m ing language design. In Com piler Con struction: A n Advanced Course. Springer-V erlag, 1976. D. R. M ilton, L. W . Kirchoff, and B. R. R ow land. A n A L L (l) com piler generator. In Proceedings O f The Sym posium On Compiler C onstruction. ACM SIG PLA N , 1979. H. M ossenbock. Alex - a sim ple an d efficient scanner generator. S IG P L A N Notices, 21(5), 1986. B. J. M ailloux an d J. E. L. Peck. Algol68 as an extensible language. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1969. S tephen M. M cM enam in an d Jo h n F. P alm er. E ssential System s Analysis. Y ourdon Press, 1984. Jam es M ilne N eighbors. Software C onstruction Using Components. P hD thesis, U niversity O f C alifornia, Irvine, C om puter Science De p artm e n t, 1981. Jam es M ilne N eighbors. Draco 1.3 Users M anual, 1984. Jam es M ilne N eighbors. T he D raco approach to constructing soft w are from reusable com ponents. IE E E Transactions On Software Engineering, Septem ber 1984. 114 [Nes81] [Nes82] [Nes83] [Nic69] [NMSW83] [Not71] [Pen86] [PL88] [Poh84] [Pre71] [PW88] [Reg71] [Rep82] J. R. N estor. Idl - interface description language. Technical R eport Cm p-Cs-81-139, Carnegie-M ellon University, C om puter Science De p artm e n t, Septem ber 1981. J. R. N estor. IDL - Interface D escription Language - d raft revision 2. Technical rep o rt, Carnegie-M ellon University, C om puter Science D epaxtm ent, 1982. J. R. N estor. E xtensions to a ttrib u te gram m ars. Technical R eport T1 83-36, T a rta n L aboratories, A pril 1983. Jo h n Nicholls. P L /I com pile tim e extensibility. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1969. Jo h n R. N estor, B hubanesw ar M ishra, W illiam L. Scherlis, and W illiam A. Wulf. Extensions to a ttrib u te gram m ars. Technical Re p o rt T1 83-36, T a rta n L aboratories, Inc., A pril 1983. M. G. Notley. A m odel of extensible language system s. In Pro ceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. T hom as J. Pennello. Very fast L R parsing. S IG P L A N Notices, 1986. Uwe F . P leb an an d P eter Lee. A n autom atically generated, realistic com piler for an im perative program m ing language. In Proceedings O f The Conference On Programing Language Design A n d Im plem en tation. ACM SIG PLA N , 1988. . Ira Pohl. A Book On C. T h e B enjam in/C um m ings P ublishing C om pany, Inc., 1984. C harles J. P renner. T he control stru ctu re facilities of ECL. In Pro ceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. P eter P epper and D avid S. W ile. Local form alism s: A n algebraic view. 1988. S. Crespi Reghizzi. G ram m atical inference for defining extensions. In Proceedings o f the Extensible Languages Sym posium . ACM .SIG PLA N , 1971. T . Reps. O ptim al-tim e increm ental sem antic analysis for syntax- directed editors. In Proceedings o f the Sym posium on the Principles o f Programming Languages. ACM SIG PLA N , 1982. 115 [Rep83] [RKES77] [Ros77] [RSSST78] [S+71] [Sam71] [SB82] [Sch71] [Sco71] [SIG69] [SIG71] [SN87] [Sta69] T hom as W . Reps. Generating Language Based E nvironm ents. M it P ress, 1983. D ouglas T . Ross and Jr. K enneth E . Schom an. S tru ctu red analysis for requirem ents definition. IE E E Transactions On Software E n g i neering, Ja n u a ry 1977. D ouglas T . Ross. S tru ctu red analysis (SA): A language for com m uni cating ideas. IE E E Transactions On Software Engineering, Ja n u a ry 1977. K ari-Jouko R aiha, M ikko Saarinen, E ljas Soisalon-Soininen, and M a rtti T ienari. T h e com piler w riting system H LP (Helsinki L an guage Processor). Technical R eport A-1978-2, D epartm ent O f Com p u te r Science, U niversity O f Helsinki, F in lan d , 1978. N. Suzuki et al. T h e im plem entation of Algol N. In Proceedings of the Extensible Languages Sym posium . ACM SIG PLA N , 1971. Je a n E. Sam m et. A pplication of extensible languages to specialized application languages. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. W illiam S w artout and R o b ert Balzer. O n th e inevitable intertw ining of specification an d im plem entation. C A C M , 2(7), Ju ly 1982. Stephen A. Schum an. A n extensible in terp reter. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. R. S. Scowen. BA BEL, an application of extensible com pilers. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. ACM SIG PLA N . Proceedings o f the Extensible Languages Sym po sium , 1969. ACM SIG PLA N . Proceedings o f the Extensible Languages Sym po sium , 1971. D onald L. Stone an d Jo h n R. N estor. IDL: B ackground an d statu s. S IG P L A N Notices, N ovem ber 1987. T hom as A. S tandish. Some features of P P L , a polym orphic lan guage. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1969. 116 [Sta71] [Sta75] [TEC71] [Tic79] [Tur82] [UDP+82] [WA86] [Wal88] [Weg71] [Wei76] [WF86] [Wil78] [WU83] T hom as A. S tandish. P P L - an extensible language th a t failed. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. T hom as A. S tandish. E xtensibility in program m ing language design. In Proceedings o f the N ational C om puter Conference, 1975. Jr. T . E. C heatham . Extensible languages - w here are we going? In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. W alter F . Tichey. Softw are developm ent control based on m odule in terconnection. In Proceedings o f the Fourth Conference on Software Engineering, pages 29-41. IE E E P ress, S eptem ber 1979. T hom as N. T urba. A facility for th e dow nw ard extension of a high- level language. In Proceedings o f the Com piler C onstruction Sym po sium . ACM SIG PLA N , 1982. J. Uhl, S. D rossopoulou, G. Persch, G. Goos, M. D ausm ann, G. W in- terstein, an d W . K irchegassner. A n A ttrib u te G ram m ar For The Sem antic Analysis O f Ada. Springer-V erlag, 1982. D avid S. W ile an d D ennis G. A llard. W orlds: A n organizing struc tu re for object-bases. 1986. Ja n e t A. W alz. Increm ental evaluation for a general class of circular a ttrib u te gram m ars. In Proceedings O f The Conference On Pro gram m ing Languages Design A n d Im plem entation. ACM SIG PLA N , 1988. Ben W egbreit. A n overview of th e EC L program m ing system . In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. Joseph W eizenbaum . C om puter Pow er and H um an Reason. San Francisco: Freem an, 1976. T erry W inograd an d F ernando Flores. U nderstanding Computers and Cognition. Ablex P ublishing C orporation, 1986. D avid S. W ile. G enerator expressions. Technical R eport 99, U S C /Inform ation Sciences In stitu te, 1978. D avid S. W ile. P ro g ram developm ents: form al explanations of im plem entations. CACM , 26(11), N ovem ber 1983. 117 [Wil86] [Wil87a] [Wil87b] [W JW +75] [Wod71] [Woo71] [Yon71] [Yue87] [ZW85] D avid S. W ile. O rganizing program m ing knowledge in to syntax- d irected experts. In Proceedings o f an International W orkshop on Advanced Programming E nvironm ents, Ju n e 1986. D avid S. W ile. Local form alism s: W idening th e sp ectru m of wide- spectrum languages. In M eertens, editor, Program Specification and Transform ation. Elsevier Science P ublishers B.V.: N orth-H olland, 1987. D avid S. W ile. P O P A R T : Producer o f Parsers and Related Tools, S ystem B u ild ers’ M anual. U S C /Inform ation Sciences In stitu te, 4676 A dm iralty Way, M arina del Rey, CA, 90292, 1987. W illiam W ulf, R ichard K. Johnsson, C harles B. W einstock, Steven O. H obbs, an d C harles M. Geschke. The Design O f A n O ptim izing Compiler. A m erican Elsevier P ublishing Com pany, Inc., 1975. P. L. W oden. A syntax m acro processor. In Proceedings o f the E x tensible Languages Sym posium . ACM SIG PLA N , 1971. Jo h n D. Wooley. M enelaus: A system for m easurem ent of th e exten sible language proteus. In Proceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. N. Yoneda. T he description a n d th e stru ctu re of Algol N. In Pro ceedings o f the Extensible Languages Sym posium . ACM SIG PLA N , 1971. K ai Yue. A U ser’ s Guide to the Zeta-Popart Editor. U S C /In fo rm atio n Sciences In stitu te, 4676 A dm iralty Way, M arina del Rey, CA, 90292, 1987. S tanley B. Zdonik an d P eter W egner. A d atab ase approach to lan guages, libraries and environm ents. In Proceedings o f the W ork shop on Software Engineering E nvironm ents fo r Programming-in- the-Large, Harwichport, M assachusetts, pages 89— 112, Ju n e 1985. 118 Appendix A LADE LA D E (LA nguage D efinition E nvironm ent) is a co m p iler/in terp re ter generator de signed to su p p o rt all phases of language design including lexing, parsing, sem antic analysis, tra n slatio n , an d code generation. It com bines sta te of th e a rt language design techniques w ith efficient com pilation m ethodologies in a way th a t will m ake th e tool useful for b o th rap id prototyping for experim entation an d for design of efficient co m p iler/in terp reters for prod u ctio n use. LA D E su p p o rts th e generation of th e following phases of com pilation from th eir respective specification languages: • a lexer is specified by lexical item s in term s of sequences of characters; • an L A L R (l) p arser is specified by a g ram m ar in term s of productions; • sem antic analysis, tra n slatio n , an d code generation is defined by an a ttrib u te action set. These p a rts are th e n b o u n d to g eth er to form a com piler or in terp reter. LA D E is actually a collection of in teg rated tools each of which is, in its own rig h t, a com piler. For exam ple, a parser co n stru cto r generates a parser from a specification in th e form of a g ram m ar, while an a ttrib u te g ram m ar is com piled in to a program w hich perform s static analysis an d tran slatio n . M ost p ro d u ctio n com piler generators (e.g. Yacc) handle only th e com piler front end an d provide ‘hooks’ for th e user of th e tool, th e com piler w riter, to code th e tra n sla tio n and code generation phases of com pilation. In th e case of Yacc, a C statem en t is associated w ith th e red u ctio n of each production during 119 LA LR parsin g which is executed by th e com piler during th e parse of a source language program . A lthough th is m eth o d is as efficient as th e C com piler in term s of m achine resources, it leaves a trem endous b u rd en on th e com piler w riter who m u st encode th e tran slatio n of th e source language into th e ta rg e t language in C and, th u s, is inefficient in term s of h u m an resources. O n th e o th er h and, a m ore pow erful an d expressive m eth o d o f specifying the static sem antics an d th e tra n slatio n of a language is th e a ttrib u te gram m ar. B ut th e a ttrib u te gram m ar, in its m ost p u re form , is extrem ely inefficient an d w asteful o f m achine resources because, in all b u t th e m ost triv ial languages, it tends to require: • th e construction of a parse tree as an in term ed iate rep resen tatio n of th e program ; • m ultiple passes over th is p arse tree; or • storage of th e a ttrib u te s of th e p arse tree betw een passes. T here have been a few a tte m p ts at rem edies in th e academ ic com m unity (see th e section on previous w ork) b u t m ost work has been on studying th e power, not th e efficiency, of th e a ttrib u te g ram m ar approach. M oreover, no production versions of a a ttrib u te g ram m ar based com piler generator exist. T h e closest to a p ro d u ctio n a ttrib u te g ram m ar based com piler generator is L inguist-86 w hich solved th e space problem s by dum ping th e parse tree an d a ttrib u te s to disk at the expense of m ore com putation tim e. 120 Appendix B Grammar A GRAMMAR defines a parser, abstract syntax, and a parse tree d a ta structure w ith parse nodes corresponding to the nonterm inals of the formalism and fields of the parse node corresponding to the nonterm inals of the right hand side of the production defining the nonterm inal to which the parse node corresponds. Prim itive nonterm inals, identifiers, string literals, num ber literals, etc. have one field, a lexeme, which is literally the substring of the input which the lexer returned. A GRAMMAR defines a parser which takes as input a stream of lexemes and constructs a parse tree and invokes the sem antic actions defined by the translator on them . Syntactically, a GRAMMAR definition begins w ith a gram m ar_declaration. B .l grammar .declaration A g ram m ar_ d eclaratio n gives the nam e of the gram m ar and a d e c la ra tio n _ se q u e n c e . grammar_declaration IS "GRAMMAR" identifier "IS" declaration_sequence "END" identifier#again ; 121 B.2 declaration A d e c la r a tio n .s e q u e n c e is a sequence of d e c la r a tio n s . A d e c l a r a t i o n is one of four form s. declaration_sequence IS [declaration_sequence] declaration ; declaration IS start_declaration I terminal_declaration I lexeme.declaration I production.declaration ; B.3 start-declaration A s t a r t . d e c l a r a t i o n nam es a set of nonterm inals a t w hich parsin g of a string in th e form alism specified by th e g ram m ar m ay begin. T he first no n term in al specified is th e default s ta rt nonterm inal. If parsing is to begin a t a n o n term in al o ther th a n th e first, th e parser m ust be directed as to w hich n o n term in al a p a rtic u la r string is to be p arsed b u t noth in g o th er th a n one declared as a s ta rt m ay be used as a directive. start.declaration IS "START" identifier.sequence ; B.4 terminal_declaration A terminal.declaration nam es a non-lexem e, n o n -co n stan t sym bol a t which parsin g term inates. N on-lexem e, non-constant term in al sym bols are used to iden tify sym bols whose rep resen tatio n depends on its use in a recursive com position of form alism s. T h e term in al m u st b e represented by a m eta-variable. terminal.declaration IS "TERMINAL" identifier ; 122 B.5 production_declaration A p r o d u c tio n _ d e c la r a tio n specifies th e nonterm inal and an e x p r e s s io n for the right h a n d side of a production in th e gram m ar. production_declaration IS identifier "IS" expression ; B.6 expression, term, factor A n e x p r e s s io n is a sequence o f term s w hich m ay be alternatively expanded in m atching an in p u t string. A te rm is a sequence of f a c t o r s w hich m ust m atch th e in p u t strin g sequentially. A f a c t o r is one of four alternatives. expression IS [expression "I"] term ; term IS [term] factor ; factor IS optional I constant I name I nested_expression ; B.7 optional A n o p tio n a l is a te rm w hich m ay or m ay n o t be expanded to m atch th e in p u t string. optional IS " [" expression "]" ; 123 B.8 constant A c o n s ta n t is a s t r i n g _ l i t e r a l which m ust m atch th e in p u t string literally. A c o n s ta n t m ay specify a field of th e production w hich will be set to a non-nil value w hen th e m atch is m ade and will be left false otherw ise. T his is useful w hen the co n stan t is enclosed in an o p tio n a l or as an altern ativ e in an e x p re s s io n . c o n s ta n t IS s t r i n g _ l i t e r a l ["# " i d e n t i f i e r ] ; B.9 name A name is an i d e n t i f i e r identifying a nonterm inal of th e g ram m ar and, option ally, a suffix i d e n t i f i e r . Each use of a nonterm inal on th e rig h t-h an d side of a pro d u ctio n creates a sep arate syntactic field of th e p arse node using th e nam e of th e nonterm inal as th e nam e of the field. T he suffix i d e n t i f i e r is used to distin guish m ultiple uses of th e sam e nonterm inal in th e sam e p ro d u ctio n definition so th a t each field of th e parse node will have a different nam e. name IS i d e n t i f i e r ["# " i d e n t i f i e r # s u f f i x ] ; B.10 nested_expression A n e s te d .e x p r e s s io n is an e x p re s s io n . n e s te d .e x p r e s s io n IS " (" e x p r e s s io n " ) " ; 124 Appendix C Attribute Action Set A n ATTRIBUTE ACTION SET defines a set of a ttrib u te s, inherited an d synthesized, for each n o n term in al of th e language defined by th e GRAMMAR. W hen activated by th e p arser generated by th e GRAMMAR, th e a ttrib u te action set com putes the values of th e a ttrib u te s. A n ATTRIBUTE ACTION SET m ay also define an interface. Syntactically, an ATTRIBUTE ACTION SET definition begins w ith a attribute_action_set_declaration. C. 1 attribute_act ion_set .declaration A a t t r i b u t e _ a c t i o n _ s e t _ d e c l a r a t i o n specifies th e nam e of th e a ttrib u te ac tion set, a list of a ttrib u te s w hich th e a ttrib u te action set m ay share w ith other sublanguages in th e source g ram m ar definition, th e nam e of th e source language, th e nam e of th e ta rg et language, an d a d e c l a r a t i o n seq u en ce. attribute_action_set.declaration IS "ATTRIBUTE" "ACTION" "SET" identifier ["FROM" identifier#from] ["TO" identifier#to] "IS" declaration.sequence "END" identifier#again ";" ; 125 C.2 declaration A d e c la r a tio n .s e q u e n c e is a sequence of declarations. A d e c l a r a t i o n is one of eight form s. declaration_sequence IS [declaration_sequence] declaration ; declaration IS start.declaration I use.declaration I nonterminal.type.declaration I nonterminal.declaration I attribute.declaration I constraint.declaration I other.declaration ; C.3 start-declaration A start.declaration is an expression.sequence w hich is evaluated after static a ttrib u te s have been com puted. In an in terp reter, th e s ta rt declaration will specify an dynam ic a ttrib u te of th e root node to begin execution. result.declaration IS "START" expression.sequence ; C.4 use_declaration A n use.declaration provides access to th e a ttrib u te definitions, nonterm inal types, an d global declarations of th e interface. use.declaration IS "USE" identifier ; 126 C.5 nonterminal_type_declaration A nonterminal.type.declaration is an identifier which designates the name of the nonterminal type and a sequence of identifiers defining the attributes associ ated with the nonterminal type. A nonterminal.type.declaration may appear only in an interface. nonterminal.type.declaration IS "NONTERMINAL" "TYPE" identifier IS identifier.sequence ; identifier.sequence IS [identifier.sequence ","] identifier ; C.6 nonterminal_declaration A nonterminal.declaration is an identifier which designates the nonterminal (from the grammar associated with the attribute action set) and another identifier which defines the type of the nonterminal from a used interface. nonterminal.declaration IS "NONTERMINAL" identifier "IS" identifier#type j C.7 attribute.declaration An attribute.declaration specifies the class name of an attribute and, option ally, an action.sequence. An attribute will be either synthesized or inherited and will be either static or dynamic. attribute.declaration IS synthesized.inherited static.dynamic "ATTRIBUTE" identifier ["IS" action.sequence "END" identifier#again] ; synthesized.inherited IS "SYNTHESIZED"#synthesized I 127 "INHERITED"#inherited ; static.dynamic IS "STATIC"#static I "DYNAMIC"#dynamic ; C.8 action A n a c tio n .s e q u e n c e is a sequence of a c tio n s . A a c tio n specifies th e nam e of a n o n term in al of th e source language an d an e x p re s s io n .s e q u e n c e w hich defines th e m eaning of th a t nonterm inal. action IS identifier.sequence ["IS" expression.sequence] ";" ; C.9 other .declaration A n o t h e r .d e c l a r a t i o n is an e x p r e s s io n designating an underlying Com m on Lisp declaration. other.declaration IS expression ";" ; C.10 expression A n e x p re s s io n .s e q u e n c e is a sequence of e x p re s s io n s . A n e x p r e s s io n has ten form s. expression.sequence IS [expression.sequence ","] expression ; expression IS reference.expression | literal.expression I string.literal I number.literal I 128 c h a r a c te r I l i s t | q u o te d .e x p re s s io n I b a c k q u o te d .e x p re s s io n I u n q u o te d .e x p re s s io n I u n q u o t e d .l i s t .e x p r e s s i o n ; C .ll reference .expression A n r e f e r e n c e .e x p r e s s io n is a name designating either a variable, function, or parse node; optionally, an e x p re s s io n .s e q u e n c e , th e p aram eters of a function call; and, optionally, an a t t r ib u te .s e q u e n c e . A n a t t r i b u t e .s e q u e n c e is a sequence of identifiers w hich designate a ttrib u te s th e p arse node. r e f e r e n c e .e x p r e s s io n IS name [" (" # p a re n [e x p re s s io n .s e q u e n c e ] " )" ] [ a t tr i b u t e .s e q u e n c e ] ; name IS [" :" # k e y ] i d e n t i f i e r [ " : " i d e n t i f i e r t a g a i n ] ["# " i d e n t i f i e r t s u f f i x ] ; a t t r i b u t e .s e q u e n c e IS [ a ttr i b u t e .s e q u e n c e ] i d e n t i f i e r ; C.12 literal_expression A l i t e r a l . e x p r e s s i o n specifies a substring in th e ta rg et language of the tran slatio n . T h e i d e n t i f i e r specifies th e nonterm inal of th e ta rg e t language, th e s t r i n g . l i t e r a l specifies th e substring, except for m etavariables, and th e e x p re s s io n .s e q u e n c e specifies th e value of th e m etavariables of th e substring in left to rig h t order. l i t e r a l . e x p r e s s i o n IS "<" i d e n t i f i e r s t r i n g . l i t e r a l [e x p re s s io n .s e q u e n c e ] ">" ; 129 C.13 Other Expressions T he o th er expressions, exactly equivalent to th e corresponding underlying Com m on Lisp form s. c h a r a c t e r IS " # \" i d e n t i f i e r ; l i s t IS " [ " e x p re s s io n .s e q u e n c e " ; q u o te d .e x p r e s s io n IS e x p r e s s io n ; b a c k q u o te d .e x p re s s io n IS u t " e x p r e s s io n ; u n q u o te d .e x p re s s io n IS "fi" e x p r e s s io n ; u n q u o t e d .l i s t .e x p r e s s i o n IS e x p r e s s io n ; 130 Appendix D Lexer A LEXER defines th e prim itive nonterm inals of a language in term s of th e characters w hich co n stitu te them . W ith th e reserved w ords of th e language, a LEXER defines a lexer w hich tra n slates a tex t file into a stream of lexemes w hich are h an d ed to th e parser. Syntactically, a lexer definition begins w ith a lexer.declaration. D .l lexer_declaration A l e x e r _ d e c la r a tio n specifies th e nam e of th e lexer and a d e c la r a tio n .s e q u e n c e . lexer.declaration IS "LEXER" identifier "IS" declaration.sequence "END" identifier#again ; D.2 declaration A d e c la r a tio n .s e q u e n c e is a sequence of d e c la r a tin s . A d e c l a r a t i o n is one of six form s. declaration.sequence IS [declaration.sequence] declaration ; declaration IS 131 comment.declaration I end_of_line_declaration I delimiter_declaration I keyword.declaration I character.set.declaration I lexeme_declaration ; D.3 comment .declaration A comment .d e c l a r a t i o n specifies a s t r i n g . l i t e r a l w hich, in th e file being lexed, signals th e beginning of a com m ent w hich is discarded by th e lexer. T he end of th e line designates th e end of a com m ent. comment.declaration IS "COMMENT" string.literal ; D.4 end_of_line .declaration A n end.of .line.declaration specifies a reserved w ord to su b stitu te for end of line ch aracters in th e in p u t tex t to th e lexer. If none is specified th en end of line ch aracters are tre a te d as blanks. end.of.line.declaration IS "EOLN" string.literal ";" ; D.5 delimiter.declaration A delimiter.declaration specifies th e opening and, optionally, closing m eta sym bols w hich signal to th e lexer th e beginning of a n o n term in al m etavariable. If no right side is specified th en th e right side is th e reverse of th e left side. If no delimiter.declaration is specified th en th e default is M ’ for left and right. delimiter.declaration IS "NONTERMINAL" string_literal#lteft string.literal#right] ; 132 D.6 char act er_set .declaration A character_set_declaration specifies a character set by a factor. character.set.declaration IS "CHAR" identifier "IS" factor ; D.T lexeme .declaration A lexeme_declaration specifies a lexem e available to th e g ram m ar of a language using th e lexer by an expression. lexeme_declaration IS "LEXEME" identifier "IS" expression ; D.8 expression, term, and factor A n e x p r e s s io n is a sequence of alternative term s. A te rm is a sequence of f a c to r s w hich m ust be m atched against th e in p u t stream one by one. A f a c t o r is one of eight form s. expression IS [expression "I"] term ; term IS [term] factor ; factor IS identifier I string.literal I nested.expression I optional.expression I repetition.expression I character.expression I range J operation ; 133 D.9 nested_expression A n e s te d .e x p r e s s io n is an e x p re s s io n . nested.expression IS "(" expression ")" ; D.10 optional_expression A n o p tio n a l.e x p r e s s io n is an e x p r e s s io n which m ay or m ay not m atch th e in p u t string. optional.expression IS expression ”]" ; D.ll repet ition_expression A r e p e t itio n _ e x p r e s s io n is an e x p r e s s io n which m ust m atch th e in p u t at least once a n d m ay m atch m ore th a n once. repetition_expression IS expression "}" ; D.12 range A ra n g e specifies a range of c h a r a c t e r . l i t e r a l s of w hich th e in p u t character m u st be a m em ber. If no second c h a r a c t e r . l i t e r a l is specified th e n th e in p u t ch aracter m ust m atch exactly. For purpose of ranges, th e ch aracter set is assum ed to be ascii. ra n g e IS character_literal#from character_literal#to] ; 134 D.13 operation A n o p e r a tio n specifies a character set by an u n s ig n e d .o p e r a tio n . If th e reserved w ord preceeds th e u n s ig n e d .o p e r a tio n th en th e o p e r a tio n specifies the set of characters n o t in th e set specified by th e u n s ig n e d .o p e r a tio n . operation IS "<" ["-"#minus] unsigned.operation ">" ; D.14 unsigned.operation A n u n s ig n e d .o p e r a tio n is a sequence of f a c t o r s seperated by o p e ra to rs . From left to rig h t, a ‘+ ’ o p erato r indicates an add itio n to th e character set while a indicates a rem oval from th e character set specified by th e u n s ig n e d .o p e r a tio n . unsigned.operation IS [unsigned.operation operator] factor ; operator IS "+"#plus I "-"#minus ; 135 Appendix E Module Interface Formalism A MIF, m odule interface formalism, defines the interaction of modules in a m ulti form alism specification environm ent. Syntactically, a MIF begins with a m o d u le _ d e c la ra tio n . E .l module_declaration A m o d u le _ d e c la ra tio n defines a m odule by an i d e n t i f i e r w hich gives th e nam e an d a d e f i n i t i o n w hich is either a sim p le _ d e f i n i t i o n or a com plexdef i n i t i o n . module.declaration IS "MODULE" identifier [definition] ; definition IS simple_definition I complex_definition ; E.2 simple .definition A simple_def inition defines a primitive module specified in the formalism indi cated by the identifier. simple_definition IS identifier ; 136 E.3 complex.definition A c o m p le x .d e f in itio n defines a non-prim itive m odule w hich is fu rth e r defined by sub-m odules in th e d e c la r a tio n .s e q u e n c e . c o m p le x .d e f in itio n IS "IS " d e c la r a tio n .s e q u e n c e "END" i d e n t i f i e r # a g a i n ; E.4 declaration A d e c la r a tio n .s e q u e n c e is a sequence of d e c la r a tio n s . A d e c l a r a t i o n is either a m o d u le .d e c la ra tio n or an i n t e r f a c e . d e c l a r a t i o n . d e c la r a tio n .s e q u e n c e IS [d e c la ra tio n _ s e q u e n c e # s u b ] d e c l a r a t i o n ; d e c l a r a t i o n IS m o d u le .d e c la r a tio n I i n t e r f a c e . d e c l a r a t i o n ; E.5 interface .declaration A n i n t e r f a c e .d e c l a r a ti o n identifies an interface used by form alism s of m odules w ithin th e scope of current m odule. T h e scope of th e interface is lim ited to the scope of cu rren t m odule an d is n o t accessible by outside m odules. All interfaces of th e form alism s of th e m odules of a MIF specification m u st have access to exactly one of each interface required. i n t e r f a c e . d e c l a r a t i o n IS "INTERFACE" i d e n t i f i e r " ; " ; 137 E.6 MIF Grammar GRAMMAR mif IS START module.declaration ; LEXEME identifier ; module.declaration IS "MODULE" identifier [definition] ; definition IS complex.definition I simple.definition ; complex.definition IS "IS" declaration.sequence "END" identifier#again ; simple.definition IS identifier ; declaration.sequence IS [declaration.sequence#sub] declaration declaration IS module.declaration I interface.declaration ; interface.declaration IS "INTERFACE" identifier ";" ; EN D m if ; E.T MIF INTERFACE ATTRIBUTE ACTION SET mif.interface IS defstruct(module, parent, [module.table, make_hash_tableO] , — hash on module name of nonterminal module [interface.table, make.hash.tableQ] , — hash on interface name of interface object ) ; END mif.interface ; E.8 MIF Interpreter ATTRIBUTE ACTION SET mif.interpreter IS USE mif.interface ; INHERITED STATIC ATTRIBUTE module IS module.declaration IS make_module_declaration( :parent, module.declaration.module) ; END module ; SYNTHESIZED STATIC ATTRIBUTE setup IS identifier IS intern(identifier.lexeme, "USER") ; module.declaration IS setf(gethash(identifier.setup,module.table), 139 module.declaration.module), setf(gethash(identifier.setup, module_modiile_table( module.parent(module.declaration.module))), module.declaration.module), module.declaration.module ; function.declaration IS setf(gethash(identifier.setup, module.funct ion.t able( module.parent(function.declaration.module))), or ( gethash(identifier.setup, module.function.table( function.declaration.module)) make.functionO)) ; type.declaration IS setf(gethash(identifier.setup, module.type.table( module.parent(type.declaration.module))), or( gethash(ident if i er.s etup, module.type.table(type.declaration.module)) make_type())) ; variable.declaration IS setf(gethash(identifier.setup, module.variable.table( module.parent(variable.declaration.module))), or ( gethash(identifier.setup, module.variable.table( variable.declaration.module)) make.variableO)) ; END setup ; 140 START setf(module, module.declaration.setup) END mif.interpreter ; Appendix F Grog F .l Grog Base Formalism Interface ATTRIBUTE ACTION SET grog.base IS export(’[block,block.parent,block_table,make_block]) ; export(* [grog_package,global_block,entry_of_symbol]) ; export (* [frame,frame_values ,make_frame] ) ; defstruct(block, parent, table(make_hash_table())) ; defvar(grog_package, *package*) ; defvar(global.block, make_block()) ; defun(entry.of.symbol,[symbol,block], cond( [block, or( gethash(symbol,block.table(block)), entry.of.symbol(symbol,block_parent(block)))], [t, gethash(symbol,block.table(global.block))])) ; defun(setf(entry.of.symbol),[entry,symbol,block], cond( [block, setf(gethash(symbol,block.table(block)),entry)], [t, setf(gethash(symbol,block.table(global.block)), entry)])) ; defstruct(frame, values) ; INHERITED STATIC ATTRIBUTE block ; INHERITED DYNAMIC ATTRIBUTE frame ; INHERITED DYNAMIC ATTRIBUTE call.frame j SYNTHESIZED DYNAMIC ATTRIBUTE execute ; SYNTHESIZED DYNAMIC ATTRIBUTE evaluate ; SYNTHESIZED STATIC ATTRIBUTE declare ; NONTERMINAL TYPE execution IS call.frame, execute ; NONTERMINAL TYPE evaluation IS call.frame, evaluate ; NONTERMINAL TYPE declaration IS frame, execute, declare END grog.base ; F.2 Expression Grammar GRAMMAR exp IS LEXEME identifier ; LEXEME number.literal ; START expression ; expression.sequence IS [expression_sequence#sub ","] expression ; expression IS ["N0T"#not3 logicand ; logicand IS [logicand#sub logical.operator] relation ; logical.operator IS "AND"#and I "OR"#or ; relation IS simple_expression#left [relational_operator simple_expression#right] ; relational_operator IS "="#equal I "/="#not_equal I "<"#less I "<="#less_or_equal I "V^greater I ">="#greater_or.equal ; simple_expression IS [adding.operator] term ; adding_operator IS "+"#add I "-"#subtract ; term IS [term#sub adding_operator] simple_term ; simple.term IS [simple_term#sub multiplying.operator] factor ; multiplying.operator IS "*"#multiply I "/"tdivide I "MOD’^mod | "REM"#rem ; factor IS [factor#sub "**"] primary ; primary IS number.literal I identifier I nested.expression I function.invocation ; nested.expression IS 144 "(" expression ; function.invocation IS identifier 1 1 (" [parameter_expression_sequence] ")" ; parameter_expression_sequence IS [parameter.expression_sequence#sub expression ; END exp ; F.3 Expression Interpreter ATTRIBUTE GRAMMAR exp_interpreter FROM exp IS USE grog.base ; NONTERMINAL expression IS evaluation ; INHERITED DYNAMIC ATTRIBUTE call.frame IS function.invocation IS make.frame() ; END frame ; INHERITED DYNAMIC ATTRIBUTE frame ; INHERITED STATIC ATTRIBUTE block ; SYNTHESIZED STATIC ATTRIBUTE symbol IS identifier IS intern(string_upcase(lexeme),grog_package) ; END symbol ; SYNTHESIZED STATIC ATTRIBUTE string IS identifier IS lexeme ; END string ; SYNTHESIZED DYNAMIC ATTRIBUTE evaluate IS expression.sequence IS when(expression_sequence#sub, expression_sequence#sub.evaluate) , expression.evaluate ; expression IS cond( [not, 145 not(logicand.evaluate)], [t, logicand.evaluate]) ; logicand IS cond( [logicand#sub, funcall( logical.operator.evaluate, logicand#sub.evaluate, relation.evaluate)], [t, relation.evaluate]) ; logical.operator IS cond( [and, function(and)], [or, function(or)]) ; relation IS cond( [simple_expression#right, funcall( relational.operator.evaluate, simple_expression#left.evaluate, simple_expression#right.evaluate)], [t, simple.expression#left.evaluate]) ; relational.operator IS cond( [equal, function(=)] , [not.equal, function(/=)], [less, funct ion ( ' / , < ' / , ) ] , [less.or.equal, function('/,<='/)] , [greater, funct ion (%>'/£)] , [greater.or.equal, functionC/,>='/.)] ) ; simple.expression IS cond( [adding.operator, funcall( adding.operator.evaluate, term.evaluate)], [t, t erm.evaluat e]) ; adding.operator IS cond( [add, function(+)], [subtract, function(-)]) , * term IS cond( [term#sub, funcall( adding.operator.evaluate, term#sub.evaluate, simple.term.evaluate)], [t, simple.term.evaluate] ) ; simple_term IS cond( [simple_term#sub, funcall( multiplying.operator.evaluate, simple_term#sub.evaluate, factor.evaluate)], [t, factor, evaluate]) ; multiplying_operator IS condC [multiply, function(*)], [divide, function(lambda([x,y], floor(/(x,y))))], [mod, function(mod)], [rem, function(rem)]) ; factor IS cond( [factor#sub, floor(exp(*(log(factor#sub.evaluate), primary.evaluate)))], Ct, primary.evaluate]) ; primary IS cond( [number_literal, number_literal.evaluate], [identifier, identifier.evaluate], [nested.expression, nested.expression.evaluate], [function.invocation, function.invocation.evaluate]) number.literal IS read.from.string(lexeme) ; identifier IS nth(entry_of.symbol(identifier.symbol,identifier.block), frame.values(identifier.frame)) ; nested_expression IS expression.evaluate ; function_invocation IS when(parameter_expression_sequence, parameter_expression_sequence.evaluate), cond( [entry_of_symbol(identifier.symbol, function_invocation.block), entry_of.symbol(identifier.symbol, function.invocation.block).evaluate], Ct, apply(intern_lexeme(identifier.string,’lisp), frame.values (function.invocation.call.frame))]) ; parameter.expression.sequence IS when(parameter_expression_sequence#sub, parameter.expression_sequence#sub.evaluate), push(expression.evaluate, frame.values (parameter.expression.sequence.call.frame)) ; END evaluate ; START expression.evaluate ; END exp.interpreter ; F.4 Statement Grammar GRAMMAR stmt IS LEXEME identifier ; START statement.sequence ; TERMINAL expression ; statement.sequence IS [statement.sequence#sub] statement ; s ta te m e n t IS a s s ig n m e n t.s ta te m e n t | if.statement I loop.statement I exit.statement 1 return.statement I procedure.invocation ; assignment.statement IS identifier expression ; if.statement IS "IF" expression "THEN" statement.sequence ["ELSE" statement_sequence#else] "END" "IF" ; loop.statement IS "LOOP" statement.sequence "END" "LOOP" ; exit.statement IS "EXIT" ; return.statement IS "RETURN" expression ; procedure.invocation IS identifier ["(" parameter.expression.sequence ")"] parameter.expression.sequence IS [parameter.expression_sequence#sub ","] expression END stmt ; F.5 Statement Interpreter ATTRIBUTE GRAMMAR stmt.interpreter FROM stmt IS USE grog.base ; NONTERMINAL statement.sequence IS execution ; NONTERMINAL expression IS evaluation ; INHERITED DYNAMIC ATTRIBUTE call.frame IS procedure.invocation IS make.frameO ; END frame ; defstruct(exit, ing) INHERITED DYNAMIC ATTRIBUTE exit IS loop_statement IS make_exit() ; END exit ; SYNTHESIZED STATIC ATTRIBUTE symbol IS identifier IS intern(string.upcase(lexeme),grog_package) ; END symbol ; SYNTHESIZED STATIC ATTRIBUTE string IS identifier IS lexeme ; END string ; SYNTHESIZED DYNAMIC ATTRIBUTE execute IS statement.sequence IS when(statement_sequence#sub, statement_sequence#sub.execute), when(not(and(statement_sequence.exit, exit_ing(statement_sequence.exit))), statement.execute) ; statement IS cond( [assignment.statement, assignment.statement.execute], [if.statement, if.statement.execute], [loop.statement, loop.statement.execute], [exit.statement, exit_statement.execute], [return.statement, return.statement.execute] , [procedure.invocation, procedure.invocation.execute]) ; assignment.statement IS setf ( nth(entry.of.symbol(ident ifier.symbol, identifier.block), frame.values(assignment.statement.frame)), expression.evaluate) ; if.statement IS 150 cond( [expression.evaluate, statement_sequence.execute], [statement_sequence#else, statement_sequence#else.execute]) ; loop.statement IS loop( statement.sequence.execute, when(exit_ing(loop.statement.exit), return(nil))) exit.statement IS setf(exit_ing(exit_statement.exit),t) ; return.statement IS expre s s i on.evaluat e ; procedure.invocation IS when(parameter.expression.sequence, parameter.expression.sequence.execute), cond( [entry.of.symbol(identifier.symbol, procedure.invocation.block), entry.of.symbol(identifier.symbol, procedure.invocation.block).execute], Ct, apply(intern.lexeme(identifier.string,’lisp), frame.values (procedure.invocation.call.frame))]) ; parameter.expression.sequence IS when(parameter.expression_sequence#sub, parameter_expression_sequence#sub.execute), push(expression.evaluate, frame.value s (parameter.expression.sequence.call.frame)) ; END execute ; START statement.sequence.execute ; END stmt.interpreter ; F.6 Declaration Grammar GRAMMAR decl IS LEXEME identifier ; START program ; TERMINAL statement.sequence ; TERMINAL expression ; program IS "PROGRAM" declaration.part "BEGIN" st at ement _ s equence "END" ; subprogram.declaration IS function^declaration I procedure.declaration ; function.declaration IS "FUNCTION" identifier subprogram.body ; procedure.declaration IS "PROCEDURE" identifier subprogram.body ; subprogram.body IS ["(" formal.parameter.sequence ")"] declaration.part "BEGIN" statement.sequence "END" identifier#again ; formal.parameter.sequence IS [formal_parameter_sequence#sub ","] identifier ; declaration.part IS [obj ect.declaration.sequence] [subprogram.declaration.sequence] ; object.declaration.sequence IS [object_declaration_sequence#sub] object.declaration object.declaration IS identifier expression] ; subprogram.declaration.sequence IS [subprogram.declaration.sequence#sub] subprogram.declaration ; END d e c l ; F.7 Declaration Interpreter ATTRIBUTE GRAMMAR decl.interpreter FROM decl IS USE grog.base ; NONTERMINAL statement.sequence IS execution ; NONTERMINAL expression IS evaluation ; NONTERMINAL declaration IS declaration ; INHERITED STATIC ATTRIBUTE block IS program IS make_block(:parent.program.block) ; subprogram.body IS make.block(:parent,subprogram.body.block) ; END block ; defstruct(index, value(O)) ; INHERITED STATIC ATTRIBUTE variable.index IS program IS make_index() ; subprogram.body IS make_index() ; END variable.index ; INHERITED DYNAMIC ATTRIBUTE frame IS program IS make.frameO ; subprogram.body IS make.frameO ; END frame ; SYNTHESIZED STATIC ATTRIBUTE symbol IS identifier IS intern(string.upcase(lexeme),grog_package END symbol ; SYNTHESIZED STATIC ATTRIBUTE string IS identifier IS lexeme ; END string ; SYNTHESIZED STATIC ATTRIBUTE declare IS procedure_declaration IS setf(entry_of.symbol(identifier.symbol, procedure.declaration.block), procedure_declaration) ; function.declaration IS setf(entry.of.symbol(identifier.symbol, function.declaration.block), function.declaration) ; formal.parameter.sequence IS setf(entry.of.symbol(identifier.symbol, formal.parameter.sequence.block), index.value (formal.parameter.sequence.variable.index)), incf(index.value (formal.parameter.sequence.variable.index)) ; declaration.part IS when(obj ect.declaration.sequence, obj ect.declaration.sequence.declare) , when(subprogram.declarat ion.sequence, subprogram.declaration.sequence.declare) ; object.declaration.sequence IS when(obj ect_declaration_sequence#sub, obj ect_declaration_sequence#sub.declare), object.declaration.declare ; object.declaration IS setf(entry.of.symbol(identifier.symbol, object.declaration.block), index.value(object.declaration.variable.index)), incf(index.value(obj ect.declaration.variable.index)) subprogram.declaration.sequence IS when(subprogram.declaration.sequence#sub, subprogram_declaration_sequence#sub.declare), subprogram.declaration.declare ; END declare ; SYNTHESIZED DYNAMIC ATTRIBUTE execute IS program IS declaration.part.execute, statement.sequence.execute ; procedure.declaration IS subprogram.body.execute ; subprogram.body IS setf(frame.values(subprogram.body.frame), frame.values(subprogram.body.call.frame)), declaration.part.execute, statement.sequence.execute ; declaration.part IS when(obj ect.declaration.sequence, object.declaration.sequence.execute) ; object.declaration.sequence IS when(obj ect.declaration_sequence#sub, obj ect.declaration.sequence.execute), object.declaration.execute ; object.declaration IS push( cond( [expression, expression.evaluate], [t, 0]) , frame.values(obj ect.declaration.frame)) ; END execute ; SYNTHESIZED DYNAMIC ATTRIBUTE evaluate IS function.declaration IS subprogram.body.execute ; END evaluate ; START program.execute ; END decl.interpreter ; Appendix G Survey Analysis Formalisms A client wishes to print graphic pie and bar charts from d ata he has collected about people’s education and income. Three interfaces have been defined by the dom ain designer and are contained in the dom ain library: • STANDARD INTERFACE is an interface of p ro c e d u re _ d e c la ra tio n s and fu n c tio n _ d e c la ra tio n s w ith execution and evaluation operations. • DATABASE INTERFACE is an interface of r e la tio n _ d e c la r a tio n s with query, update, and generate operations. • DEVICE INTERFACE is an interface of d e v ic e _ d e c la ra tio n s w ith graphic operations. Among the formalisms which the dom ain designer has previously provided in the dom ain library are: • DDL is a formalism for defining relational databases which pro duces r e l a ti o n .d e c l a r a ti o n s for DATABASE INTERFACE and consumes p ro c e d u re .d e c la ra tio n s and f u n c tio n .d e c la r a tio n s from STANDARD INTERFACE. • DML is a relational d a ta m anipulation form alism which produces p ro c e d u re _ d e c la ra tio n s and fu n c tio n _ d e c la ra tio n s for STANDARD IN TERFACE and consumes r e la tio n _ d e c la r a tio n s from DATABASE INTER FACE. 156 • STAT is a statistics calculation formalism which both produces and con sumes p ro c e d u re _ d e c la ra tio n s and f u n c tio n .d e c la r a tio n s from and for STANDARD INTERFACE. The STAT c ro s s ta b _ d e c la ra tio n s and re g re s s io n _ d e c la ra tio n s and the in it_ d e c la r a tio n are treated as fu n c tio n _ d e c la ra tio n s and p ro c e d u re _ d e c la ra tio n s , respectively, for purposes of interfacing through STANDARD INTERFACE. • GRAPH is a graphics generation language which produces p ro c e d u re „ d e c la ra tio n s and fu n c tio n _ d e c la ra tio n s for STANDARD IN TERFACE consuming d e v ic e _ d e c la ra tio n s from DEVICE INTERFACE. The GRAPH g ra p h _ d e c la ra tio n s are treated as p ro c e d u re _ d e c la ra tio n s for purposes of interfacing through STANDARD INTERFACE. • DEVICE is a graphics device description language which produces d e v ic e _ d e c la ra tio n s for DEVICE INTERFACE. • GROG: a general purpose program m ing language. Modules use and define pro ced u res and fu n c tio n s from and for STANDARD INTERFACE. The system ’s designer writes a specification to solve the problem which the client has presented in six modules using the above formalisms from the domain library. G .l m l DDL ml IS RELATION person (name:string, education:integer, income:real) ; RELATION education (education:real) := PROJECT person (education) ; RELATION income (education:integer, income:real) := PROJECT person (education, income) ; END ml ; 157 G.2 m2 DML m2 IS PROCEDURE new_person (name, education, income) :* ++ person (name, education, income) ; FUNCTION education.enumeration LISTOF education ; FUNCTION income.enumeration :* LISTOF income ; END m2 ; G.3 m3 STAT m3 IS CROSSTAB education.crosstab (education) :« INIT calculate_education_crosstab DATA education.enumeration ; REGRESS income.regression := (education, income) INIT calculate.income.regression DATA income.enumeration ; END m3 ; G.4 m4 GRAPH m4 IS GRAPH make.education.graph := ON main.terminal BAR education.crosstab (0:4) HEADING "Education LABEL ("Grade School", "High School", "College", "Graduate School") ; 158 GRAPH make.income.graph : = ON plotter_10a LINE income.regression (0:4,0:100000) HEADING "Education and Income" LABEL ("Education", "Income") ; END m4 ; G.5 m5 DEVICE m5 IS TYPE terminal (start.address) := DISCRETE HOR 0:300 VER 0:360 ADDRESS start.address ; TYPE plotter := CONTINUOUS HOR 0:36 VER 0:40 PEN UP plotter_pen_up DOWN plotter_pen_down MOVE plotter.move REFRESH plotter.refresh ; main.terminal := terminal(36042) ; plot^er.lOa := plotter ; END m5 ; G.6 m6 GROG m6 IS PROCEDURE main := — load up database calculate.education.crosstab (), make.education.graph(), calculate.income.regression (), 159 make.income.graph() ; END m6 ; G.T STANDARD INTERFACE ATTRIBUTE GRAMMAR standard.interface IS INHERITED DYNAMIC ATTRIBUTE call.frame ; SYNTHESIZED DYNAMIC ATTRIBUTE execute ; SYNTHESIZED DYNAMIC ATTRIBUTE evaluate ; SYNTHESIZED DYNAMIC ATTRIBUTE declare ; SYNTHESIZED DYNAMIC ATTRIBUTE set ; NONTERMINAL TYPE execution IS call.frame, execute ; NONTERMINAL TYPE evaluation IS call.frame, evaluate ; NONTERMINAL TYPE variable.evaluation IS call.frame, evaluate, set, declare ; defstruct(call.frame, values) ; defvar(procedure.table, make.hash.tableO) ; — hash on procedure name of nonterminal execution defvar (funct ion. table, make.hash.tableO) ; — hash on function name of nonterminal evaluation defvar(variable.table, make.hash.tableO) ; — hash on variable name of nonterminal variable.evaluation START entry.of.symbol(’user::main,global_block).execution ; END standard.interface ; G.8 DATABASE INTERFACE ATTRIBUTE GRAMMAR database.interface IS INHERITED DYNAMIC ATTRIBUTE relate.frame ; SYNTHESIZED DYNAMIC ATTRIBUTE assert ; 160 SYNTHESIZED DYNAMIC ATTRIBUTE retract ; SYNTHESIZED DYNAMIC ATTRIBUTE test ; SYNTHESIZED DYNAMIC ATTRIBUTE generate ; NONTERMINAL TYPE relation IS relate.frame, assert, retract, test, generate ; defstruct(relate_frame, object, values) ; defvar(relation_table, make.hash.tableO) ; — hash on relation name of nonterminal relation END database_interface ; G.9 DEVICE INTERFACE ATTRIBUTE GRAMMAR device.interface IS INHERITED DYNAMIC ATTRIBUTE graph.frame ; SYNTHESIZED DYNAMIC ATTRIBUTE move.abs ; SYNTHESIZED DYNAMIC ATTRIBUTE move.rel ; SYNTHESIZED DYNAMIC ATTRIBUTE point.abs ; SYNTHESIZED DYNAMIC ATTRIBUTE point.rel ; SYNTHESIZED DYNAMIC ATTRIBUTE line.abs ; SYNTHESIZED DYNAMIC ATTRIBUTE line.rel ; SYNTHESIZED DYNAMIC ATTRIBUTE text ; SYNTHESIZED DYNAMIC ATTRIBUTE refresh ; NONTERMINAL TYPE device.graphics IS graph_frame, move_abs, move_rel, point_abs, point_rel, line.abs, line.rel, text, refresh ; defstruct(frame, values) ; defvar(device.table, make.hash.tableO) ; 161 — hash on device name of nonterminal device.graphics END device.interface ; G.10 DDL Grammar GRAMMAR ddl IS START ddl.declaration ; LEXEME identifier ; ddl.declaration IS "DDL" identifier "IS" declaration.sequence "END" identifier#again ; declaration.sequence IS [declaration_sequence#sub] declaration ; declaration IS relation.declaration I implementation.declaration ; relation.declaration IS "RELATION" identifier ["(" parameter.sequence ")"] [ii;as" relation.definition] ";" ; parameter.sequence IS [parameter.sequence parameter ; parameter IS identifier [":" identifier#type] ; relation.definition IS implementation.definition I derived.definition ; implementation.definition IS "IMPLEMENTATION" identifier ; derived.definition IS "DERIVED" expression ; expression IS relation.literal I join_expression I select_expression I project.expression ; relation_literal IS identifier ; join_expression IS "JOIN" "(" expression_sequence ")" ; expression_sequence IS [expression.sequence ","] expression ; select.expression IS "SELECT" expression "WHEN" identifier "(" [identifier.sequence] ")" project_expression IS "PROJECT" ["COMPACT"#compact] expression "(" [identifier.sequence] ")" ; implementation.declaration IS "RELATION" "IMPLEMENTATION" identifier ["(" identifier.sequence ")"] "IS" ["ASSERT" identifier#assert ";"] ["RETRACT" identifier#retract ";"] ["TEST" identifier#test ";"] ["GENERATE" identifier#generate " ; ["INIT" identifier#init "; "END" identifier#again ; END ddl ; G .ll DDL Interpreter ATTRIBUTE GRAMMAR ddl.interpreter IS USE standard.interface ; USE database.interface ; NONTERMINAL relation_declaration IS relation ; defvar(relation.object.table, make_hash_table()) ; — hash on relation name of lisp object defvar(implementation.table, make_hash_table()) ; — hash on implementation name of nonterminal — relation.implementation INHERITED DYNAMIC ATTRIBUTE calllframe IS implementation.declaration IS make.frame() ; END call.frame ; INHERITED DYNAMIC ATTRIBUTE frame IS relation.declaration IS make.frameQ ; END frame ; SYNTHESIZED STATIC ATTRIBUTE declare IS relation.declaration IS setf(gethash(identifier.declare,relation.table), relation.declaration) ; implementation.declaration IS s etf(gethash(ident if i er.declare,implement at ion.t able) relation.implementation) ; identifier IS intern(lexeme,"user") ; END declare ; SYNTHESIZED DYNAMIC ATTRIBUTE assert IS relation.declaration IS setf(relate.frame.obj ect(relation.declaration.frame), gethash(identifier.declare,relation.object.table)) setf(relate.frame.values(relation.declaration.frame), relate.frame.values (relation.declaration.relate.frame)), cond( [relation.definition, relation.definition.assert], Ct, gethash ('user::base,implementation.table).assert]) ; implementation.definition IS cond( [implementation.definition, implementation_definition.assert] [derived_definition, derived.definition.assert]) ; implementation.definition IS gethash(identifier.declare,implementation.table).assert ; derived.definition IS error("Update to derived relation.") ; implementation.declaration IS unless(identifier#assert, error("No assertion for implementation.")), setf(frame.values(implementation.declaration.call.frame), cons( relate.frame.obj ect (implementation.declaration.frame) relate.frame.values (implementation.declaration.frame))), entry.of.symbol (identifier#assert.declare,global_block).execute ; END assert ; SYNTHESIZED DYNAMIC ATTRIBUTE retract IS relation.declaration IS setf(relate.frame.obj ect(relation.declaration.frame), relate.frame.obj ect (relation.declaration.relate.frame)), setf(relate.frame.values(relation.declaration.frame), relate.frame.values (relation.declaration.relate.frame)) , cond( [relation.definition, relation.definition.retract], Ct, gethash ('user::base,implementation.table).retract]) ; implementation.definition IS cond( [implementation.definition, implementation.definition.retract] [derived.definition, derived.definition.retract]) ; 165 implementation.definition IS gethash (identifier.declare,implementation.table).retract ; derived.definition IS error("Update to derived relation.") ; implementation.declaration IS unless(identifier#retract, error ("No retraction for implementation.")), setf(frame.values(implementation.declaration.call.frame), cons( relate.frame.object (implementation.declaration.frame) relate.frame.values (implementation.declaration.frame))) , entry.of.symbol (identifier#retract.declare,global_block).execute ; END retract ; SYNTHESIZED DYNAMIC ATTRIBUTE test IS relation.declaration IS setf(relate.frame.obj ect(relation.declaration.frame), relate.frame.obj ect (relation.declaration.relate.frame)), setf(relate.frame.values(relation.declaration.frame), relate.frame.values (relation.declaration.relate.frame)), cond( [relation.definition, relation.definition.test], It, gethash(’user::base,implementation.table).test]) ; implementation.definition IS cond( [implementation.definition, implementation.definition.test] [derived.definition, derived.definition.test]) ; implementation.definition IS gethash(identifier.declare,implementation.table).test ; derived.definition IS — test derived definition implementation.declaration IS unless(identifier#test, error("No test for implementation.")), 166 setf(frame.values(implementation.declaration.call.frame), cons( relate.frame.object (implementation.declaration.frame) relate.frame.values (implementation.declaration.frame))), entry.of.symbol (identifier#test.declare,global.block).evaluate ; END test ; SYNTHESIZED DYNAMIC ATTRIBUTE generate IS relation.declaration IS setf(relate.frame.obj ect(relation.declaration.frame), relate.frame.obj ect (relation.declaration.relate.frame)), setf(relate.frame.values(relation.declaration.frame), relate.frame.values (relation.declaration.relate.frame)), cond( [relation.definition, relation.definition.generate], [t, gethash (’user::base,implementation_table).generate]) ; implementation.definition IS cond( [implement at ion.def init i on, implementation.definition.generate] [derived.definition, derived.definition.generate]) ; implementation.definition IS gethash (identifier.declare,implementation.table).generate ; derived.definition IS — generate derived definition implementation.declaration IS unles s(ident if i ertgenerat e, error("No generate for implementation.")), setf(frame.values(implementation.declaration.call.frame), cons( relate.frame.obj ect (implementation.declaration.frame) relate.frame.values (implementation.declaration.frame))), 167 entry.of.symbol (identifier#generate.declare,global_block).evaluate END generate ; END ddl_interpreter ; G.12 DML Grammar GRAMMAR dml IS START dml.declaration ; LEXEME identifier ; dml.declaration IS "DML" identifier "IS" declaration.sequence "END" identifier#again ; declaration.sequence IS [declaration.sequence] declaration ; declaration IS function.declaration I procedure.declaration ; function.declaration IS "FUNCTION" identifier subprogram.body ; procedure.declaration IS "PROCEDURE" identifier subprogram.body ; subprogram.body IS ["(" identifier.sequence ")"] statement.sequence ; identifier.sequence IS [identifier_sequence#sub ","] identifier ; statement.sequence IS [statement_sequence#sub statement ; statement IS procedure.invocation I assert.statement I retract.statement I return.statement ; procedure.invocation IS identifier "(" [parameter.expression.sequence] ")" ; parameter.expression.seqnence IS [parameter_expression_sequence#sub ","] expression ; assert.statement IS "++" identifier "(" [parameter.expression.sequence] ")" ; retract.statement IS "— " identifier "(" [parameter.expression.sequence] ")" ; return.statement IS "RETURN" expression ; expression IS function.invocation I test.expression I generate.expression ; function.invocation IS identifier "(" [parameter.expression.sequence] ")" ; test.expression IS "??" identifier "(" [parameter.expression.sequence] ")" ; generate.expression IS "LISTOF" identifier ; END dml ; G.13 DML Interpreter ATTRIBUTE GRAMMAR dml.interpreter IS USE standard.interface ; 169 USE database.interface ; NONTERMINAL function.declaration IS evaluation ; NONTERMINAL procedure.declaration IS execution ; INHERITED DYNAMIC ATTRIBUTE call.frame IS function.invocation IS make.frame() ; procedure.invocation IS make.f rame() ; END call.frame ; INHERITED DYNAMIC ATTRIBUTE relate.frame IS assert.statement IS make.relate.frameO ; retract.statement IS make.relate.frameO ; test.statement IS make.relate.frameO ; generate.statement IS make.relate.frameO ; END relate.frame ; INHERITED DYNAMIC ATTRIBUTE frame IS subprogram.body IS make.frame () ; END frame ; SYNTHESIZED STATIC ATTRIBUTE symbol IS identifier IS intern(lexeme, "user") ; END symbol ; SYNTHESIZED STATIC ATTRIBUTE string IS identifier IS lexeme ; END string ; SYNTHESIZED STATIC ATTRIBUTE declare IS function.declaration IS setf(entry.of.symbol(identifier.declare,global.block), function.declaration) ; procedure.declaration IS setf(entry_of.symbol(identifier.declare.global_block), procedure.declaration) ; END declare ; SYNTHESIZED DYNAMIC ATTRIBUTE execute IS procedure.declaration IS subprogram.body.execute ; subprogram.body IS setf(frame.values(subprogram.body.frame), frame.values(subprogram.body.call.frame)), statement.sequence.execute ; statement.sequence IS when(statement_sequence#sub, ' statement_sequence#sub.execute), statement.execute ; statement IS cond( [procedure.invocation, procedure.invocation.execute], [assert.statement, assert.statement.execute], [retract.statement, retract.statement.execute], [return.statement, return.statement.execute]) ; procedure.invocation IS when(parameter.expression.sequence, parameter.expression.sequence.execute), cond( [entry.of.symbol(identifier.declare,global.block), entry.of.symbol(identifier.declare, global.block).execute], [t, apply(intern_lexeme(identifier.string,’lisp), frame.values (procedure.invocation.call.frame))]) ; parameter.expression.sequence IS when(parameter_expression_sequence#sub, parameter_expression_sequence#sub.execute), push(expression.evaluate.frame.values (parameter.expression.sequence.call.frame)) ; assert.statement IS when(parameter.expression.sequence, parameter.expression.sequence.execute), gethash(identifier.symbol,relation.table).assert ; retract.statement IS when(paramet er.expres s ion.sequence, 171 parameter.expression.sequence.execute), gethash(identifier.symbol,relation.table).retract ; return.statement IS expression.evaluate ; END execute ; SYNTHESIZED DYNAMIC ATTRIBUTE evaluate IS function.declaration IS subprogram.body.execute ; expression IS cond( [function.invocation, function.invocation.evaluate], [test.expression, test.expression.evaluate], [generate.expression, generate.expression.evaluate]) function.invocation IS when(parameter.expression.sequence, parameter.expression.sequence.execute), entry.of.symbol (identifier.declare,global.block).evaluate ; test.expression IS when(parameter.expression.sequence, parameter.expression.sequence.execute), gethash(identifier.symbol,relation.table).test ; generate.expression IS gethash(identifier.symbol,relation.table).generate ; END evaluate ; END dml.interpreter ; G.14 STAT Grammar GRAMMAR stat IS START stat.declaration IS LEXEME identifier ; stat.declaration IS "STAT" identifier "IS" declaration.sequence "END" identifier#again ; d ecla ra tio n ^ seq u en ce IS [d ecla ra tio n _ seq u en ce# su b ] d e c la r a tio n ; declaration IS init_declaration I crosstab_declaration I regression_declaration ; init_declaration IS "INIT" identifier initialization.sequence ";" ; initialization_sequence IS [initialization_sequence#sub identifier crosstab_declaration IS "CROSSTAB" identifier "(" identifier_sequence identifier#fn ";" ; regression_declaration IS "REGRESS" identifier "(" identifier_sequence identifier#fn ";" ; identifier_sequence IS [identifier.sequencetsub " , identifier ; END stat ; G.15 s t a t Interpreter ATTRIBUTE GRAMMAR stat.interpreter IS USE standard.interface ; NONTERMINAL init.declaration IS procedure ; NONTERMINAL crosstab.declaration IS procedure ; NONTERMINAL regression.declaration IS procedure defun(calculate.crosstab,[value.list], ) ; defun(reference_crosstab,[index], ) ; defun(calulate_regression[value_list], ) ; defun(reference_regression,[index], ) ; defvar(statistics.table, make.hash_table()) ; defvar(statistics_result_table, make_hash_table()) ; INHERITED DYNAMIC ATTRIBUTE call.frame IS crosstab.declaration IS make.frame() ; regression.declaration IS make.frame() ; END call.frame ; SYNTHESIZED STATIC ATTRIBUTE declare IS init.declaration IS setf(entry.of.symbol(identifier.declare,global.block), init.declaration) ; crosstab.declaration IS setf(gethash(identifier.declare,statistics.table), crosstab.declaration), setf(entry.of.symbol(identifier.declare.global.block), crosstab.declaration) ; regression.declaration IS setf(gethash(identifier.declare,statistics.table), crosstab.declaration), setf(entry.of.symbol(identifier.declare,global.block), regression.declaration) ; identifier IS intern(lexeme,"user") ; END declare ; SYNTHESIZED DYNAMIC ATTRIBUTE init IS crosstab.declaration IS setf(gethash(identifier.declare,statistics_result_table), calculate.crosstab(entry.of.symbol (identifier#fn.declare).evaluate)) ; regression.declaration IS setf(gethash(identifier.declare,statistics.result.table), 174 calculate_regression(entry.of.symbol (identifier#fn.declare).evaluate)) ; END i n i t ; SYNTHESIZED DYNAMIC ATTRIBUTE evaluate IS init.declaration IS initialization.sequence.evaluate ; initialization.sequence IS when(initialization_sequence#sub, initialization_sequence#sub.evaluate), gethash(identifier,statistics.table).init ; crosstab.declaration IS reference_crosstab( gethash( identifier.declare,statistics.result.table), frame.values(crosstab.declaration.call.frame))) regression.declaration IS reference.regression( gethash( identifier.declare,statistics.result.table), frame.values(statistic.declaration.call.frame))) END evaluate ; END stat.interpreter ; G.16 G R A P H Grammar GRAMMAR graph IS START graph.declaraton ; LEXEME identifier ; LEXEME string.literal ; LEXEME numeric.literal ; graph.declaration IS "GRAPH" identifier "IS" declaration.sequence "END" identifier#again ; declaration.sequence IS [declaraton_sequence#sub] declaration ; d e c la r a tio n IS g ra p h _ d ecla ra to in ; graph.declaration IS "GRAPH" identifier "IS" graph.form "(" range.sequence ")" label_form "END" identifier#again ";" ; range_sequence IS [range_sequence#sub range ; range IS numeric_literal#from ":" numeric_literal#to graph.form IS pie.graph I 1ine.graph I bar.graph ; pie.graph IS "PIE" identifier ; line_graph IS "LINE" identifier ; bar_graph IS "BAR" identifier ; label_form IS ["HEADING" string.literal ";"] ["LABELS" label ";"] label_sequence IS [label_sequence#sub ","] label ; label IS string.literal I nested.label ; nested.label IS "(" label.sequence ")" ; EN D graph ; G.17 GRAPH Interpreter ATTRIBUTE GRAMMAR graph_interpreter IS USE standard_interface ; USE device.interface ; NONTERMINAL graph_declaration IS procedure SYNTHESIZED STATIC ATTRIBUTE declare IS END declare ; SYNTHESIZED DYNAMIC ATTRIBUTE evaluate IS END evaluate ; END graph.interpreter ; G.18 DEVICE Grammar GRAMMAR device IS LEXEME identifier ; LEXEME numeric.literal ; START device.declaration ; device.declaration IS "DEVICE" identifier "IS" declaration.sequence "END" identifier#again ";" ; declaration.sequence IS [declaration_sequence#sub] declaration declaration IS type.declaration I instance.declaration ; type_declarati°n IS "TYPE" identifier ["(" identifier_sequence ")"] type.form ; type.form IS discrete_form I continuous.form ; discrete_form IS "DISCRETE" limits ["ADDRESS" mimeric_literal] ; continuous_form IS "CONTINUOUS" limits ["PEN" ["UP" identifier#up] ["DOWN" identifier#down]] ["MOVE" identifier#move] ["REFRESH" identifier#refresh] ; limits IS ["HOR" numeric_literal#hor [":" numeric_literal#hor_h.igh] ] ["VER" numeric_literal#ver [":" numeric_literal#ver_high]] pen_control IS ["PEN" ["UP" identifier] ["DOWN" identifier]] instance_declaration IS identifier identifier#type ["(" identifier_sequence ")"] ; END device ; G.19 DEVICE Grammar ATTRIBUTE GRAMMAR device IS USE standard.interface ; USE device.interface ; NONTERMINAL device.declaration IS device SYNTHESIZED STATIC ATTRIBUTE declare IS END declare ; SYNTHESIZED DYNAMIC ATTRIBUTE evaluate IS END evaluate ; END device ;

Abstract (if available)

Abstract In a multi-formalism specification environment an application specification is written in terms of one or more domain formalisms. No one formalism is sufficient to subsume the others in such a way that the entire specification could be easily written in that one formalism. Instead, different aspects of a specified application are described in terms of narrow domain formalisms whose semantics are defined independently and linked together through interfaces.
The process of multi-formalism specification, in its purest form, is three separate activities: interface, formalism, and application design which interact only through the formalism library. Interfaces are first designed and then formalisms are designed in terms of one or more interfaces. Interface and formalism design are ongoing activities; the formalisms and associated tools are saved in a formalism library. The application designer selects formalisms from the library and composes them to specify the particular application. Once the application is specified, an implementation is automatically generated using the semantic definitions associated by the formalism designer with the respective formalisms of the specification.
There are two basic methods of composition: closed and open. Closed composition explicitly joins particular formalisms to create a new formalism. In open composition, on the other hand, no new formalism is created. Instead, formalisms are composed in the specification on the basis of the interfaces on which they are defined. Other than relying on a common interface, formalisms in open composition are totally independent: they may be designed relatively independently, unlike subformalisms of a closed composition. In general, inter-formalism interaction in closed composition is arbitrary whereas interaction in open composition is restricted to the semantic concepts of the interfaces between each formalism pair.
Two methods of open composition are supported: modular and recursive composition. In modular composition, specifications are broken down into modules. Each module is expressed in a single formalism. A modular composition multi-formalism specification consists of one or more such modules, potentially in different formalisms.
In recursive composition, substrings in different formalisms may be intermixed. Transitions between formalisms in the text of the system specification are explicitly indicated by meta-symbols. Whereas modular composition requires named declarations to be shared between formalisms, recursive composition allows direct switching between formalisms.
Future software development environments must support multiple formalisms as smoothly as today’s single-language software development environments. Among the advantages a multi-formalism specification environment offers over conventional software development environments are: close fit of model to problem, combination, within a specification, of different models to describe an application, and extensibility of the model base.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Sharing persistent object-bases in a workstation environment

PDF

A statistical ontology-based approach to ranking for multi-word search

PDF

Learning semantic types and relations from text

PDF

Learning affordances through interactive perception and manipulation

PDF

A reference architecture for integrated self‐adaptive software environments

PDF

From matching to querying: A unified framework for ontology integration

PDF

WikiWinWin: a Wiki-based collaboration framework for rapid requirements negotiations

PDF

Automated synthesis of domain-specific model interpreters

PDF

Deriving component‐level behavior models from scenario‐based requirements

PDF

Modeling and recognition of events from temporal sensor data for energy applications

PDF

Understanding semantic relationships between data objects

PDF

Learning paraphrases from text

PDF

Parametric and non‐parametric modeling of autonomous physiologic systems: applications and multi‐scale modeling of sepsis

PDF

Decentralized real-time trajectory planning for multi-robot navigation in cluttered environments

PDF

Complex pattern search in sequential data

PDF

Asymetrical discourse in a computer-mediated environment

PDF

Software quality understanding by analysis of abundant data (SQUAAD): towards better understanding of life cycle software qualities

PDF

Rethinking perception-action loops via interactive perception and learned representations

PDF

Efficient bounded-suboptimal multi-agent path finding and motion planning via improvements to focal search

PDF

Calculating architectural reliability via modeling and analysis

Asset Metadata

Creator Ipser, Edward Anthony, Jr. (author)

Core Title Toward a multi-formalism specification environment

School Graduate School

Degree Doctor of Philosophy

Degree Program Computer Science

Degree Conferral Date 1990-08

Publication Date 08/31/1990

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag OAI-PMH Harvest

Format 191 pages (extent)

Language English

Contributor ProQuest (digitizer)

Advisor Wile, David (committee chair), Dubois, Michel (committee member), Jacobs, Dean (committee member), McLeod, Dennis (committee member)

Permanent Link (DOI) https://doi.org/10.25549/usctheses-oUC11257199

Unique identifier UC11257199

Identifier DP22803.pdf (filename)

Legacy Identifier DP22803

Document Type Dissertation

Format 191 pages (extent)

Rights Ipser, Edward Anthony, Jr

Internet Media Type application/pdf

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the author.

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA

Repository Email cisadmin@lib.usc.edu