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

exhibit metacircularity and hence a tight coupling b etween the language and the meta

architecture While this coupling enhances application development exibility it causes

the metalevel architecture to b ecome dicult to disentangle from their base languages for

separate reuse

The need for selfapplicabil itymetacircularity is an imp ortant design issue It is a

fundamental requirement in the dynamic environments of Smalltalk and CLOS MOPItis

not even p ossible in Scheme since it is a non OO language with an OO metaarchitecture

The requirements of static typing and separate compilation make it imp ossible to express

the Jigsaw language on whichEtyma is based using itself The details of this are b eyond

the scop e of this pap er

A language metaarchitecture supp orts reuse of design and co de just as a domain sp ecic

OO framework do es OO frameworks for several domains have b een constructed

Similarly an OO framework can b e used as a reusable domain mo del for OO languages

and systems indeed this is a primary goal of Etyma

An imp ortant use of metaarchitectures is as an aid in understandingmaintaining the

system Another use is the construction of program analysis tools such as browsers and

debuggers Sp ecic metaarchitectures have also b een used for other applications suchas

persistence

Requirements of Semantic Models

In addition to general goals such as the ab ove metaarchitecture designs have several se

mantic requirements For instance typ echecking is an imp ortant issue that must b e taken

into early consideration when building a metaarchitecture Although metaarchitectures

are considered extensible the design decisions in the area of typing built into existing archi

tectures p ervade the entire mo del and make it hard to retrot signicant static semantics

Another example of a fundamental requirement is the semantics of inheritance

Feature Smalltalk CLOS MOP Etyma

Inheritance Single Multiple Unbundled

Encapsulatio n Ob jectlevel none Ob jectlevel

Metho d dispatch Single GenericMulti Single

Static Typing No No Structural

Figure Selected OO semantics of surveyed languages

By its very nature the metaarchitecture of a language captures and constrains the

semantics of the base language The space of highlevel language semantics is broad and a

subspace of it must necessarily b e carved out by a particular metaarchitecture The larger

the subspace the more complex and p otentially less useful the metaarchitecture Once the

subspace is chosen the particular way in whichsemantic concepts within this subspace are

mo deled is also signicant Furthermore the lo cation of the p oint representing the base

semantics of the language must b e chosen within this subspace Figure tabularizes a

sample of OO semantic choice p oints of the languages surveyed here In the following sec

tions we describ e the sp ecic semantics captured by metaarchitectures for OO languages

in detail including supp ort for inheritance encapsulation metho d dispatch instantiation

static typing and abstract classes

Wenow turn to a more detailed treatment of sp ecic metaarchitectures

Smalltalk

Smalltalk is based on a uniform mo del of communicating ob jects It has a small number of

concepts ob ject class instance message and metho d Every concept in the system is

mo deled as an ob ject either instantiable class ob ject or not instance ob ject The most

primitivelowlevel op erations in the system are delegated to a virtual machine Ob jects

communicate via messages the semantics of messages are implemented by receivers as

metho ds

Smalltalks notion of ob jects is captured by class Object which provides the basic

semantics including message handling of all ob jects in the system The semantics of

classes is captured by class Class along with its sup erclass Behavior which denes the

state required by classes such as for instance variables and a metho d dictionaryFurther

the class CompiledMethod emb o dies the notion of a class metho d this class denes a

metho d valueWithReceiver to evaluate itself The OO semantics of Smalltalk captured

by the metaarchitecture is given in Figure

Inheritance The class Class implements a message subclass which accepts one

class parameter the sup erclass thus implementing single inheritance The

sub classes of Classwhich are the metaclasses of individual classes inherit

the metho d subclassthus individual class ob jects also resp ond to this

message The assumption that classes have a single sup erclass p ermeates

the system Inheritance of state and metho ds is captured by the sup erclass

of Classclass Behaviorwhich implements metho ds to compute the set

of instance variables and metho ds available to instances of a class

Message handling Class Object denes a metho d performwithArguments that handles

message dispatch using a primitive metho d of the Smalltalk virtual ma

chine There is also a class MessageSend that captures the notion of a

messagesend However for eciency an instance of this class is not cre

ated for every messagesend in the system

Encapsulation Instance variables are encapsulated in Smalltalk Metho d handling co de

searches only the metho d dictionary of a class but not the instance vari

