MELD: A Multi-Paradigm Language with Objects, Dataflow and Modules
Gail E. Kaiser Columbia University Department of Computer Science New York, NY 10027
David Garlan Tektronix, Inc. Computer Research Laboratory Beaverton, OR 97077
December 1987
CUCS-281-87
Abstract
This technical report consists of the two most recent papers from the MELD project. Melding Software Systems from Reusable Building Blocks describes MELD as a declarative language that combines facilities from the package library, software generation and object-oriented language approaches to reusability. MEWing Data Flow and Object-Oriented Programming emphasizes the multi-paradigm nature of MELD and introduces overriding of inherited facilities and generic features, and discusses compile-time error detection.
Prof. Kaiser is supponed in pan by grants from AT&T Foundation, ffiM, Siemens Research and Technology Laboratories, and the New York State Center of Advanced Technology - Com puter & Infonnation Systems, and in pan by a Digital Equipment Corporation Faculty Award. When this research was conducted, Dr. Garlan was supported in pan by the United States Anny, Software Technology Development Division of CECOM COMMIADP, Fort Monmouth, NJ and in part by ZTI-SOF of Siemens Corporation, Munich, Gennany. Melding Software Systems from Reusable Building Blocks
Gall E. Kalser. Columbia Ulliversity Dayid GanAD. Cantetie MeDoa Ulliversity
cannot easily be expanded to meet unan ticipated needs. To realize the potential of larae-scale software reusability. three charactensucs urrent apprOKhes to software are reqwred: rewe have nO( lived up to reusa • Unauaae independence. to avoid C bility's pocaatiaJ to dramatically early implementation dedsions. Of improve software productivity and main course. every notation is a "Ianauaae." ThIs declamth>e tamability. but it is bat to avoid ronCfele representa TM shortCOftliIllS of the three m06t tions and control mu"ures until actual language taka the popular aPJ)foaches are discuued in the reuse. when the most effident solutions best /eatura from the bolt on p. ". The pnmary deficiency of can be chosen. three ,.., popular these approaches is that they tiahtly cou • Composition of components. to build ple reusable components to their oriainaJ larle software systems to meet complex reusabUlty~ con tal. Either tne reusable components requirements. Procedural invoation of but Ol'efComes their arc _ritlC1l In one l&nluaac and c:anftOt separately developed components works cully be rewed in aDOCber lanluaac or to some extent. but it does not promote /laws. It supports tbey implemau a specirlC abstract data rewe of larle-scale components. language independence, t )1)e aDd/or f uDCtion and c:annot euiJy be • Flexibility. to expand reusability component cOfl1POl!jitba, coaYaUd into the subtly c1iffemu require beyond the capabilities and appliations ments of another appliation - or even anticipated by the oriaina! implementor. and toUorfng. the oriJ1Dal appticarjoa - hen it is repaired MOQ ~0ICba reqwre that the complete or mhanad. Fun.bermore. the optioas for set of taiJorina options be dermed when the tlliorinia reusable component are deter reusable component is created. These rruncd _hen the component is wnllen and options are not always sufficient.
July 1987 17 We have developed a new approach to ~oreover. unlike Ada packages. fea· guage or executed on a new architecture reusable software that has these three tures have the flexibility of classes. A fea simply by reimplementing the translator characteristics. The basis of this approach ture's interface impons a group of and runtime suppon. is Meld. • a declarative language that can features. making the classes exponed by Thus. Meld combines the advantages of be translated to an efficient implementa these features available within its Imple libraries. software generation. and object tion in a conventional programming mentation. There. an imponed class can oriented programming - without assum· language. be merged. either with a locally defined ing the limitations of these approaches. An entire software system can be writ class or with another imponed class. However. there are cenain important ten in Meld and then translated to the Merging has the effect of inheritance: issues in software reusability we did not desired programming language_ System One class inherits (reuses) all the facilities address. Meld is no better than the Widely maintenance is done with the Meld repre already defined for another class and can used approaches at helping programmers sentation rather than the implementation augment and replace any subset of these determine if a particular component IS language. Or an individual component can facilities. suitable for reuse in a particular applica be written and maintained in Meld. and its tion. Meld also does not address the sepa translation intearated into an application Action equations. Unlike classes, how· rate problem of catqorizinl and retrieving written in a conventional language. Thw. ever. features can combine. as weU as aug reusable components. but we are working old code can be combined with compo ment and replaA:e, inherited methods. This on this. USinl a conceptual clustering nents written in Meld. is accomplished by writing methods as approach derived from research in artifi action equations. Action equations should cial intelligence. Overview of Meld not be confused with mathematical equa tions. They were developed to extend Meld is an object~riented lanlUaae in An extended example that it suppons the encapsulation of data attribute p-amman for semutia procesI The imponant aspectS of Meld can be and operations as objecu defined by ina of proaramminl environmenu. I iIIwtrated with an extended eumple. classes and the inheritance of separately Actioa equations derIDe (1) me reWioo defined data and operations from ances ships that must hold amOI1l objects and M..", ...... Suppose a proaram· tor classes. In the context of object amon. partS of objects and (2) the mer wuu to implement a facility for load· oriented languaaes. such data arc called dynamic iDlmICtion amon. objects and in, and storinl arbitrary entities to disk. instance variables and such operations are b«weeD objecu and external qcnu (1UCh Traditionally. he miaht modify the entities methods. as users. tbe operatin. system. ud themselves to suppon memory manage But Meld hu two essential asP«ts that utilities). malt. Or he milht add the facility directly set it apan from other object-or"iented Ian When classes mer.e. separately to the runtime suppon of the program· guages./NtllfU and actio" ftlJMltioflS. inherited methods can be combined by min. Ianauaae. perhaps as a generic assipina them the same selector (the same puk.... Fn...... Fealu.ra arc rcu.sabIc buiJdina method name). Because methods define Neither approach promotes reusability. blocks. Like Ada packqa. their inter· relationsltips and dynamic interactiolU in In the first C&$C. memory manaaement is faces are separate from the imp&emalta the aband - u ICtioa equatiolU - specific to the entities. In the second case. tion. A feature bundles a colJec:tioa or rather thaD by • sequence of swemenu. the memory manaaer is reusable only in interrelated classes in iu impiemmtaDon. the behavior oftbe methods is combtDed the seDJC that a text editor or a compiler is: The interface uporu a subMt of thae implicilly. The resultin. compolite I use it today on one file. you use it tomor· classes and I subset of their IDllbodiI behavior doa no« depend on any sequen row on IIlOther me. This memory man tial ordainl of the methods. IJeT cannot be tailored to the particular I n effect. I (eaturt is a reusable I&Dk needl or the application. larger (hln I subroutiM. on appr'Ou. mat ely the wne scUe. u Ada pack.... I ..... ' ...... Meld is implcmcftted However. with Meld the prOl1ammer by truslaun. ach feature into a convas. COnJU'\ICU a reuaable buildin. block that (hat permits the reuII of the aJlM amon. tiona! prosrunmin. lanauqc and by be incorporated into any system that subroutines (methodI, aDd. in flit:l.1IDOftI a can S1*ial Nfttime mvironmalt thai supporu requires memory manqement. abstract datarypes (cIaIaes). A aeneric rea execulion or systems built from features. The Memory Manqer describes the (ure is similar to a aeneric !)Kk. because implanenwion world u seen (rom a simple memory the Inter(ac.c can be instantiated accordina We dIri¥ed the aJeorithma from prev;ous worll on software pnera manqcr's point or view. The world con to the requirements of the ~red appli. tion, specificaUy luauqe-bued editon, sists or a collection of memory-managed . cation. where performucz .. toad • handc:oded entities Iroupcd under a memory· editon I\u been ac:ttiC'Yed. manqcd rcoc. Eacb memory·managed This imi*mentaUon technique mswa entity hal a unique identifier, a disk loca· -nw cba~ ~ of •• ~ •••, "!IId ~ IMauaP independcnc:e and portability tion, a desianation or whether it is loaded wftl... Of "to __." Mad uo.uds rOf Mu1Itpk because all aimn. feat Urel can be in con Of not, and a time stamp rCllrcsent· EIIladatIOftS or LAIII\&IIII Dacn~. wl\ldl wu wUCSIed by o.nd ...... 0-. produced in a new implementation lan- in. the most recent acceu to it.
18 IEEE SOFTWARE What's wrong with the popular approaches Three approaches to software reusability have achieved Widespread use suo· routine Ilbranes, software generation, and oblect'Ortented programming None has achieved marked gains In productiVity outside of a small set of applI· cation areas, but all treat reusability as part of the deSIgn rather than an after· The information about each memory thought of the ImplementatIon. It IS rarely feasible to decompose an eXlSllng managed emity is always maintained in software system Into reusable components that can be then used to construct core; the actual content of the entity is other systems, ReusabIlity must be engIneered from the start. what the memory manager loads and stores. The memory manager loads the Subroutlnellbrlrle .. librarles have had a SignIficant effect on the production of mathematical software systems, as well as string manipulation and 110, but content of an entity when it is first they are not suffiCIent to achieve a large-scale Improvement In software produc· accessed. When primary memory is nearly tivlty and maintenance. full, entities are stored according to a least An Individual subroutine ia too small and the glue necessary to make many recently-used policy. subroutines work together Is too large. Small size makes subroUtines more amena· Figure I shows the classes for a generic ble to reuse than larger units, since they tend to be relatively Simple and context· memory manager. This description is free. but only a small amount of code IS actually reused by each subroutine call encapsulated into a feature, which has a Libraries are written in a particular programming language. so deCISIons aDout narne. an interface. and an implemen primitive data types, constructors for structured data types. and subroutine link· tation. ages have already been made. Subroutines are wrttten with all the detailS filled in, so It IS not possible to change the number or types of the parameters or to pick out part of the algortthm Inter/ace. The interface lists the classes encapsulated in the subroutine without a proliferation of library versions or hand· exported by the feature in its exporu clause copying of reused code. and lisu tbe other features that are Ada packages extend subroutine libraries.. expanding the sIze of the reusable imported in iu imporu clause. unit and encapsulating some of the glue among subroutines.. so the glue c.n also In this case, the ROOT and ENTITY clas.scs be reused. Genertc package, pennlt the type. of selected parameters to be sp«i are exported. Any exported in.st.an~ vari fled by the application, but do not suppon changing the number of p.rameten ables are listed in the bracketS followin. and do not help the programmer In sp«lallzlng algOrithms.. Ada packages a,. bet· the class rwne; only the listed components ter th.n subroutine. when It comel to m.lnten.nc.. since the Ada ~rammlng are accessible outside the feature. The Suppon Environment supporU version control. Code skeleton, also extend subroutlnellbrarle.. They conaist of many subrou instan~ variables of ENTITY are entirely tines.. Of' even many package.. making even more of the glue reusable. Code skele hidden, but the maxentities variable of tons are batTen. however: Inatead of supplying the glu .. the progr.mmer must ROOT is available to other fe.tures th.t supply the content .. If the d.t. ,tructures .nd algorithms are not Included in the import the memory-m.anqer feature. This skeleton, they muat be proVIded by the proorammer; If elthar IS Included, oppor· is more powerful than inform.tion hidinl tunillea for reuse are restricted to tho.. planned by the original Implementor. an Ada, where either all or none of the fields of a record are exported. Softw8,. generatara. Applied succ.. lfully to rtpOn generators. compiler· compll.,.. and langu.g.b.1ed edlto,.., softw.,. generation mM" the criterion The implement.tion Implemt1ttallofl. of langu.ge Ind8i)endence. The generatOf' can be changed to produce software part defines two clusa, lOOT and EHTtTY. In a different Implementation langu.ge without Ilgnlflcantly affecting existing followed by the instan~ vari.bles and Input lpacillcation.. their types. The action equatiol1.l tb.al Software generation produc" code .....aJ ord.,. Of megnltudt larger than the deSCribe the beh.vior of the rOO( and IC)eCJfleation. but a MW ~tor can be ~1ot*I only att. thelP9l1catlon are. memory-man ••ed entities are Iival in II "'atl¥lty WlI-undefS100d and ltandardlzed - and ltandardlutlon cannot keeP FIgures 2 and 1. respectively. pace with new .ppllc.tlon.. The ENTITY class re-presenu the mtities It I. difficult to combine the output produced by dlHer.nt generato,.., and larg. manaled by the memory manapr. It scale p.tCh•• to the generated cOde ab.ndon the .dvantag.. of g.n.ratlon for I.tll m.lntenance. defines four Jnstancevariabla - unjqUl Id. Incore.lastusc. &ad dWDd - that con tOlln obvious informaUoa. Each insWK:e Obfect-oNfttecll.,.,..... Thll appro.ch suppons great flexibility In defln· van able is typed; SU'OaI rypq is mforcIId. Ing and CQ(l\pollng reu.able component.. New cl ..... Inherit the facilltl .. 01 enforced. sC)«lfled alltlng cl ...... and a clan may augment or reQlac. any lub.. t of the The ENTITY class represents only the in"ented data llructu'" and o.. tlon .. stub for an entity - there are no instanc:c In adCIltlOft to augmenting and ""'acing. h~. it I. ott.n nee ....ty to com· variables represenunl the content of the blne dlltlnct OC*'Itlonl prcMded by dlN.,."t rtuaable component.. Some ob,eet· ooented languaga pennlt a colleC1lon of to combined by seQuenc· memory-manaled entity. Instana vari. ~tlonl be Ino - caJll"O Meh one Individually In some PfMC)IClfied ordef - but WIth no sup bles that do represent the content are pon for condltlon.1 cholc. or Interle.vlng. added when the Memory Manqer feature Obleet-()(lented proorammlng languaQ" Imply panlcular elecilion. regarding is meraed with one or more other features the Implement.tlons of d.t. ty~ and o~atlons.. dra.tlcally limiting. a priori, that provide entities that require memory the contexts In which a cl ... can be r8Yled. manaaement. The lOOT dus defines the memory- 19 July 1987 Feature :l.lodule Imerconnectlon Language
Interface:
Exports ~ ~Programmlnll Languaie PROJECT class of the MIL feature and the Implementation: ROOT class of the ~emory Manager feature. Clus PROJECT:: = name: Idmtt/lu However, the only instance variable -- modules: 1'90/MODULE from the ROOT class that can actually be Class MODULE ::,. name: idmttflu accessed here is maxentities, since It is the -- imports: uq 0/ IdDtttflu only instance variable exported by Mem· expons: S'9 0/ SIGNATURE ory Manaaer. A new action equation over components: rides its default value of 100 and changes IMPLEMENTATION the constant value of maxentities to 200. so the memory manager now maintains at End Feature Module Interconnection LaniU&le most 200 entities in core. Overriding default methods and constraints makes it easy to tailor features to a wide variety of applications. The prollamminl-in-the-Iarge feature Flail"". TH Mod. hlletcouectioal.a.qaap featare. o~ates as foUows. When a human user tries to read the text of a module. the prim itive operation Access is received by the module. which then activates any action ULE class can be tailored to the desired do this. We establish a connection between equations that are part of the Access lanlUaae by imponin. a Proarammin. the lOOT and PlOJECT classes on one method for the MODULE clau. Lanluaae feature that defines the SIGNA· hand. and between the ENTlTY. MODULE. In this cue. the only equations art those TUllE and IMPLEMIHTAnON cl&sses. In the and IMPL.IJoII!NT' AnON c1uses on the other . that were inherited from tbe !NTTTY clau case of Ada. wltic:h defmes its own mod A feature may combine a 1l0UP of in F'1IUfe 3. Thae equations update iastuse ule construct. the MODULE clau miaht be imponed features. In this case. the to tbe current time and cheek if the incore merled with an imponed PACKAGe clul. Pro.rammiDI-in·the-Larle feature insWlCe variable nBS the value true. If not, imporu bodl Memory MaDqer and MIL. the Load messaae is sent to self, meanina M ...... Continuina with the example, and c:enain clwa from these two features the module. This nBS the effect of loadina the Memory Manqer and MIL features are meraed in the implementation. the content of the accessed entity. I f there are combined in a small system. In this sys For eumple, wben the lOOT dill is are now too many mtities in core. the least tem. the memory manapr Mil manqc the mer.ed with the PROJECT clau. each recently wed entity is stored on disk. modules and their implementations. instaDc:e of the fYNIm«J PlOJICT clau hal A real system would probably merae Filure ~ illustrates how we 11M MekI to ail the instance variables from both the many such features. as listed in Fiatire 6.
Implementation Three early versions of Meld have been Interface: implemented. The flnt. the Representation Descrip ~ ... tion Lanluqe. barely resembles Meld ~ MoIhdII_ = L..anpaee. e~ that it uses the same notation for Maaary =. MaMIIr instance variables. RDL development Impl "dol: bepn in 1981 BS pan of the Display Orieftted Structure Editorl system and ~IOOT, PROJECT. PROJECT has been wed for rapid protcxypinl of EHTTTY. MODULf'"u MODULE several smail syStemS at Camq,ie Mellon E!'n1TY. I'-4PLEMEJlr,nl0N !!,1'-4PLE'-4ENTATlON University and Siemens Research and Clua PIOJECT :: • IDUaUtieI: ...... TechDo&osY Laboratories. The secoDd. Genie. is much closet to Methods: Meld. It hal the notion of features. then ITIIltftlUIlCl : • 200 called views. but applied tnenl only to sup port display mechanisms. Genie was used in 198' to implement the Mac:Gnome' edw::ationaJ proaramminl environment for Puca!. which is expected to be released
22 IEEE SOFTWARE . Interia:e; E~ports; Imports: \todule Interconnection Language. \temory \tanager. Compllal1on Unit. Documentation FacllilY, by Apple Computer as a commercial \ty Error Handler •. , , product. The most recent implementation, Mer Implementation: cury, was completed in February 1987. ~Iercury supports constraints but not mes sages and methods, uSing parallel End Feature A Larger System algorithms in a distributed environ ment. J,6 Mercury has been used to imple ment demonstration-quality, multiple Fiaure 6. A la'ler sy!tem. user programming environments for small subsets of Modula-2 and Ada. RDL was originally implemented in extended Pascal on the Perq operating sys necessary because only some facets of an constraints - those action equations (for tem, was poned to Accent in 1982 and to object may be active at any time; this was the same synthesized type) that are not C on Sun 3.0 (essentially Berkeley Unix) in seen in the memory-manager example, attached to a selector. These dependency 1985. Genie was implemented in a differ where the stub for an object could be graphs are used by the runtime suppon to ent extension of PasaJ for the Macintosh. loaded and manipulated independently of determine the evaluation order for active Mercury, written in C, was implemented its content. equations. by modifying the Cornell Synthesizer It is easy to translate individual classes The translation of action equations also Generator7 and runs on Digital Equip into the correspondinll data types in con involves translating each individual action ment Corp. VAX 7SOS under Unix 4.3 ventional prollramming languages. For equation into a procedure that performs BSD on a 10M-baud Ethernet. example. in Pascal uch facet would be the activities in the equation. The proce We are now designing a founh imple represented by a record, where each field dures take advantage of the facilities mentation that will suppon all of Meld as in the record is a component or a pointer provided by the implementation languaae. presented here. The implementation has to a component (dependinl on the type of as well as the primitives provided by the four pans: an environment (or developing runtime support. and maintaining Meld features, a transla The runtime support provides all the tor for the structural components of neces.sary primitives for creatinll, deleting. cla55eS and features, a translator for action and accessing objects, as well as for inter actina with users, the file system. and the equations, and runtime support. To the popc.1aT reUIIe The environment IS itself descnbed in operating system. It sends messages cor Meld and will be implemented throuah a appr'DOCha Meld adds respondina to these primitives as neces bootstrapping procedure. This environ the uNque COIace,x of sary; for example. the Access messaae is ment provides mechanisms for choosinl combIr*W both data and sent to an object whenever the object is particular concrete representations (for Gpe.adot.. accessed. It also provides primitives to example, for collections) and control send the new messqes defined in the Meld ~tructures tfor eumple, sequcntiaJ venus description and manqes a queue of pend parallel equation evaluation) appropriale inl meuqes. to the Implementation lanllaP and the The most important job of the runtime reusing application. It also supportS ~ the component). The difnculty arisa in suppon is to order the evaluation of active lutlon of features usina techniques previ nWntainina the connec:tions and con· action equations. This is done using an ously demonstrated in Trans(ormGen,' sistency amonl the vanous facets of the adaptation of Reps' incremental attribute ..... hlch automates updala to existinl wne object. ThiJ is handled by ,meratinl evaluation alaorithm,' which was devel objects when their definitions are new constraints Ihat update the instance oped to lenerate language-based editors modified. variables of one faU{ in response to from attribute ararnmars. The basic idea The translator for the strUCtural comJ)C> chanles in anOiher. is that the local dependency graphs are nents IS responSible (or leneratinl ob)fCt Unlike the sets o( instance variables. the combined into a composite dependency definitions In a conlfentional pro,ram methods (or a merled dasa are combined araph at runtime to reflect the actual con mlng lanlUaae. An object in a Meld system In the translator (or action equations. A nections amonl objects. Only the graphs ,IS a synthesis of one or more clUieS. per local dependency Iraph is constructed to (or the current messale, plus the araphs haps defined in different futures. The represent the action equations attached to for constraints. are considered in the com classes themselves are not actually com the same selector. The nodes in the araph position. A topolo!ical sort o( the com· bmed in the translation; instead. the phys represent equalions. and the edlCS repre posite anpft determines the order in whJch Ical representation of uch object consists sent the depen July 1987 23 eld meets the three criteria and solves most of the problems of these umque concept of combining bOlh data essential to large-scale reuse three approaches. and operattOlU. Other object-oriented lan M and is superior to the widely From the package library approach guages merge data structures, in the sense accepted approaches to software reusabil came relatively large-scale modular units of creating objects with private memory Ity. The notation abstracts away the details - features - that enforce information for the instance variables defined by each of any particular programmmg language, hiding. From software generation came ancestor class. But no other notatton sup although almost any language is suitable the idea of a declarative notation that can pons combination of algorithms on the for implementation. Meld supports com be translated into an efficient implemen basis of dependencies. position of components through imports tation in a conventional programming lan Software reuse will lead to large produc and merging and tailoring through renam guage. From object-oriented program tivity gains only when it becomes practical ing and overriding equations. ming carne the concepts of inheritance and to combine separately developed Meld, then, blends the package library, of encapsulating behavior with data algorithms more flexibly than procedure software generation, and object-oriented structures. invocation. Meld represents the first step programming approaches to reusability To these approaches Meld adds the in this direction. Acknowledgments work on Gandalf.'o Yael Cycowicz. Dannie Durand. Charlie This ankle is an expansion of "Composin. KrueJer. Josephine MicaJJef. DaVId Miller. Ben Soflwue Syslems from Reusable Buildin. jamin Pierce. Calton Pu. and anonymous Blocks." which appears in pp. 5J6.S4' of Prete. referees made useful criticisms and sugestions }()tlr HawGii 1,,,'1 COIf/. Systmr Saimca. (Com about earlier versions of lhis article. Bob puter Soc:iety Press. Los AlamitOl. Calif •• 1987). Schwanke at Siemens RTL. members of the ~ser is supponed in pan by IBJIts from GandaJf proJC'Ct 011 CarnqIC Mellon University ATolT Foundation, Siemens Research and (AI K-.. is an Ulistant professor of computer and students in the Prosrammin. Lan.UAlcs TechnololY Laboratorics. and New York State science at Columbia Univenity. where she and Translators I course at Columbia Univer Cenler for Advanced TechnolOty, and in pan received a DEC Faculty Award. Her research sity ha\'e Wrlllen st'Ieral features in Meld ~ by a DEC faculty award. Garlan is supponed interests are software reusability. obJect discovered cen~n problems that have Since been in pan by the U.S. Army. Software TechnoiOlY oriented lanauqes, prollramminl environ solved. Development Division of CECOM ments. evolution of lar,e software systems, We also thank Nico Habermann and Mark COMM/ADP, Fon Monmouth. 1'4.1. and in applic:ation of anirlCi&l inteililence technololY Tucker for mOllvallnl our Interest in reuuble pan by ZTI·SOF of Siemens Corp., Munich. to software development and mainlenance. and softwue. Meld IS an OUIICowth ofboch awhon' West Germany. distributed systems. Kaiser received Ihe PhD in compuler science from Cameaie MeUon Uruvmity. where she References 6. Gad E. KaUer and Simon M. Kaplan. wu a Heru Feilow. "Reiiability in DiIlnbuted Prosrammilll I. Gall E. Kaiser. "Generallon of Run-Time Environments." SIGPiGII 86 S)I"'P. COIft Environments." Pr«. SUrlr S)I"'p. R". bllil, DUlfibtllfd Dalu.. plWrCOlUlrvctfOll. ACM. New Yon. 1916, 5o/l..,.,.twt S)lflmu. CS Prcsa. loI AJamitOl, CaIlf.. pp. ~1-'7. pp.4'-55. ~. DaVid Garlan. ··Views (M TooU iD IDu 7. Thomu RfPI and Tim TeitdbaWII. ""The &rited En'lfonments." Prete. IFTP WG 1. 4 Synthnller Generalor." Pr«. SIG- 1111'1 Wo,ltsltop .~dllCltC«i Prot,.".lffut, 50ftlSIGPfM 5o/tw4rl Ut,1IWrlIq S1"'II Ell llirolf ,"'1111. SpriftJIr Vtriac. 1IrtitI. Prec/n/ Soft..,., ~""..", Ut~iroIt 1986. pp. )41-)41. ".",D. ACM, New Yorll. I .., Pel. 41~. Pmr H Ffi_ ud Gail E. KaiIa-. I. DaVld Carlan. Clwlft ViI. Kruepr, and .. Duptay·OnaMd SIncNrw M&/MCIU&1Doe a.n.r. 1. SUudl.. "A Suucnnl A".,...... De9W c.t.11ICIIIUly received lhe PhD in com ,n a "fulu-~ 5~" Prete. s.w.uAl to the M&lntmanc. of Stl'UC1urt~led puur science from Camqie McUon University. 11f1·ICo'"lJfJlw~MtdA,.uc.1OIU EnvlronmfDu," Pr«. S«OIf4 SIG where hllw !)em an active member of the Gu COIf/.. CS Prm. LOI AlanwOl. Call, .. StJ/,/S/GPfM SDftw.w £Jt,IIIftriIt, Symp. dalf UId Gnome projects. Hit theW. V;'Wf 1M 19U. pp. -'0-41. Prec,n/ Sci'''''' DrMo""..", Eltyw,," Tootr i1I/~ £JtyiloNfwltlJ.1ddtesacs the problem of tools for hiahlY int•• led .a Ravinder Chandhok er al.. "Stl'UC1urt _U, ACM, New YMII. 19M. pp • buiIdiIIa .:nviroclmenll. Editlnl- Based PrOlrammln. Envlron 166-170. His ~ in&InIU iDdude 1001 9. Thoaw itepI. rUII Teildbawa. UId A1u intesration. menu: The GNOME A~." "".,'/ softw.,.. de¥dopmerU environmentJ. reuyblc CO"'lJfJlwCoII/~8j, MIPS. RCSlOft. Oemcn.. "I ncrtmaI&aI COCILIIl-DeprncMn« software. (WICt;oaa! prosnmmin,lan,U&lcs. Va .. 198'. pp. W~-)70. An&.IyW for Unpqc-Bued Ec1i1on." educationaJ prosramminl environmentJ. and A C.W TffltU. Pro,f'GIfI"'ut, UltfWIIG IJItd S. Simon M. Kaplan and Gail E. Kaiser, ~jcl-()NII1ed sySlCmJ and IanlU&lcs. "Incremental Allnbute Eval~ III ~ S)ISImu. July IMl. pp. 4119-477. Inbuted un~Bascd EnVllonmeftts." 10. A.N. Habmnana and O. NOllliD, "Gan QuaUona aboullhi.l attic:1e CUI be ac1dtcsied Prete. Filllr SJaACT-SIGOPS S)lfftp. PnIt dalf: Sofl...,.. Devef09tDftU Environ 10 K.aiMr II ColWllbia Univenicy. Computer (ipia Dumblil«i COIffptllut,. ACM. New menu." IEEE r'GII$. SO/I ••" same:. De1*t .. New Yorll:. NY 10027; CSnet York. 1986. pp. 121-130. EII""..,.II" Dec. 1916. pp. 1117-1127. kwcrOa.coIutDbia.edu. 24 IEEE SOFTWARE ~re July 1987 THEME ARTICLES Reusability Come! of Age 6 W,ll Tracz Reusability has lon8 held out the promise of ISSUing In software's mdustnal revolution. of transformln8 a coua8e Industry IntO a mass· production system. The tools to do thu are now appeanng. Fname-Bued Software Engineerinl 9 Paul G. Ba,ss,u One of reu.sabllity's maJn problenu IS how to easily modify aVaJlable components. This frarne·ba.sed approach handles the problem. MeidiDI Software Systems from Reusable BuiJdiDI Blocks 17 Gml E. KalSlN and Dtrvld Garlillf This declarauve laJllUlae wes tbe best features from the three most popular reusability approaches. but overcomes their (law,. It supporu WlIU&IC lIldepeDdenc:e. compoaem composition. and !&ilonn,. Tbe Reusable Software Ubrary 25 BruCf A. Slmo", RItONU WiI1tk AI'I7'o". Sltpltt" A. Blziwy, KtlflVllt D. K~ltl#r. and l..invrrt A. Maya The RSL couples I pawve databue WIth interacuve cIalID tooillo make rewc an Intqral pan of Ihe software development procesa. Software Reue tJaroap BIIiIdJ .. 8IockJ 34 .'.(alffrrd Uti:. HaltS Albncltl Sdmid. and hi" F. Waif Specification. desllD. and code can all be rewed euaJy If haAc1Ied II I bwldina block. AJI IBM 110UP recently devdopcd tlus conc;epc and appij«S It 10 SyslGIII Pfop-amauJll- WIth succeu. Reusability lsaaes ucI Ada 43 A If /110111 c;.,.,.ro aDd T.L. (Ff'Mk) ~ How do you wnte reusable code wbal )'OUIIDCtbodoIOC doaD'llddraa rcwatrility? 'TheM iUldehnes devdoped by • mal« Qc{CIIM COGtnClOf lDAy bdp. 2 CaD Pro.,...." Real Soltwart? 5 Scoll ..... Woo4/Wd. Drnd W. EIrtI*7. aDd 0.1 T. Scott An ellpcnment ulted ~ WSU'IiaId ia mat 10 cvall&&U COGIpoDIDI rcwabiJity. They did poorly An rftIabWly's proauMI bolIow1 Or are tbat lOGIC IAlwen1 COlaidq VIew 01 .... aM RtdTlMP 60 GullardF'~ Reus.&ble compolMllU 1ft DOC CDOUP. PrOlJ"Ull deI&pen MId tcola Ib&t bGp u... understand Ihe compoomu aDd how to lUI u.... Fonl&AllCy. lOGIC suppon lcob do CIUII. SPECIAL FEATURE I mrHe-.etldq ucI o,a.lziq La, lOf 1M era, 74 1. Way,. A...,.,.".. WiJI_ F. (AI_y. RoMn ~. X-.. HrrlJm ,I,,(~. and Wil1/rWfJ NftUI nus Ponlble Common Lup VeT1lOQ for lbc Cray coupla the ~'s wmi1N WIth the mlclwlc's power. The researcben wbo developed the UDpMmrnllnoo IriJ bow tbcy cUd It. ,n s 0- MELDing Data Flow and Object-Oriented Programming Gail E. Kaiser Columbia University Depanment of Computer Science New York. NY 10027 (212) 280-3856 David Garlan Carnegie-Mellon University Depanment of Computer Science Pittsburgh. PA 15213 (412) 268-7698 Abstract mean the tools necessarily operated concur MELD combines concepts from data flow rently, but that the incrementality of the tools and object-oriented programming languages was enhanced by interleaving the operation of in a unique approach to tool reusability. the various tools that manipulate the same MELD provides three units of abstraction - software entities. This was made possible by equations, classes and features - that MELo's data flow facilities. For example. together allow sufficient options for symbol resolution and type checking tools granularity and encapsulation to suppon the could be defined separately to pennit the implementation of reusable tools and the same symbol resolution facilities to be reused composition of existing tools in parallel (i.t .• for different programming languages. But the interleaved) as well as in series. tools could still be interleaved. permitting the type correctness of an individual identifier use 1. Introduction to be detennined as soon as the identifier was bound to its definition. MELD started out as a data flow language oriented not towards dataflow computers but MELD evolved into an object-oriented lan towards the implementation of incremental guage as it became clear that software en~ties tools for Proaramminl environments. Our such as modules, procedures, statements. etc .• two primary lOlls were to suppon reusability could best be viewed as objects, with their of tools acrou I specaum of programming components represented as instance variables languages and software development projects, and the object-specific tool fragments as and to be able to compose tools in parallel as methods. Multiple inheritance became our well as in series. 8 y "in parallel" we do not mechanism for composing tools in parallel. since we could indicate that a fragment of one Pmft_ 10 COI'Y WlUIou\ ,.. II « c-ft oIl1111 ~ II .,.... III'O'"dId tool manipulated the same object as a frag l/\al die COCIMIIft ftC)( made « ItaIIntIutId for duKt COftImmcU ~IIIL the ACM ~I noocr &lid IIw IJUI 0I11w "",,",-- &lid Its dill ..,..... ment of another tool by making that object an and nocJCC IJ II~ tJ\Il CCClY'lIllII by ~ oldie A8CICI&DOII for instance of a class that inherited both tools. ComPlolu .... Maduncry. To COllY ~«IO ~ I'IQ\IU'III_azvU or SC*I1ic: pmn_. In the above example. an identifier class would inherit from both the symbol class 00PSlA 17 ProcIICill91 manipulated by the symbol resolution tool The data flow and object-oriented aspects and the variable class of the type checking of ~LD fit together nicely to correct these tool. defects and thus support reusable tools. One way to view MELD is: As we compared MELD with other lan ~ld a Reusabl. Modul.. + gua~es. we found that most object-oriented Data Flow + programming languages have some serious Multiple Inheritance. deficiencies when applied to the implemen Each of the components in isolation provides tation of realistic systems of tools. The an important aspect of tool definition and in primary fonn of abstraction in these lan tegration, but all three are neeaed to make the guages is the class. However. tools are. in whole thing work. general. much more comple" than classes. In this paper we present MELD using a Thus we found that previous object-oriented bottom-up approach. building up to a small languages are inadequate for defining reus e"ample programming environment consist able tools for five reasons: ing of several tools. In Section 2 we briefly 1. Granularity of abstraction is too small (a single class) to represent realistic e"plain our use of classes and multiple in tools. Most tools. such as window heritance. In Section 3 we present MELD's managers and graphics packages. in data flow notation for writing methods and volve a collection of several interre describe in Section 4 how this notation sup. lated classes. ports parallel as well as serial combination of 2. Granularity of abstraction is too large separately defined tool fragments. Finally. (a single procedure) to fle"ibly com bine the functionality of interrelated we address the consauction and composition tools. Methods may be composed by of reusable tools in Section S. serial invocation. but not by parallel composition in a sense similar to Certain aspects of MELD have been coroutines. where one tool depends on described in three previous papers [7. 11. 121. the partial results of another and vict This paper describes our past work on MELD versa. in the context of other research on object 3. The notation does not support the oriented programming languages, and parallel combination of types that define tools. This is necessary to sup presents a more detailed rationale for our port interleaving, as described in the design decisions. There is also some material previous point presented here for the fmt time. notably over 4. The boundaries of abs1l'lCtion between riding, generic modules. and compile-time tools are not enforced. Although typi consistency checking. The algorithms under cally only an object's methods may lying MELD's (running but only partially manipulale its instance variables, every class generally knows about completed) implementation are described every other class and any object can elsewhere [14, 13. 10,8]. send messages to any other object. This does not pennit infonnation hiding within tools that are larger than a single class. S. Classes cannot be parameterized to enhance tool reusability among widely divergent contexts. ; ytr zS • -% S"'=-; ~ 2. Basics abIes. a collection of methods. and inheritance information; we ignore the methods and in heritance information for now. As in Simula 2.1. Classes and Unions [5], Trellis/Owl [20] and C++ [23], instance variables are typed. MELD unions provide a Cla •• OlRcrMlf ::- -- inpu~.: uq o/EN!'In means for designating a set of alternative output.: uq 01 &Nfln types. They are used to specify the type of an c~ci: 1W6 instance variable as anyone of several classes. Cl ••• D'1'In ::- -- ti_: fIlCKSfAMP odc;in: ouaI.. The type of an instance variable is either a class, a union, or a collection. Collections fill Onion ouanr ::. the role of Smalltalk's indexed instance vari -- OU~f I puxntva ables [9] and Trellis/Owl's type generators. MELD provides four kinds of collections: ar ray, sequence, set and table. Arrays are of (* MIIUt lIteyworcla are W'ldarlinecl. .. : : •• , .. : .. , a.ncl .. I" are .pec1al. ay. fixed length and sequences are dynamic bola det1ned by MIIUt. 8u11t-in cla.... length, both accessed by index. Sets and a.ncl type coc.t~c:tor. are qivea in NItI ilMUl. *) tables are of dynamic length and are accessed by keys. A designated instance variable Fipre 2·1: Classes and Unions for Make serves as the key. The difference between sets and tables is that sets are unordered and Figure 2·1 illustrates the classes and wtiofLS tables are ordered by a particular relation defined for a tool similar to the Unix TM Make among the keys. utility (6]. Each instance of the DEPUNlT class is a dependency unit. Its functionality is to define the outputs as dependent on the in· 1.1. Mer&ina puts; whenever one or more of the inputs change in value. the outputs are recalculated 5!!!!. MQOULa ::. by applying the given command to the inputs. n ...: IIM1II1/W 1I11pOft.: Uf ./lMrfIi/IM Each input or output is an instance of the EN.. e&peft.: ..../IIaa.~ bcMIJ: IMtLDDUfIOil TITY class. maintains a timeswnp signifyinl when it was 1uc chan,ed, and indicates its !!!!!!! DlDOII't!. MQOota !! ca.0II't! origin. As deftDed by the ORIGIN union. the 5!!!!. ec.t0ll't! :: • objaocM: ~. origin may be an instance of a dependency ay.t.a: nMaOLfuz.a unit (if the object is derived) or an instance of the PRIMITIVE class (otherwise). The PRlMITIVE class has no instance variables, FJaure 2·2: Merging DEPUNlT. MODULE since it is an atomic value. Figure 2-2 shows how we merge the MELD classes are similar to those found in previously deftned DEPUNlT class and the il other object-oriented programming languages. lustrated MODULE class into the new COM· They consist of a name, a list of instance vari· PUNIT class. A module consistS of a name, a list of imported modules, a list of exported [he instance variable among the methods for procedures, types, variables, etc., and a body the separately defined superclasses. If not, written in the source code of some program MELD helps the programmer to rename one of ming language. SIGNATURE and IM the conflicting instance variables (in the con PLEMENTA TION, not shown here. would be text of this application). defined specifically for the desired program ming language. Each instance of COM 3. Methods PUNIT represents a compilation unit, and adds the object code and symbol table results of compilation to the instance variables 3.1. Data Flow Equations defined by DEPUNIT and MODULE. Cl ••• DIROWIT ::- Merging detemtines inheritance, in the -- lnput.: ,., of UTI" sense of defining a class as a specialization or output.: .., of UTI" CO~: .trlIq subclass of another class, its superc/ass. Like Aavors [16] and CommonLoops [3] and some Metbod.: other languages, MELD pennits multiple in )GD 0 --> heritance, meaning that a class may be a !!!!!! )GD !! lnput. [!!!,l specialization of more than one other class. If M1n(output.[&lll.t~) Thus the inheritance structure is a lattice - < lW&(lnput.(&lll.t~) ~ ~UnT!! •• If rather than a strict hierarchy. U.LTO --> The "Merge" clause lists the superclasses whose components are inherited by the sub class, given after the "As" keyword. Note output. :- App11(C~. lnput.) that merging is written separately, rather than Cl ••• ~IfT ::- in the body of either the subclass or the super -- t1_: fDCIIUMt classes. This supports an easy shonhand for od9ln: ouruw defining a new class that simply merges Metb0d.8: together the components provided by all its IADO --> superclasses, without addinl any new com If fypeOt(or1q1n) <> 'a%MlfIVa ponents of its own. fbee ~ lAD !! orlqln MELD permits both instance variables and CDJtCZI () ~ (!!!% !!.!!!2S. t1_. orlq1n) --> methods to be inherited. As with all systems that suppon multiple inheritance a problem arises if an instance variable or a method with (e "-->" .epazat•• t~ ..tb04 ••lector uw& fora&! pa~ ...teu h_ lta looal the same name is inherited from more than .adabhe (not .bowD In ttU. _...,h) and bocI7. "all- nlf.r. to ••cD .1. one superclass: we describe in the next sec ..at of • oelleGt1oe. .) tion how we deal with this for methods. MELD solves this problem for instance vari Fiaure 3-1: Methods for Make ables by asldng the programmer at compile time whether or not his intention is to shart Figure 3·1 shows the nuthods for the DEPUNIT and ENTITY classes. DEPUNlT n 7 "p' m: has two methods, MAKE and APPLY. messages by the run-time suppon requires MAKE forwards the MAKE message to all minimal overhead. Since the ENTITY class inputs of the dependency unit, to ensure they does define a CHANGE method. it is are up-to-date. It checks whether any input automatically invoked whenever any instance has changed more recently than any output variable of the object is modified in any way. and, if so, sends the APPLY message to the For obvious reasons. the On clause restricts dependency unit to actually rederive the out the application of the CHANGE method to puts. In MELD the statements of a method are changes to instance variables other than time not purely sequential commands, but are or origin; since the ENTITY class does not treated as a set of equations that must be define any other instance variables, the evaluated. When there are no dependencies CHANGE method is meaningless unless EN between the equations. as is the case here, TITY is merged with some other class whose they may be evaluated in either order, or con content changes in value. Thus ENTITY (and currently. The evaluation of equations is the other Make facilities) are intended to be described in detail later in this section. used in the same manner as Aavors mixins. The APPLY method calls the Apply func Like other object-oriented languages, MELD tion (not shown) on the command and input methods consist of a name or selecror, formal instance variables. Apply uses a system call parameters, local variables, and a body. The - illustrated in the next section - to ask the formal parameters and local variables are operating system to invoke the given com typed in the same manner as instance vari mand with the given inputs. and rerum the in ables. Argument transmission is the usual dicated outputs. Once computed. the origin call-by-reference, where each object is itself of each output is set to the dependency uniL passed rather than a copy. ME.l.D enforces the Since the second equation computes the out abstraction common to most object-oriented puts used in the address expression on the left programming languages: only the methods for hand side of the first equation. the second an object's class can directly modify the in must be scheduled before the f"U'St; we explain stance variables of the object shonly how we use data flow techniques to Although they look similar. as noted above, accomplish this scheduling. MELD methods are quite different from the . The ENTITY class also hu two methods. methods of other languages. Almost all If the object is nO( primitive. the MAKE mes object-oriented languages define each method sage is forwarded to rederive the object (if in a manner akin to a procedure, as a. se necessary). The CHANGE method responds quence of statements that are executed in the to MELD' s built-in CHANGE messale. order written. Message passing nonnally automatically sent by the run-time suppon to works in the same way as a procedure call: by each object that is modified by any another invokinl a method. Passinl it the actual m~thod or by an external agent (t., .• the parameterS. and waitinl for the return results. human user of the Make tool). Most classes Exceptions include certain concurrent lan do not provide a CHANGE method: since guages, notably the various Actor languages those classes that do are known at compile [2]. where methods may execute concur time. such automatic propagation of built-in rently and a sending object does not neces sarily block until receiving a response. - - , m MELD is another exception. but different 3.2. Constraints from other concurrent object-oriented lan guages in that the granularity of concurrency 9.!!! OUUlfU ::. is much finer - at the level of a statement. input:.: 1.,0/IUITI1'Y output:.: 1.,0/INU1'Y The goal here is not to maximize concur co-.nci: IIMI rency, since methods are typically so shon Claa.140001..& ::- that performance improvements by this -- nama: UUllriflW import.: ,.,0/ iA.lIli/flr mechanism are unlikely, but to suppon data e.xport.: I., 0/ SIaNAT~ flow interleaving of separately defined body: IMPLKKENTATIOV methods in order to connect these tool frag M.rqe. OUOlnl'. )(0001..& !! COKPtnlIl' Cl ••• COMl'Olnl' ::. ments in parallel; this is explained in the next -- objco4e: O-.nCl'COOI section. .y.tab: SYlGOLTULa Metboci.: • :- rIb) (* 2nci *) input.[ll :- body b :- 1;(0) (* l.t: .) ci :- 11(.) (* any U ... *) inputa[2 ••• J :- UIport.[!!!.1 Figure 3·2: Dependencies among Equations oOjoode :- output.[ll In the simplest case, the equations of a .,..ab :- output.[2l method can be evaluated in any order. (. fbe • [il· not.t10ft .0_.... the itb However. in many cases one MELD equation oa.pGnaftt of &D ordered ooll.ct10ft (ur.y. .equen_ Or tabl.) wbil•••••• perfonns a calculation using a value com refer. to the re.t of tbe 0011ect1on . ) puted by another equation; we say the first . equation depends on the second. It is then necessary to execute the second equation Figure 3·3: Constraints for COMPUNIT before the first one. in the sense of data flow When the DEPUNIT and MODULE classes languages [1]. Therefore. equation evalua are merged into the COMPUNIT class, it be tions are scheduled in the order implied by the comes necessary to specify how the inputs dependencies amona equations. USinl an and ourputs of the dependency units relate to adaptation of algorithms ori&inally developed the components of the module and the derived for incremental evaluation of attribute gram infonnation of the compilation unit. respec mars [19]. Figure 3-2 shows an example in tively. Figure 3-3 shows five assignments which the computation F(b) in the fll'St equa that act as consrraints for the COMPUNIT tion depends OIl the value b assigned by the class. The first and second together ensure second equation. Thus the second is that the inputs of the dependency unit are al automatically evaluated before the fll'St. The ways maintained as the current values of the third equation is independent of the other two. body and imponed resources of the module. and can be evaluated at any time. The third behaves as a constant defmition to set the dependency unit's command to "Compile". as appropriate for the context of module recompilation. The last two con- ~.----~. - ---- straints define the objcode and symtab in vironment, while the DEPUN1T method stance variables of the compilation unit to be derives this object code. Thus the second the first twO outputs of the dependency unit, DEPUNIT equation must execute first, fol to make sure the most recent object code and lowed by the COMPUNIT equation and the symbol table are always accessible. first DEPUNIT equation in either order (or concurrently), since neither depends on the MELD constraints are equations that are in other. dependent of any particular message. that is. they appear separately rather than as part of a method body. Constraints are automatically £!!!! DUlnIlf :: - ... re-evaluated as necessary to maintain consis tency. An assignment (":=") constraint is UPLY() --> recalculated if any argument to the right hand output.C!!!].oriq1n :-!!!! side expression or the left hand side address output. :- expression changes in value. A conditional Apply(c~. input.) ("If') is recomputed in response to changes in !!!!i!! DDtnIl!. NODtn.a !!. COMItnIl! the arguments to the conditional expression. £!!!!. CClCttnll! :: - .• , Constraints fill the same role as the active Nethocla: values of Loops [22] and some other object objooda :- outp.lta[l] oriented programming languages, to U'L'f () --> automatically maintain specified relationships !!!! lJ·te.Call(· ...aut.·.objcode) among objects. The primary difference is that !! !!!! active values are nonnally implemented using (e ·1J.te.Call- 11 on. _an. wbe~ lazy evaluation - that is, instance variables ~ .vpport. int.raction. with tbe operaUnq .y.t_ and other tac1l1ti •• on the left hand sides are recomputed only ia tbe eat.mal ea91roa.aat. e} when they are accessed; lazy evaluation is possible but not assumed for MEl.O con FilW'e 4-1: Distinct Method Definitions straints. MELD constraints are also related to I Borning's constraints [4], which are bidirec A problem arises when a method with the tional, while MELD's are unidirectional. same selector (i.e., name) is inherited from multiple ancestors. as in this example. This is solved by data flow interpretation of methods. I 4. Method InterleaviDI tor Multiple Specifically. MELD handles multiple in Inheritance heritance of methods as follows: Consider all the methods collectively defined by a par 4.1. Data Flow amona Methods ticular class. its superclasses. their super Figure 4-1 illustrates a case where distinct classe~ etc .• all the way up to the root of the APPL Y methods are defined by both the lattice. Sometimes this collection contains COMPUNIT class and its DEPUNIT super more than one method with the same selector. class. The COMPUNIT method sends the When a me5sale with this selector is received (built-in) SystemCalI message to itself to ac by an instance of the clu~ all of these tually run its object code in the external en- methods are invoked, with the schedulinl of ~-- --~ -~------______.<_2.2 ...... rt individual equations determined using the consequent inter-method assumptions by per data flow techniques previously described. mitting more than one of the candidate Thus. ~LD may interleave separately methods to be ciggered. but always in some defined methods inherited from distinct an explicit order. For example. Flavors uses a cestors. (MELD also supports overriding in mechanism similar to Loops to chose a main herited methods. as in standard multiple in method, but then orders before and after heritance; we will get to this soon.) methods nested according to the class precedence list We argue that such explicit 4.2. Ancestor Class Encapsulation ordering implies most of the disadvantages discussed above. and similarly rescicts In contrast to MELD. most object-oriented reusability to a small scale. programming languages require that such multiple inheritance of the same method be disambiguated to choose exactly one of these 4.3. Overriding methods to be ciggered by the corresponding message. This is done by explicit selection of 9:.!!!. DDtnlI~ ::. one method in the class itself. as in Nethocl.: Trellis/Owl. or by picking the first method in some strict precedence ordering of the super U'LI() --> classes - such as Loops' rule of depth-first search with respect to the left-to-right order output. :- Apply (c~. inpuU) ing given in each superclass liSL Nerq.. DU01IIf. NODt7tJl !.!. COMItnfIf We claim such solutions destroy the encap 9:.!!!. CONJtnlI~ :: •.•• sulation of functionality defined by a super Methocl.: class. The methods of a panicular superclass objc~ :- output.Cll make cenain assumptions about each other, such as that one produces instance variable UtL" () --> values to be consumed by another. These as Override output. : Saart(co..aftd. input.) sumptions are violated when method selection is detennined by incidental orderings and Fipre 4-2: Specialization name conflicts. One mi&ht argue that the or derings and name conflictS are nO( incidental, Consider the case where the programmer but carefully understood by the programmer. specializes the compilation unit to support This seems achievable only when all the an 'sman recompilation' [25]. Smart recompila cestor classes are written by the same tion refmes the granularity of dependency: in programmer or by a very small. tightly knit the original combination of the MAKE and group of programmers: large scale reusability APPL Y methods. all the outputs of depen is impossible if such detailed understanding is dency units depend on all the inputs; we now required. consider the language-specific dependencies among the source code symbols (procedure. A few languages attempt to solve the type and variable names) defmed within the problem of superclass encapsulation and the input modules. Consider the case where a r __ • 57 -n C-? X • !. module M impons a module N. Using the would be many such features. one per Make facilities as originally defined. M is a relevant programming language, that could be dependency unit that depends on N: this separately merged with the Module Intercon means that whenever N's interface changes. nection Lang feature in order to extend each M's object code must be rederived. A sman programming language with module interface recompilation strategy would keep track of facilities. the particular symbols exponed by N that are actually used by M. Suppose N expons Feature Modu~e Interconnect1on L&nq procedures p and q, and M uses only p. Then Interface: if changes to N only modify q, it is not neces sary to recompile M. This refinement is ac complished by ove"iding the APPLY method I!!II?Oru lIroqr.-i.A9 I.atl9Q&P ~ (and taking the MAKE method as is) to in ""' stead call the Sman function (not shown). Cl... ~MDOUU ::- Sman performs various checks on the com - n ... : ~'tlIJI. iJIpol:'t a: IIf 0/ iUJUi/ln pilation unit's symbol table before actually upol:'ta: IIf 0/ S1ca1.~ passing the command in a system call boCy: IlCtLKlCDUfIOli . 1M J'e.tun Moclul.i Interconneat1oQ .•• Note that there is an important tradeoff be· tween functional encapsulation of anceston; Module Interconnection Lang and functional specialization of descendants. _ Flpre 5·1:- Most other languages have dectd~T.JO-make We-have already explained that the primary specialization easy and sucheftCaP.s~lation motivatio. for MELD's unique method inter nearly impossible, while we- mUe ~-i\~~psula leaving is to increase the potential for large tion easy and specialization-sliptly more scale reusability. Unfortunately, interleaving tedious for the prograinmer, but cenainly not and other mechanisms for ancestor encapsula impossible. tion (presented shonly) are not sufficient to achieve this goal. The most imponant dif s. Reusability ficulty is that a single class, even augmented by all the instance variables and methods in herited from its ancestor lattice. is rarely suf 5.1. Features ficient to implement an interesting tool. The Figure 5-1 shows the Module Interconnec Make utility consists of several classes (and a tion Lang /IQIJ,V,. which defmes and ex~ns union); similarly. the Module Interconnection the MODULE class discussed previously. Language used in the example is not complete This feature exportS every thin I: the module without the IMPLEMENTATION and SIG class with all its instance variables and NAnJRE classes. Some mechanism is (omitted) methods. It importS the Program needed to bundle together those classes that ming Language feature. not shown. whlch together define a distinct tool or tool fragment provides SIGNATURE and IMPLEMEN that can be reused in many different applica T AnON classes appropriate to the specific tions. programming language. In practice. there MELo solves this problem by providing the feature as a unit of modularity larger [han [he The System ~odeller feature. shown in individual class. Each feature defines a tool Figure 5-2, pulls together several tools into a fragment. such as a parser. that can be reused complete system. The System ModeHer as part of many different tools. or a tool. such could in tum be reused as a tool in many as a memory manager, that can be reused larger systems, such as the Cedar environ across many systems. MELD features can be ment [24]. from which we borrowed the mixed and matched to obtain the facilities "System ModeHer" name and its basic desired for a system. functionality [15]. Note that the same name appears on both the left and right hand sides Like an Ada TM package. each feature con sists of an interface (specification) and an of two of the merges clauses. The use of implementation (body). The interface lists the "IMPLEMENT AnON" on the left hand side facilities - classes and unions - exponed refers to the facility imponed from Module Interconnection Lang (via its own impon of by the feature and the other features whose facilities are imponed. Unlike Flavors' Programming Language), while the use on the packages, the interface is soict; it is not pos right is a new subclass that merges the com sible for a client of a feature to refer to an in ponents of the imponed ENTITY and IM ternal facility through a name qualification PLEMENT A TION classes. Throughout the rest of the implementation part of this fea~ scheme. The implementation defmes suf "IMPLEMENTA nON" refers to this new ficient facilities that, perhaps together with subclass. provides this simple scoping imponed facilities, provide the required ex MELD mechanism to make it easier for feature im pons and implement the functionality of the plementors to use mnemonic naming feature. schemes. re.ture IYlt.. Modaller Thus imponed classes and unions may be used in two different ways within a feature's Interface: body: (1) as the types of instance variables (or &xport. the alternatives of unions) and (2) on the left Import. hand side of a merges clause. This means that No4ule Interconneot1oQ L&n9. M&ke. Ca.p11er •... one or more superclasses defmed by different features can be merged into a subclass' defined by another feature. In the first case, Herr' DUowt!. MCIOcn.a !! ec.tJWI! Claa. COWiOilt ::- where an imponed class is used as the type of -- .joode: C&1k!'COO8 an instance variable, the messages for that ',-U: rneoLt.Ul.I class can be sent to the instance variable. !!!!!!! arrtft. U.~!lo. ~ X.UMIII'U!Io. This capability is typical, of course, for He rr' Iftl". oi:1IcrcOO8 object-oriented languages, whether or not A. oa.7aC'tCOO8 strongly typed: messages associated with a class can always be sent to instances of that Ind r.ature Iylt .. Modeller class wherever they appear. Figure 5-3 illustrates the Make feature. It Figure 5·2: System Modeller expons the DEPUNIT and ENTITY classes, OOPSUI7 Ptoc.. dingl .. and hides ORIGIN and PRIMITIVE, since defined in other features. For example, if a these are useful only within Make. In ad method defined in the COMPUNlT class dition to the usual advantages of such infor sends the APPLY message to itself. this does mation hiding [17], this prevents proliferation not have the effect of invoking DEPUNIT's of class and union names into the global name APPL Y method. Notice that the ENTITY space, a problem with most other object class does not expon anything at all; none of oriented languages. its components are available to subclasses. It is still necessary. however, to expon the EN 'eature Mak. TITY class itself so it can be merged with other classes such as MODULE that are in Intertace: puts or outputs of dependency units. bport. O&JOWlf[1nput •• output •• Trellis/Owl and CommonObjects [21] also co-.nd. .aD]. DU1'T[] provide stronger fonns of encapsulation than I!!If!Ort. f~ most other object-oriented languages. Trellis/Owl's classes can defme methods as subtype-visible. meaning these methods are lli!! DDtnrtf ::- accessible to subclasses but not to clients. 1nput.: s., of ~I1'T output.: s.f-l D!'I1'T CommonObjects' instance variables are in a_..... : IIrVI, accessible to subclasses as well as to clients. Cla •• ~1!T ::- -- t~: fn.sUoNl Neither provides any form of module larger orlq1D: oaIQIJI than the class. however. nor any means for ~ oaxaI1l ::- restricting an arbitrary subset of a class' in DDtnrt~ I 'UIa~rva stance variables and methods from in lli!! rana!Ift ::- heritance. lnd '.ature Make (. 1'b4 In.tan_ .arJ.ul.. an4 _tboda S.2. Generic Features ava1lul. for -qiD9 are HatM be t.e.G ~ br&Aket. followlDi tbe ala•• n.- 1D tbe ....n. U ..-. .) Qeaerla W.ature .,at.. Modell.~ [Jr~--.t.D9 ~ (1IC3D!UU. IWLDlDUfIOI) 1 FilUn 5·3: Make Int."f._: DEPUNIT exportS all ics insl&nCe variables plus its MAKE method (from flame 3-1). I!p!ru to These instanCe variables are accessible sub MocIIa1. Iatera0GDe0t1oe 1.&Dq. classes of DEPUNrT. such u the previously MaU. C-.llu. described COMPUNlT. while the MAKE message can be sent by clients as well as by a compilation unit The APPLY method lnd f ••ture .,.t.. Modell." remains internal. as do SmaJIWk's private methods. but here the methods are private only with respect to clientS and subclasses FilUre 5-4: Generic System Modeller MELD allows an implementor to 6. Conclusions parameterize tools by wnung generic ~lELD's unique combination of reusable features. Figure 5-4 shows how the System modules. data flow and multiple inheritance ~odel1er Feature can be written as a generic makes it possible to define reusable tools that feature. parameterized by the Programming can be composed in parallel as well as in Language Feature. The latter consists of the series. It solves the problems posed in the in SIGNATURE and IMPLEMENTATION troduction as follows. classes, which define the boundary between 1. Granularity of abstraction in other lan the System Modeller and a particular pro guages is too small - a single class gramming language. To use such a generic - to represent realistic tools. MELD's fearures. however, allow the program feature the implementor must instantiate it mer to bundle up collections of classes with a feature, such as C, that defines the as a tool unit facilities appropriate to a particular program 2. Granularity of abstraction in other lan ming language. Instantiation binds the types guages is too large - a single proce and methods exponed by the actual feature dure - to flexibly combine the parameter to those anticipated by the formal functionality of interrelated tools. In contrast, MELD's methods are made parameter. Figure 5-5 illustrates how this is up of equations (rather than done. The resulting System Modeller has statements), which are intenwined by now been tailored to provide Make-like be the run-time suppon using data flow havior and module interface checking for C. techniques. 3. Other languages do not provide nota tion for the parallel combination of reature 'roqr..-1nq InY1ro~nt types that define tools. MELD's Interface: mug ing allows the programmer to compose tools in parallel. by combin Exporta ... ing the objects manipulated by the Importe ... tools using a special fonn of multiple SM Ie W.. SJat.. Modellar inheritance. 1h09i..-1D9 ~ • C 4. Information hiding is not enforced in (1Ica&~ • awl!'. u.LKMmI'Una. • Mn) I other languages. except within a single class. whereas feature interfaces are smctly enforced at compile-time. S. Classes in other languages are not parameterized. but generic features Figure 5·5: System ModeJIer Instantiated permit parameterization of both types and methods. enhancing tool MELD fearures are thus similar, but not reusability among widely divergent identical to Ada packages [181. Unlike Ada, contexts. generic packages features may be parameterized by other features. However, like Ada, pararneter(s) to a generic feature are Acknowled&ements We would like to thank Josephine Micallef bound at compile time. and Calton Pu for reviewing a previous draft of this paper and making many useful criticisms and suggestions. Dr. Kaiser is supported in part by grants [6] S.l. Feldman. from AT&T Foundation. Siemens Research Make - A Program for Maintaining and Technology Laboratories, and New York Computer Programs. Software - Practice &: Experience State Center of Advanced Technology - 9(4):255-265, April, 1979. Computer & Informarion Systems, and in pan by a DEC Faculty Award. Dr. Garlan is sup- [7] David Garlan. Views for Tools in Integrated En- ported in pan by the United States Army, vironments. Software Technology Development Division In IFIP WG 2.4 InternationaL of CECOM COMM/ADP. Fort Monmouth, Workshop on Advanced Program- NJ and in pan by ZTI-SOF of Siemens Cor- ming EnvironmentS. Trondheim. poration, Munich. Germany. Norway, June. 1986. Lecture Notes in CompUler Science 244, Springer-Verlag. 1986. References [8] David Garlan. [ 1] William B. Ackennan. Views/or Tools in Integra~d Data Aow Languages. Envirol1l'MnlS. Computer 15(2): 15-25. February. PhD thesis. Carnegie Mellon U niver- 1982. sity. May. 1987. [2] G. Agha. [9] Adele Goldberg and David Robson. Actors: A MotUl of Concurrent Com- Smalltalle-80 TM Language and iu putation in Distributed Systems, Implemenuuion. MIT Press. Cambridge. MA, 1986. Addison-Wesley Pub. Co •• Reading. MA.1983. [3] Daniel G. Bobrow. et al.. CommonLoops: Merging Corrunon [10] Gail E. Kaiser. Lisp and Object-Oriented Pro- Semantics of Structure Editing gramming. Envirol1l'MnlS. In ACM Conference 011 Object- PhD thesis. Carnegie Mellon Univer- Oriented Systems. Languages, and sity, May, 1985. AppU'cariollS. plges 17-29. Technical Repon CMU-CS-8S-131. Ponland. OR. September. 1986. [11] Gail E. Kaiser and David Gulan. [4] A. H. Borninl. MELDing Software Systems from Cons~ts and Functional Program- Reusable Building Blocks. nung. IEEE Software 4(7). July, 1987. In Sixth A1UWQJ bu.nt4lioNJi PhoellU [12] Gail E. Kaiser and David Gulan. I Cotr/.rence 011 ContpUlers and MELD: A Declarative Notation for C olftlfllUlictJliollS. pages 300-306, Writing Methods. Sconsdale, AZ. February, 1987. In Sixth Anllual Interfllltiofllll Ph.oe7tU [5] Ole-Johan Dahl and Kristen Nygaani. Conference 011 COmpUltrS and SIMULA- an ALGOL-Based COmnuuUcan'ollS, pales 280-28S. Simulation Langulle. Scorudale. AZ. February, 1987. CommunicQtUJIIS of tM ACM 9(9):671-678. September. 1966.