The Design of ObjectOriented MetaArchitectures For Programming Languages Guruduth Banavar and Gary Lindstrom Department of Computer Science University of Utah Salt LakeCity Abstract This pap er is a survey of the design of four ob jectoriented metalevel architectures for programming languages We presentoverviews and compare the salient features of the meta architectures of Smalltalk Common Lisp Ob ject System CLOS a Scheme Compiler and Etyma our framework for mo dular systems This comparison claries imp ortantarchitectural asp ects of the surveyed systems such as the space of concepts captured bythearchitectures and the abstractions that emb o dy similar language concepts across the architectures We nd that there are considerable dierences in the goals and conceptions of these architectures yet they can all b e used for similar applications Finallywe p oint out some strengths and weaknesses of the architectures surveyed Intro duction Ob jectorientation is a p opular design technique that has b een used to mo del application domains of all varieties A recently emerging trend is to apply the ob jectoriented O O metho d to the design of OO language pro cessors themselves thereby harnessing the much touted advantages of abstraction and reuse in this domain also For example the Meta Ob jects of the CLOS MetaOb ject Proto col MOP is an OO mo del of certain useful concepts in CLOS A recently prop osed OO mo del for a compiler for a non OO language Scheme is another example One of the earliest OO programming systems Smalltalk was itself built up on an intricately interconnected group of metaclasses The ab ove languages emb o dy OO metalevel architectures or metaarchitectures for short in the sense that they mo del the fundamental concepts in the language suchas class and methodasinteracting metaclasses This has resulted in reective exible and extensible language designs Many of these advantages stem from the fact that reied metaclasses are candidates for systematic reective access That is a system that has a welldesigned metaarchitecture can essentially provide users not only with its standard This researchwas sp onsored bytheAdvanced Research Pro jects Agency DOD monitored bythe Department of the Navy Oce of the Chief of Naval Research under Grantnumb er NJ The views and conclusions contained in this do cument are those of the authors and should not b e interpreted as representing ocial p olicies either expressed or implied of the Advanced Research Pro jects Agency or the US Government Contact author G Banavar Computer Science MEB University of Utah Salt LakeCity UT USA email banavarcsutahedu phone fax interface but with an alternativeinterface a side do or to the internal architecture whichistypically a subset of the metaarchitecture interface Information access and renement via this alternativeinterface can enable applications to netune a language implementation to suit its particular needs Metaclasses can b e sp ecialized to suit sp ecic tasks using standard OO techniques such as inheritance In a compilation setting meta classes can even b e sp ecialized to statically optimize runtime data layout or generate optimized co de for particular sp ecial cases It is imp ortant to clarify the relationship b etween the concepts of metaarchitecture reection and metaobject protocol MOP A metaarchitecture mo dels systematically implements and do cuments the fundamental concepts of a system A metaarchitecture is OO if the concepts are mo deled as collab orating classes A system is reective if its users haveintrosp ective ie read andor intercessory ie mo dication access to the internal implementation of the system Finally a MOP do cuments and illustrates a disciplin ed metho d of reective access to a carefully chosen subset of a systems OO metaarchitecture The semantics of a programming language is rarely made formally explicit in the lan guage implementation let alone made usefully accessible from within the language itself This may b e due to the fact that the design of programming languages is generally con sidered to b e an amorphous creative activity carried out by the b est exp erts in the eld However this need not necessarily b e the case an imp ortant p oint of this pap er is that the design discipline encouraged by ob jectoriented metho ds can b e fruitfully applied to the design of programming languages themselves Furthermore a signicant part of the semantics of a language can b e reied as an OO metaarchitecture A welldesigned meta architecture enables reuse reection and the design of a suitable MOPandthus brings the advantages mentioned ab ove The traditional architecture for pro cessing high level languages involves the following usually separate languages the source language the target language this is not signicant in the case of direct interpreters and the pro cessor description implementation language An imp ortant observation is that the metaarchitecture of a language is expressed in its pro cessor description language From this it follows that a language can havemultiple meta architectures corresp onding to multiple pro cessor descriptions each designed with dierent requirements It also follows that a languages metaarchitecture need not necessarily b e metacircular ie expressed in the source language itself In fact in order to have an OO metaarchitecture a language need not even b e ob jectoriented However its implementation language must The metaarchitectures of dynamic languages suchas Smalltalk are metacircular since a large part of the language is implemented using the language itself as is its metaarchitecture In this pap er wecontrast the three metaarchitectures mentioned ab ove Smalltalk CLOS MOP and the Scheme compiler MOP along side our own metaarchitecture based on a language called Jigsaw Smalltalk and CLOS are generalpurp ose OO languages that enjoy signicant followings Smalltalk was built groundup based on a remarkably coherent metaarchitecture while the metaarchitecture for CLOS was retrotted onto the language The Scheme compiler MOP shares the goals of the CLOS MOP but is signicantly dierent from the ab ovetwosinceScheme is not OO and its MOP is compile time oriented Finally our framework Etyma attempts to generalize and bring together many of the concepts from the ab ove metaarchitectures The pap er continues by discussing the design issues investigated in this survey followed by detailed descriptions of the four metaarchitectures under consideration Finallywe provide a summary of architectures and conclude Design Issues The design of metaarchitectures for languages is driven byvarious considerations In this section we outline some of the issues that govern the design of metaarchitectures the main categories b eing i the prestated design goals of the language as governed by the requirements of applications and ii the requirements of semantic mo dels of languages also driven by applications ie how the abstractions of metaarchitectures must capture the crucial semantics of their languages Goals and Application Requirements Consider the comp eting goals of generality vs backwardcompatibility A primary requirement in the design of the CLOS MOP was backward compatibility with several existing LISP Ob ject systems whichwere pairwise incompatible The reneability of the ob ject mo del enabled by the MOP essentially brought ab out the backward compatibility Hence it was sucient to mo del just the ob ject system in the metaarchitecture in such a manner that backward compatibility can b e achieved One can imagine that the meta architecture in such a scenario could b e markedly constrained by the existing ob ject mo dels On the other hand the Smalltalk and Etyma metaarchitectures were built from scratch based up on a uniform mo del ie every concept in these systems is mo deled in the meta architecture Moreover Etyma was designed from the start with the explicit purp ose of abstracting semantic commonalities in mo dulebased languages and systems As a result the abstractions provide a clean mo dule and inheritance mo del leaving the rest of the language design op en An imp ortant application of metaarchitectures is the supp ort for exibili ty and ex tensibility of a language via reection and MOPs In addition to introsp ective access a MOP typically provides intercessory access to metaob jects making it p ossible to rene them incrementally using standard OO techniques and hence amend the existing language design itself The user can dene new metaob ject classes as sp ecializations sub classes of the standard metaob ject classes rening their b ehavior as necessary The most imp or tant goal of the CLOS and Scheme compiler metaarchitectures is to provide a metaob ject proto col for users This has led to the pragmatic design goals of i controlled and care fully do cumented user extensibility ii interop erability of separately designed extensions iii eciency via user sp ecialization and iv ease of use In the context of MOP design there is a tradeo b etween implementor freedom and user extensibility The CLOS MOP designers deal with this tradeo by explicitly sp ecifying restrictions on the usage of the MOP Given reective access to its metaarchitecture a languages source programs are made up of base language co de intersp ersed with metaco de ie the co de that accesses the metaarchitecture One design issue in such systems is the execution time of metacode Dynamic environments like Smalltalk and CLOS require metaco de to execute at run time while the Scheme MOP runs metaco de at compiletime Dynamic architectures