ables Metho d ob jects have access to instance variables since they refer to a

scop e ob ject that records the variable ob jects accessible within that scop e

Instance creation Class Behavior the sup erclass of class Class denes a message new

which calls a primitive message to create an instance of the receiver which

must b e a class

Figure Smalltalks OO semantics

Smalltalk is a dual hierarchy language as are most ob jectoriented languages That

is it has a cleanly articulated classsub class hierarchyaswell as a classinstance hierarchy

In most languages however the classinstance hierarchyisnotinteresting since it comprises

only two levels that of all classes and all instances In Smalltalk this hierarchyisdeeper

and is recursive as describ ed b elow

Every ob ject in Smalltalk is an instance of some class Since classes themselves are

ob jects each class ob ject is an instance of yet another class usually referred to as a

metaclass ob ject For example a class Foo is an instance of its metaclass given by the

expression Foo class Such metaclass ob jects are themselves instances of an ordinary class

called Metaclass The metaclass of class Metaclass itself is given by Metaclass class

which is also an instance of class Metaclass just as Foo class is The ab ove recursion

puts an end to the innite regression of metaclasses

Consider the classsub class hierarchy of metaclasses Every class in Smalltalk inherits

from class Object hence the sub class hierarchy is a singly ro oted tree The class Metaclass

mentioned ab ove is also a sub class of Object The instances of class Metaclass such

as Foo class Metaclass classandeven Object class are all metaclasses These

metaclasses are sub classes of class Class which is a sub class of class Object

In Smalltalk the metaarchitecture is really innitely op en in the sense that every

single concept in the system except some primitive op erations that are p erformed directly

by the virtual machine is captured as an ob ject which users can not only sp ecialize but also

browse and access ie directly edit and mo dify which of course is strongly discouraged

CLOS MOP

As mentioned earlier a primary requirement in the design of CLOS was backward compat

ibility with existing LISP systems It was recognized that these incompatibilities could b e

reconciled if a family of languages rather than a single one were dened Thus the CLOS

metaarchitecture was designed to facilitate mo deling an entire space of language designs

with the default CLOS design b eing a distinguished p oint Furthermore a proto col MOP

has b een carefully designed and do cumented to access this metaarchitecture usefully

The CLOS ob ject system supp orts the standard concept of classes which can b e in

stantiated into instances Class attributes are called slots A distinguishing feature of

the CLOS mo del is the notion of generic functions which are dened indep endentofany

class and can b e sp ecialized into methods that are applicable to sp ecic classes Generic

functions can b e dispatched based on multiple arguments multimetho ds

The CLOS metaarchitecture sp ecies the following basic metaob ject classes corre

sp onding to the basic concepts of the language class slotdefinition generic

function and method All userdened metaob jects must b e designed to b e sub classes of

one of the ab ove metaob ject classes The sp ecied default semantics of the CLOS lan

guage are emb o died by sp ecializations of the ab ove classes with names b eginning with

standard eg standardclassand standardmethod The manner in which the

metaarchitecture captures basic OO semantics in CLOS is given in Figure

The classsub class hierarchy of the CLOS metaarchitecture is as follows At the ro ot

is class t which has one sub class standardobject capturing the semantics of all ob jects

in the system Every class created in the system must have standardobject as its

sup erclass One sub class of standardobject is the class metaobject of which the basic

metaob ject classes mentioned ab ove are sub classes

The classinstance hierarchyofCLOSessentially has four levels Individual CLOS

classes are instances of class class or one of its sub classes Class class is an instance of

its own sub class standardclass as are most other metaob ject classes

The CLOS MOP has functions for systematic introspective access to its metaob jects

For example the programmer can access the class metaob ject of a given ob ject the

The actual sub class hierarchy of Smalltalk is slightly more involved than what is describ ed here due to

the desirability of symmetric class and metaclass hierarchies but the given description will suce for this discussion

Inheritance Generic functions sp ecialized on the class metaob ject class implement

the semantics of multiple inheritance A class precedence list ie a total

ordering on a class sup erclasses is computed by the generic compute

classprecedencelist The generic function computeslots com

putes the full set of slots accessible from instances of the class The

semantics of slot prop erty union is implemented by computeeffective

slotdefinition whichiscalledby computeslots The generic func

tion classdefaultinitargs computes the full set of initialization ar

guments required by the class

Generic invo cation A discriminating function asso ciated with a genericfunction metaob

ject provides the semantics of multimetho d dispatch The dis

criminating function is computed by a generic function compute

discriminatingfunction Dispatch pro ceeds by rst nding the set

of applicable metho ds for the given set of arguments from the set of all

metho ds asso ciated with the generic function metaob ject via compute

applicablemethods and computing an eective method via compute

effectivemethod

Slot access The function slotvalue a wrapp er for the generic function slot

valueusingclass is used for slot access The generic function itself is

sp ecialized to class and slot metaob jects implementing the semantics of

slot access in CLOS ob jects

Instance creation The generic function makeinstance and allocateinstance b oth sp e

cialized to class metaob ject class implement instance creation Prior

to creating an instance of a class it is nalized by computing the actual

structure of the class as describ ed under inheritance ab ove

Figure CLOSs OO Semantics

class metaob jects name sup erclasses slots each of which is a metaob ject on its own

sub classes and metho ds The details of each slot metaob ject generic function and metho d

can also b e accessed Using these functions it is p ossible to for example reconstruct a

textual description of an ob jects class

CLOS MOP is a layered proto col ie the proto col sp ecies metaarchitecture func

tionalityatvarious levels of detail with higher levels delegating work to lower levels so

that userrenement can b e made at various granularities of semantics For instance a top

layer proto col concerned with inheritance is the generic function finalizeinheritance

which delegates to the next layer computeclassprecedencelist and computeslots

which further delegates to computeeffectiveslotdefinition

A large numb er of applications that the CLOS MOP can b e put to are illustrated in

These include sp ecialized classes suchascounted classes and encapsulated classes CLOS

MOP has also b een utilized to provide a signicant p ersistence facility

Etyma

Etyma is a general metalevel architecture for OO languages realized as a C framework

in the sense of The primary abstractions of Etyma are based on a language called

Jigsaw a mo dule manipulation language designed to mo del the semantic foundations of

ob jectorientation esp ecially inheritance in all its forms A basic premise of this work is

that OO concepts prop erly formulated can b e applied not only to traditional program

ming language design but for the broader design and implementation of OO programming

systems suchaslinkersloaders library management to ols conguration management sys

tems typ e checkers etc We name our framework Etyma the plural of etymon taken

from the etymology of etymology since it is a collection of ro ot concepts from which

other concepts are formed by comp osition or derivation

In Etyma as in Jigsaw the central concept is that of a module akin to a class which can

b e informally dened here as any software unit that provides a set of services as sp ecied by

its interface A mo dule consists of a set of lab els identiers each asso ciated with either i

a value eg an integer a function in a languages value domain or a type in the languages

typ e domain or ii a location in which case the lab el corresp onds to a mutable instance

variable or iii a nested mo dule or its interface The key characteristic of this mo del is

that mo dules can b e combined using a suite of unbundled and general mo dule combinators

to achievevarious eects of inheritance sharing and encapsulation A summary of the

key semantics captured by the metaarchitecture is given in Figure

Inheritance The semantics of the usual kinds of inheritance is supp orted by some combi

nation of the primitive op erators merge overrideand copy aswithvari

ous other eects achieved via the op erators rename restrictand freeze

All of these op erators are implemented as metho ds of class Module

Typing A static typ e system with subtyp es and inherited typ es is supp orted The

structural typ e of mo dules is captured by class InterfaceEtyma also has

a hierarchyoftyp e metaclasses to capture the typ e space of programming

languages

Encapsulation Supp orted bythe hide op erator of Module Hidden attributes are removed

from a mo dules interface and are accessible only by a class own metho ds

Metho d dispatch Supp orted bytheselect metho d of class Instance In the default case

select dynamically dispatches on attribute name

Abstract classes Mo dules can have attributes whose typ es are declared but which are not

dened Such mo dules corresp ond to abstract classes and cannot b e

instantiated

Instantiation Supp orted by the metho d instantiate of class Module which returns an

ob ject of class Instance

Figure EtymaJigsaw OO semantics

The classsub class hierarchyofEtyma has class Etymon at the ro ot A sub class Typed

Value emb o dies the typ ed value domain of languages and another sub class Type embodies

the corresp onding typ e domain Class Module is a sub class of TypedValue as is class

Instance but via class Record There is a parallel typ e hierarchy with classes Interface

InstanceType and RecordType

In wehave describ ed a preliminary C prototyp e implementation of Etyma The

design of abstractions in Etyma has b een guided mostly by semantic concerns with ideas

based on a denotational description of the Jigsaw language Etyma can b e used to describ e

and build pro cessors for many systems that can b e construed to b e mo dulebased Lan

guages that are derived from the framework are called client languages and pro cessors for

them are constructed by extending the framework The client language is in general unre

lated to the framework implementation language an extension of Mo dula Mo dula

is presented in and examples of simple languages based on C are given in Etyma

is b eing used as the metaarchitectural framework for a larger initiative for evolutionary

supp ort for mo dular architectures in which a mo dulebased serverstyle linkerloader is

b eing designed as an extension In this extension UNIX o and so ob ject les are

regarded as sp ecializations of class Modulethus enabling the use of comprehensive inheri

tance semantics and typ e checking in their comp osition

A MOP for Scheme Compilers

Like the CLOS MOP this MOP carefully cho oses a useful p ortion of the internal function

alityofascheme compiler in order to provide the Scheme programmer with the desirable

attributes of exibility and control over layout and access over runtime data Many of the

details of this MOP are still under development so we only give a general description

of it

Unlike the CLOS MOP this is a compiletime MOP ie the accessible metaarchitecture

is sp ecializable to control the static behavior of the compiler Such static sp ecialization is

utilized at runtime However metaco de the co de that accesses the MOP is not executed

at runtime This architecture decouples the language of the static pro cessor compiler

and hence the metaarchitecture from the source language itself thus it is not meta

circular The metaarchitecture is expressed in an OO extension of LISP called Traces

This metaarchitecture attempts to capture certain asp ects such as pro cedures and

pairs of a non OO base language Scheme

The primary abstraction in this metaarchitecture is what is termed a contract A

contract metaobject represents a group of interrelated source program fragments that must

agree on the layout of runtime data For example a lambda abstraction and all applica

tions of ie calls to it would b e such a group Contracts essentially capture the notion

that an abstraction and its uses must statical ly agree on conventions such as runtime lay

out Other such static contracts include cons pairs along with its accessors car and cdr

and let environments along with their variable accesses

Dep endencies b etween abstractions and their uses are traced byow analysis on source

program fragments captured as program graph metaobjects Source programs are trans

lated into a register transfer language captured as RTL metaobjectsFor instance when a

function application is required to generate co de it delegates the job to its contract metaob

ject which further requests the appropriate program graph metaob jects to generate RTL

metaob jects

A few applications of the Scheme MOP are illustrated in These include extending

the base Scheme language to supp ort pro cedures with extra data attached to them im

mutable data structures and pro cedures that are dispatched based on the numb er of input parameters

Summary and Conclusions

In this section we attempt a summary of the metaarchitectures surveyed Of course it is

imp ossible to provide a comprehensive summary of the depths of the metaarchitectures

instead wegive a broad comparison of some essential asp ects

Figure shows the abstractions b oth OO eg class and nonOO eg function

captured as metaclasses by the architectures Figure gives a comparative summary of

the architectures in the areas of inheritance metho d dispatch encapsulation and static

typing

Smalltalk CLOS MOP Etyma Scheme

Meta Metaclass none none NA

Class Class standardclass ModuleInterface NA

Instance Object standardobject InstanceInstanceType NA

Function BlockClosure none FunctionFunctionType lambda contract

Variable Variable none LocationLocationType let contract

PrimitiveValue Magnitude etc none PrimValuePrimType primitive contract

Figure Summary of selected abstractions

Inheritance In Smalltalk the class Behavior and its sub class Class together mo del

single inheritance semantics In CLOS MOP generic functions sp ecial

ized to class class mo del multiple inheritance semantics In Etyma class

Module implements unbundled inheritance op erators The default seman

tics of inheritance is signicantly broader in EtymaJigsaw compared with

the defaults in either Smalltalk or CLOS MOP

Metho d dispatch In Smalltalk metho d dispatchisdonebytheperform metho d of

class ObjectInCLOSMOP a discriminating function asso ciated with

class genericfunction p erforms metho d dispatch In Etyma it is done

by the metho d select of class Instance CLOS MOPby virtue of its very

general mo del of generic functions and multimetho ds provides the most

sophisticated metho d dispatch semantics

Encapsulation Smalltalk supp orts strong encapsulation of instance variables and Et

ymaJigsaw encapsulates mo dule attributes sub jected to hide op erations

CLOS MOPs default encapsulation semantics is weak although metaob

jects could b e sp ecialized using the MOP to supp ort b etter encapsulation

Static typing Static typing and separate pro cessing of mo dules are highly desirable at

tributes for languages The Jigsaw language supp orts static typ e rules

whichhave b een incorp orated into Etymas Interface abstraction Et

yma also incorp orates a comprehensive mo del of typ e metaclasses Sucha

mo del is practically absent in the other metaarchitectures

Figure Summary of OO semantics

Although Smalltalk cannot b oast generality in the area of inheritance it still provides

the most uniform and comprehensive mo del of concepts as ob jects in its metaarchitecture

It is also the most comprehensively designed metaarchitecture considering the complexity

of the interacting dual hierarchies of metaclasses The CLOS MOP on the other hand

provides a pragmatic and systematically do cumented MOP making it the most useful to

applications EtymaJigsawprovides signicant generality compared with the other archi

tectures but its utilityisyet to b e demonstrated The Scheme MOP is as yet exp erimental

and in the pro cess of b eing develop ed but is unique and very promising

Smalltalk is the clear winner in the area of abstractions for non OO concepts in the

language The abstractions are general broadly conceived and uniform The Scheme MOP

attempts to capture only those basic concepts in the language which are imp ortantfrom

a compilation standp oint Etyma is currently attempting to design general abstractions

covering the space of basic values and typ es in some commonly found languages

In conclusion metaarchitectures are p owerful exible and extensible by their very na

ture There are considerable similarities and dierences in the goals that the architectures

surveyed here are trying to achieve as well as in their conceptions Eachwas designed

with a dierent set of requirements yet they can b e used for similar applications The

space of metaarchitectures span from the pragmatic to the very general In this pap er

wehave surveyed the goals semantic mo dels and applications of four metaarchitectures

Smalltalk CLOS MOPScheme compiler and Etyma and highlighted their salient

features

Acknow ledgments

We gratefully acknowledge useful discussions and input from Gregor Kiczales Bob Kessler and

Tim Mo ore

References

Johnson R E and Russo V F Reusing ob jectoriented designs Tech Rep

UIUCDCS University of Illinois at UrbanaChampagne

Kiczales G des Rivieres J and Bobrow D G The Art of the Metaobject Protocol

Cambridge MA The MIT Press

Lamping J Kiczales G Ro driquez L and Ruf E An architecture for an op en

compiler in Proc of the IMSA Workshop on Reection and Metalevel Architectures

Goldb erg A and Robson D Smal ltalk The Language and its Implementation

AddisonWesley

Bracha G and Lindstrom G Mo dularity meets inheritance in Proc International

Conference on Computer Languages San Francisco CA IEEE Computer So ciety pp

Also available as Technical Rep ort UUCS

Bracha G The programming language jigsaw Mixins mo dularity and multiple

inheritance PhD thesis University of Utah Technical rep ort UUCS pp

Keene S E ObjectOrientedProgramming in Common Lisp Reading MA Addison

Wesley

Lee A H The p ersistent ob ject system MetaStore Persistence via metaprogram

ming PhD thesis University of Utah Technical rep ort UUCS pp

Banavar G and Lindstrom G A framework for mo dulebased language pro cessors

Computer Science DepartmentTechnical Rep ort UUCS University of Utah

Orr D B and Mecklenburg R W OMOS An ob ject server for program execu

tion in Proc International Workshop on Object OrientedOperating SystemsParis IEEE

Computer So ciety pp Also available as technical rep ort UUCS

Banavar G Lindstrom G and Orr D Typ esafe comp osition of ob ject mo dules

in Computer Systems and Education In honour of Prof V Rajaraman pp Ban

galore India Tata McGraw Hill Publishing Company Limited ISBN Also

available as Technical Rep ort UUCS

Kiczales G Lamping J and Mendhekar A What a metaob ject proto col based

compiler can do for lisp Unpublished rep ort A mo died version to b e presented at the

OOPSLA workshop on OO Compilation

Kiczales G Traces a cut at the make isnt generic problem in Proc of Intl

Symposium on Object Technologies for Advanced Softwarevol of Lecture Notes in Com

puter Science Springer Verlag