LISP AND SYMBOLIC COMPUTATION An International Journal

c

Kluwer Academic Publishers Manufactured in The Netherlands



Balancing the EuLisp Metaob ject Proto col

y

HARRY BRETTHAUER bretthauergmdde

JURGEN KOPP koppgmdde

German National Research Center for Computer Science GMD

PO Box W Sankt Augustin FRG

HARLEY DAVIS davisilogfr

ILOG SA avenue Gal lieni Gentil ly France

KEITH PLAYFORD kjpmathsbathacuk

School of Mathematical Sciences University of Bath Bath BA AY UK

Keywords Ob jectoriented Programming Language Design

Abstract The challenge for the metaob ject proto col designer is to balance the con

icting demands of eciency simplici ty and extensibil ity It is imp ossible to know all

desired extensions in advance some of them will require greater functionality while oth

ers require greater eciency In addition the proto col itself must b e suciently simple

that it can b e fully do cumented and understo o d by those who need to use it

This pap er presents the framework of a metaob ject proto col for EuLisp which provides

expressiveness by a multileveled proto col and achieves eciency by static semantics for

predened metaob jects and mo dularizin g their op erations The EuLisp mo dule system

supp orts global optimizations of metaob ject applicati ons The metaob ject system itself

is structured into mo dules taking into account the consequences for the compiler It

provides introsp ective op erations as well as extension interfaces for various functionaliti es

including new inheritance allo cation and slot access semantics

While the overall goals and functionality are close to those of Kiczales et al the

approach shows dierent emphases As a result time and space eciency as well as

robustness have b een improved



This article is a revised and extended version of

y

The work of this pap er was supp orted by the joint pro ject APPLY Ilog SA the

University of Bath the British CouncilDAAD ARC program and the EuLisp working

group

The joint pro ject APPLY is funded by the German Federal Ministry for Research and

Technology BMFT The partners in this pro ject are the University of Kiel the Fraun

hofer Institute for Software Engineering and Systems Engineering ISST the German

National Research Center for Computer Science GMD and VWGedas

BRETTHAUER KOPP DAVIS PLAYFORD

Intro duction

Recently ob jectoriented languages with metaob ject proto cols have b egun

to gain acceptance A metaob ject proto col extends the default semantics of

an ob jectoriented language with an op en do cumented proto col allowing

the programmer to extend the base language in directions appropriate for

his application Instead of b ending the application to t the language

the programmer b ends the language to t the application Ideally many

such extensions can p eacefully co exist within the same basic framework

the language will treat the extensions homogeneously

Additionally metaob ject proto cols can provide generalized reective fa

cilities which allow the construction of debugging environments insp ectors

and other to ols which manage all ob jects via the same set of op erations

The state of the art in metaob ject proto col design is b est describ ed in

The Art of the Metaob ject Proto col by Gregor Kiczales Jim des Rivieres

and Daniel G Bobrow Indeed it is still an art rather than a science

to dene elegant and useful ob jectoriented programs and the problem is

comp ounded for a program as general as a language Kiczales et al present

an elab orate and tested metaob ject proto col MOP for the Common Lisp

Ob ject System CLOS Furthermore they intro duce the essential

problems to the reader and show various techniques which can b e used to

solve them Op en questions and unsolved problems are presented to direct

future work

One of the main problems is to nd a b etter balance b etween expressive

ness and ease of use on the one hand and eciency on the other

Since the authors of this pap er and other memb ers of the EuLisp

committee have b een engaged in the design and implementation of an ob ject

system with a metaob ject proto col for EuLisp intended to correct some

of the p erceived aws in CLOS to simplify it without losing any of its

p ower and to provide the means more easily to implement it eciently

The current status of this work is reected in the EuLisp denition The

ob ject system TEO has b een implemented with minor variations in

1

the public domain EuLisp implementation FEEL in the commercially

1

available dialect LeLisp version in Common Lisp and in

1

Scheme TEO is used as the base for a set of articial intelligence

and graphic programming to ols marketed by Ilog SA The exp ert system

2

workb ench babylon marketed by VWGedas uses MCS which is

closely related to TEO Most of these to ols extend the kernel ob ject

language provided by TEO using the metaob ject proto col

1

All three implementation s are available via anonymous ftp from host ftpbathacuk

in the directory pubeulisp

2

MCS is available by anonymous ftp from langlispmcs on ftpgmdde

BALANCING THE EuLisp METAOBJECT PROTOCOL

This work builds not only on CLOS but also on a series of Europ ean

work on simple reective ob jectoriented architectures in Lisp including

work on ObjVLisp the Micro Flavor System Micro Common Fla

vors and the Meta Class System MCS

Design Context

TEO is an integrated part of the EuLisp language denition In de

scribing it we cannot completely isolate the ob ject system from the rest of

the language There is a strong synergy b etween the rest of the language

and the ob ject system esp ecially in the diverse ways that software engi

neering goals are supp orted For example the division of work b etween

classes and mo dules is discussed in more detail b elow

EuLisps primary goal is to serve as a general programming language

oering the traditional p ower of Lisp while taking the b est concepts from

other languages and striving for the p ossibility of simple ecient imple

mentations EuLisp features the following essential elements

 a mo dule system to supp ort separate compilation and encapsulation

 division into a core language and libraries to facilitate small applica

tion development

 parallel pro cesses based on threads and semaphores for mo dern and

future computer architectures

 a condition system for error handling

 downward continuations for exible control structures

 macros for syntactic extension

 an ob ject system based on classes and generic functions with simple

default b ehavior and a metaob ject proto col

All elements of the language except mo dules bindings and the predened

syntax dening and sp ecial forms are represented by rstclass ob jects

It is imp ossible to create or change a binding by computing its identier

at runtime Although functions can b e generated dynamically at runtime

all co de patterns are known at compiletime All of this helps generate

small ecient applications allowing EuLisp to comp ete favorably with more traditional languages

BRETTHAUER KOPP DAVIS PLAYFORD

Design goals

Certain design goals apply almost to all languages and systems These

include robustness abstraction extensibility ease of use and eciency

Kiczales et al claim to meet a numb er of these imp ortant design

criteria Why is it hard or even imp ossible to meet all of them The cri

teria are in practice contradictory if they must all b e met simultaneously

However we can use the fact that the priority of the goals change dur

ing the course of the software lifecycle to emphasize the most imp ortant

goals at each lifecycle phase thereby reducing design goal conicts For

example abstraction and ease of use apply mainly to the development and

maintenance phases while eciency is essentially a runtime goal

We prop ose the following classication of the ab ove goals

Robustness

The programmer must b e able to dep end on the do cumented function

ality of dened mo dules in other words their semantic integrity must b e

enforced Adapting them should not mean changing them since other mo d

ules used in the same system might stop working as a consequence CLOS

and Common Lisp generally violate this constraint through various redef

inition facilities Instead we should distinguish b etween development time

and execution time During development dynamic redenition is useful

At execution time however the semantics of language entities should b e

xed Since the development environment is not generally considered to

b e appropriate for sp ecication we have little to say ab out the extended

development capabilities oered by implementations However we would

like to assure the programmer that he can write programs whose semantics

is welldened

Abstraction

There should b e dierent levels of granularity in the proto col reect

ing the dierent levels at which users need to think ab out the systems

functionality and extend it Not all extensions are equal Some extensions

require only small mo dications in b ehavior from the default while others

are quite large The amount of work required to implement an extension

should reect its scale Although the user should not have to know imple

mentation details our exp erience shows that revealing appropriate details

at appropriate levels often makes use easier A delicate question is the

lowest level of detail which can b e revealed to allow p ortable and ecient

implementations

BALANCING THE EuLisp METAOBJECT PROTOCOL

Extensibility

The scop e of ob ject mo dels and implementations currently supp orted by

various languages and to ols is quite large ranging from classless prototyp e

based systems like Self to the complex intricate mo dels supp orted by many

exp ert system to ols If our goal is to provide a single medium in which all

of these mo dels can harmoniously coexist sp ecial care must b e taken in

the development of exible general proto cols

This goal also interacts with robustness We consider extension rather

than mo dication to b e the appropriate mo del for implementing new sys

tem b ehavior since it allows b oth the denition of new functionality and

constant semantics for existing functionality

Ease of use

Using and extending the language must b e natural and straightforward

Ease of use should not however b e confused with the laziness of program

mers who write quick hacks with unpredictable consequences The fact

that defgeneric is optional in CLOS is an example for such a doubtful

supp ort in our view

Eciency

MOPbased systems are intended for large and serious software pro jects

the extensive freedom of a MOP cannot and should not b e p erceived

by small applications Using a metaob ject proto col appropriately should

increase the overall eciency of complex systems Eciency has the highest

priority at execution time and programs should follow the principle dont

use dont lose Time and space are b oth imp ortant As the p ower of our

hardware increases so to o do es the ambition of software develop ers We

do not agree with the dictum that eciency will not b e a problem with

next years computers

However since eciency concerns are esp ecially vulnerable to conict

with other goals they must b e emphasized in the appropriate place Here

we make the sweeping generalization that compiletime and loadtime ef

ciency are less imp ortant than runtime eciency In order to achieve

high eciency and extensibility we try to put the highcost op erations

at loadtime Future research will b e directed in putting more eort into

compiletime extensions

All the ab ove goals can b e structured to reect the two sides of a com

puter system A computer language is an intermediary b etween a human

and a machine b oth have dierent needs which the language must try to

balance It must provide b oth

BRETTHAUER KOPP DAVIS PLAYFORD

 Supp ort for go o d software engineering practice this reects the asp ect

human ) language

 Supp ort for ecient programs this reects the other asp ect language

) machine

In the following we show how the TEO MOP tries to achieve b oth of

these goals Note that the balance we describ e is somewhat dierent than

that noted by Kiczales et al where the tension is b etween exibili ty

and eciency Here we broaden exibility to include general software

engineering goals since the metaob ject proto col is a part of a programming

language

Design Approach

By applying the following rules we hop e to achieve the ab ove goals

 Simpler is b etter instead of worse is b etter vs right is b etter

 Orthogonal language constructs are b etter

 Development and execution requirements should b e distinguished

 A mo dules compiletime and runtime dep endencies should b e dis

tinguished

 Eciency costs should b e paid at loadtime rather than runtime

 Language supp ort is needed for a clear separation b etween extension

denition and extension use

 Restrictions due to eciency concerns should b e made explicit in the

language rather than in the do cumentation

These rules inuence software engineering as well as eciency The rst

two rules warrant further explanation they inuence each other and their

violation often arises from a single cause To determine which constructs

should b e provided by a language we must identify the problem solving

metho ds and paradigms used by humans Dierent metho ds should b e

supp orted by orthogonal constructs which can then b e kept simpler

A go o d computer language should have a simple eciency mo del That

is constructs in the language should map simply onto implementations

The TEO slot access proto col is an example of a simple eciency mo del

whereas the CLOS proto col and Common Lisp in general explicitly rely

BALANCING THE EuLisp METAOBJECT PROTOCOL

on clever implementations for achieving eciency Clearly eorts in this

direction must b e continual and we do not claim that TEO is the last

word in this evolution Rather it p oints a direction in which further work

can b e done

TEO could b e viewed as a simplied version of CLOS and the CLOS

MOP However we claim that the result is more p owerful and more ap

propriate for most users based on our exp erience with MCS FEEL and

LeLisp version The pro of of course must still b e provided by the

exp erience of a wider range of users The various public domain and com

mercial versions of TEO are starting to provide that feedback now

Mo dular Decomp osition

Many language designers b elieve classes and mo dules serve similar or iden

tical purp oses However this b elief is not universally shared The

classob ject construct provides data abstraction with sp ecialization and

generalization of structure and b ehavior of ob ject classes in contrast the

mo dule construct deals with scop e and extent of variable bindings and im

p ortexp ort relationships b etween mo dules supp orting information hiding

and encapsulation Classes serve primarily to mo del the problem domain

while mo dules aid problem decomp osition Another way to lo ok at the

distinction is to think of classes as implementation devices and mo dules as

interface devices

Common Lisp do es not provide supp ort for strict imp ort exp ort and

visibility asp ects Its package system considers symb ols as sub jects of ex

change Symb ols however are used for many binding spaces global func

tions variables classes typ es and so on Thus exp orting a symb ol for one

purp ose op ens the do or automatically for all the others

Languages like C or Eiel overload classes by imp ortexp ort and

visibility features That makes their class concept as well as their scop e

rules complex esp ecially when inheritance comes into play

In EuLisp we use the distinction b etween classes and mo dules to provide

a mo dule system orthogonal to the ob ject system thus supp orting b etter

software engineering practice as well as b etter eciency

The example in Figure hints at how the distinction b etween compile

time and runtime dep endencies can b e expressed by the programmer Up to

now the EuLisp committee has only sp ecied the semantics of imp orting

macros as compiletime imp orts However compiletime imp orts can also

b e applied to other metalevel features like metaob ject classes and their

op erations Using this information the compiler could more easily decide

which optimizations to apply

BRETTHAUER KOPP DAVIS PLAYFORD

defmodule nonreflectiveobjectsystem

interface

import primitivelanguageelements

reflectiveobjectkernel

syntax comfortablesyntax

export defstruct

defgeneric defmethod

genericlambda

callnextmethod nextmethodp

make initialize allocate

implementation

defmodule nonreflectiveapplication

interface

import nonreflectiveobjectsystem

syntax comfortablesyntax

nonreflectiveobjectsystemsyntax

export startapplication

implementation

defun startapplication

Figure Two example mo dule denitions

A mo dule can b e compiled separately generating a library or an entire

application can b e completely compiled including all of its imp orted mo d

ules generating a standalone application While many global optimiza

tions are dicult and unsafe in Common Lisp EuLisp provides direct

supp ort for making them straightforward and based on clear semantics

Structuring TELOS Using Mo dules

The dierent parts of the MOP are separated into mo dules to gain clarity

and eciency for applications

We want to have a simple mo dule of ob jectoriented constructs which

can b e analyzed statically allowing signicant optimizations by the com

piler when used in applications In particular all classes generic functions

and metho ds should b e known at compiletime We must keep the mass

of a complex application nonreective in order to achieve the same p er

formance as in nonreective languages Furthermore programs are more

understandable if reective and nonreective parts are clearly separated

BALANCING THE EuLisp METAOBJECT PROTOCOL

In the ab ove example we show through the exp ort list of the mo dule

nonreflectivemodule which language constructs we consider as non

reective These are the dening and anonymous creation forms for classes

generic functions and metho ds as well as the instance creation and initial

ization functions make initialize and allocate

The other mo dules can b e divided in those allowing introsp ection and

those allowing sp ecialization of sp ecial kinds of metaob jects like classes

slot descriptions generic functions and metho ds The introsp ection mo d

ules exp ort the corresp onding classes and slot readers The sp ecialization

mo dules additionally exp ort the op erations sp ecied by the initialization

proto cols Furthermore we provide a mo dule exp orting p ortable low level

allo cation primitives

The Metaob ject Proto col

The following sections summarize the salient p oints of the TEO meta

ob ject proto col as it reects the design philosophy describ ed ab ove We

assume the reader to b e familiar with the CLOS MOP to contrast the

relevant asp ects of the two proto cols

The slot access mo del is describ ed in detail to illustrate the general prin

ciple of moving as much work as p ossible to loadtime The higher order

capabilities of Lisp are exploited by proto cols which compute functions to

b e used at runtime a kind of congurable dynamic compilation pro cess

By closing over all precomputable information we can avoid a great deal

of runtime work

The proto cols controlling instantiation and inheritance are describ ed

only briey highlighting mainly their simpler default b ehavior when com

pared with their analogs in CLOS Note that some dierences b etween the

TEO and CLOS proto cols go unrep orted here since they are b eyond the

immediate scop e of this pap er

Slot Access

The slot access mo del adopted within TEO departs from CLOS Be

fore explaining the new proto col we will rst justify it by identifying the

features of the CLOS approach which put it at o dds with our stated design

philosophy

The CLOS Approach

From our design standp oint the CLOS slot access proto col is not a

reasonable solution Although it provides for straightforward extension of

the default slot access b ehavior the following prop erties present problems

BRETTHAUER KOPP DAVIS PLAYFORD

Inherent ineciency Slot access time is crucial to the p erformance of

ob jectoriented applications Recognizing this a simple eciency

mo del as dened ab ove is desirable

The primary route to the value of a slot of a CLOS ob ject is through

the slotvalue chain This is a dynamic protocol a MOP proto

col that must b e honored at runtime even in principle in a non

3

reective application with all of the attendant runtime overhead

To achieve acceptable p erformance CLOS relies on implementations

to circumvent this route whenever p ossible while still honoring new

metho ds added to the proto col functions Typically accessor func

tions are optimized in some way often via some new proto col for their

computation leading to further problems

Comp eting proto cols Problems of consistency can often arise b etween

computed accessors and the dynamic proto cols due to the instability

of the complex optimizations b eing employed The existence of these

two metho ds of slot access also raises uncertainty as to which is used

by other areas of the MOP such as initialization

So although the CLOS slot access proto col provides a exible means of

extension the cost in terms of the complexity of ecient consistent imple

mentations is to o great The design goals for TEO suggest that it should

b e replaced by a proto col which while retaining exibili ty and simplicity

maps more naturally to reasonable implementations

The TELOS Approach

Rather than have a dynamic slot access proto col TEO provides a

standard proto col for computing readers and writers Every slot description

contains one reader and one writer capable of extracting and up dating the

corresp onding slot within instances Slot options in defclass which dene

accessors merely bind the slots single reader or writer to the appropriate

name Therefore two readers for the same slot b ound to dierent names

will always b e eq

Orthogonality of design is maintained by describing al l slot accesses

as taking place through calls to these accessor functions No analog of

4

slotvalue is provided

3

Every slot access requires at least one standard function call two generic function

calls and a list or table lo okup for the appropriate slot denition ob ject ignoring the

cost of accessing the set of slot denitions from the class ob ject

4 Although it can b e written simply in terms of accessors

BALANCING THE EuLisp METAOBJECT PROTOCOL

The Slot Access Protocol

Accessors are computed and up dated as part of the initialization of a

class A new slot inherited from no sup erclass has a fresh reader and writer

computed for it These functions are then stored in its slot description The

proto col generic functions

COMPUTESLOTREADER class slotd slotds

COMPUTESLOTWRITER class slotd slotds

are used to compute these functions Accessor functions computed in this

way are not guaranteed to work for direct instances of a particular class un

less they have b een ensured for that class Typically computeslotreader

will return a generic function without any metho ds dened on it

Inherited slots either sp ecialized in some way or left unchanged take

the reader and writer from the corresp onding slot description ob jects of

the sup erclasses To combine two or more inherited slot descriptions they

must have a common ro ot and thus share the same accessor functions

Note then that there is a onetoone corresp ondence b etween logical slots

and their accessor pairs

Before inheritance is complete the accessors of the slot descriptions of

the class must all b e ensured The proto col generic functions

ENSURESLOTREADER class slotd slotds reader

ENSURESLOTWRITER class slotd slotds writer

are called to guarantee that the accessors will work on direct instances of the

new class Typically ensureslotreader will add a metho d to reader

capable of reading the appropriate slot of direct instances of class In cases

where the slot has not moved relative to its p osition within instances of

the sup erclasses of class there may b e no need to up date the reader

The computed accessor proto col also gives a p ortable way of dening lower

overhead slot accessors by making readers and writers standard functions

where appropriate

defmethod computeslotreader

c structureclass sd slotdescription slotds

computeprimitivereaderusingclass c sd

defmethod ensureslotreader

c structureclass sd slotdescription slotds reader reader

BRETTHAUER KOPP DAVIS PLAYFORD

Slots of structure classes which always use single inheritance never change

p osition in sub classes and the accessors should not check the typ es of their

arguments The ab ove metho ds implement this functionality for readers

A primitive reader is returned as the slot accessor ensureslotreader

need not do anything since the slot p osition can never change

The standard ensuring metho ds use a subproto col for computing prim

itive accessors standard functions capable of accessing a particular slot

in direct instances of a given class These proto col functions are the direct

analog of the slotvalueusingclass tier in CLOS and are the generic

functions most commonly used to change the b ehavior of slot access

COMPUTEPRIMITIVEREADERUSINGSLOTDESCRIPTION slotd class slotds

COMPUTEPRIMITIVEWRITERUSINGSLOTDESCRIPTION slotd class slotds

COMPUTEPRIMITIVEREADERUSINGCLASS class slotd slotds

COMPUTEPRIMITIVEWRITERUSINGCLASS class slotd slotds

For example computeprimitivereaderusingclass returns a func

tion of one argument that when applied to a direct instance of class

returns the value of the slot describ ed by slotd Its b ehavior on instances

of other classes even sub classes of the sp ecied class is undened

Comparing Use

From the p oint of view of the applications programmer there is little

practical dierence b etween the CLOS and TEO slot access proto cols

The functional equivalence b etween the two can b e illustrated by a simple

example Lets say we want to implement a new slot description which

veries that a slot value when set matches a certain predicate In b oth

CLOS and TEO we can store the predicate in the slot description

ob ject The dierence lies in how to sp ecify the b ehavior of writing to such

a slot

Here is the CLOS metho d

defmethod setf slotvalueusingclass

newvalue class standardclass

object slot predicateslotdefinition

assert funcall slotdefinitionpredicate slot object

callnextmethod

BALANCING THE EuLisp METAOBJECT PROTOCOL

Here is the equivalent TEO metho d

defmethod computeprimitivewriterusingslotdescription

slot predicateslotdescription class class slotds

let prevwriter callnextmethod

predicate slotdescriptionpredicate slot

lambda object newvalue

assert predicate object

prevwriter object newvalue

We can note that the TEO metho d is slightly more complicated but

more ecient since it accesses the predicate just once compared to on ev

ery write as in the CLOS case In this small example the eect of this

is minimal but it can b e quite signicant in others Also note that the

function returned by the TEO metho d is called directly by the writer

generic function

All primary metho ds for slotvalueusingclass could b e translated

mechanically into computeprimitivereaderusingclass metho ds

In cases where it might b e desirable to use a dynamic proto col it is

a simple matter to sp ecialize computeslotreader to return a standard

closure which honors that new proto col Similarly it should b e p ossible to

implement the computed proto col as an extension to CLOS but this would

b e somewhat more involved

Implementation and Eciency

Despite an increase in the numb er of functions over its dynamic counter

part implementation of the computed TEO proto col is no more dicult

a naive implementation need take no more than a few lines of obvious

co de to implement each function in the proto col

The clearest dierence in terms of runtime eciency is that the computed

accessor proto col reduces slot access in standard classes to a single generic

function call in even the simplest implementation This has b een done

without loss of generality or signicant reduction in the ease with which

the b ehavior of the ob ject system may b e extended The uniform use of

accessors also ensures that this p otential improvement is propagated into

other areas such as initialization

In addition one exp ected eect of reducing the relative signicance of slot

access as a p erformance b ottleneck is to allow implementors to concentrate

their optimization eorts on a smaller set of hot sp ots

Metho d Lo okup and Generic Dispatch

TEO uses the generic function mechanism intro duced by CLOS to

BRETTHAUER KOPP DAVIS PLAYFORD

implement p olymorphic b ehavior However the default generic function

mechanism of TEO is simplied compared to CLOS rather than intro

ducing dubious and costly extensions in the kernel we cho ose to relegate

certain functionality to extension mo dules and provide enough extensibil

ity to allow p ortable versions of them to b e written

For example the default generic function dispatch in TEO is purely

class based eql metho ds are not supp orted However eql metho ds like

those found in CLOS can b e p ortably implemented in an extension mo dule

by dening a new generic function class and new metho ds on the metho d

lo okup generic function

Allo cation and Initializa ti on

In the current sp ecication of TEO the instance creation proto col

is very similar to that of CLOS However we intend to apply the load

time priority principle to instance creation as well Classes will then have

asso ciated allo cator and initializer metho ds computed for them at class

creation time Extensions to allo cation or initialization will thus b e done

by extending the allo cator or initializergenerating metho ds rather than

some general allo cating or initializi ng generic function as is done in CLOS

and the current version of TEO

Class Denition and Inheritance

TEO supp orts a standard inheritance proto col as exible as that pro

p osed by Kiczales et al and of a slightly ner granularity splitting the

work into a numb er of explicit phases

The move towards a more loadtime weighted proto col translates into

more work b eing done at class instantiation time This work includes com

puting and ensuring accessors allo cators and initializers as describ ed ab ove

The generation of these functions constitutes a phase in itself

The default inheritance metho ds implement single inheritance The pro

to col however is designed so that general multiple inheritance or mixin in

5

heritance can b e easily and p ortably implemented in extension mo dules

Neither class redenition nor changing the class of an instance is sup

p orted by standard classes It is this in combination with the guarantee

that the b ehavior of standard generic functions cannot b e mo died for

6

standard classes which imbues programs expressed in terms of the default

5

It is likely that all three kinds of inheritance will b e supp orted by standard EuLisp

library mo dules

6

Due to the absence of supp ort for metho d removal and nonstandard metho d

combination

BALANCING THE EuLisp METAOBJECT PROTOCOL

metaob jects with static semantics

Class metho d and generic function redenition as well as class change

may all b e p ortably implemented as library extensions as has b een done in

MCS They are also desirable features of an interactive development envi

ronment We envisage that such development environments may transpar

ently by simple mo dule substitution allow co de to b e develop ed in terms

of a set of metaob jects supp orting these facilities in place of the standard

metaob jects If necessary to gain sp eed or space eciency the program

may b e recompiled in terms of the standard metaob ject set without change

An Example Mixin Inheritance

This section sketches an extension of the TEO MOP which implements

mixin inheritance Since only the slot access proto col has b een describ ed

in detail in this pap er we fo cus on that asp ect here

Informal Sp ecication

The goal of mixin inheritance is to provide a more expressive and exi

ble programming style than single inheritance while avoiding certain prob

lems asso ciated with general multiple inheritance Mixin inheritance dis

tinguishes b etween essential and subsidiary prop erties of ob jects when clas

sifying them in a problem domain We asso ciate base classes with essential

prop erties and mixin classes with subsidiary prop erties From the mo d

eling p oint of view essential prop erties are substantive such as buers

and windows Subsidiary prop erties are descriptive such as printable

b ordered and titled

Mixin inheritance claries class hierarchies and improves application ef

ciency by ob eying the following restrictions

 A base class can directly sp ecialize many mixin classes but only one

base class A sup erbaseclass is considered more general than the

sup ermixinclasses

 A mixin class can sp ecialize many mixin classes but no base classes

 There are no join no des in the inheritance hierarchy except the ro ot

class object

 Base classes may have direct instances while mixin classes may not

b e instantiated

BRETTHAUER KOPP DAVIS PLAYFORD

Implementation Outline

First we have to dene the two new metaclasses baseclass and

mixinclass These metaclasses are the classes of the new kinds of

classes we describ ed ab ove

defclass baseclass

defclass mixinclass

The exact sup erclasses are not sp ecied here but they must b e meta

classes and thus sub classes of class

In this pap er we concentrate on the slot reader generating proto col How

ever the other generic functions in the inheritance proto col which need to

b e dened for the new metaclasses should b e mentioned to o These generic

functions include

compatiblesuperclassesp

compatiblesuperclassp

computeclassprecedencelist

computeinheritedslotdescriptions

computeslotdescriptions and

computespecializedslotdescription

The metho ds checking the compatibility of sup erclass and sup erclasses

control the rst and second restriction in the list given earlier The metho d

on computeclassprecedencelist linearizes the class hierarchy for base

and mixin classes depth rst left to right It signals an error if a join no de

dierent from the ro ot class object o ccurs The metho d computing

inherited slot descriptions returns a list containing the eective slot de

scription lists of all direct sup erclasses The new metho ds for computing

slot and sp ecialized slot descriptions have to deal with the case of multiple

inherited slot descriptions with the same name Often we can reuse the

system dened metho d via callnextmethod and extend it as needed

Now we consider the slot accessor computation Slots of base classes

never change p osition in sub classes Slots of mixin classes however can

change p osition in sub classes Thus a generic function can b e returned

as the reader for slots dened by mixin classes while a simple function is

returned as the reader for slots dened by base classes

defmethod computeslotreader

c baseclass sd slotdescription

computeprimitivereaderusingclass c sd

BALANCING THE EuLisp METAOBJECT PROTOCOL

defmethod computeslotreader

c mixinclass sd slotdescription

genericlambda o c

The ensureslotreader metho d do es not need to do anything for

mixin classes since they have no direct instances and may rely on the

assumption that the right thing will b e done when a slot dened for a

mixin class is inherited by a base class A metho d applicable for the direct

instances of the base class will b e added to the generic reader

defmethod ensureslotreader

c mixinclass sd slotdescription reader

reader

defmethod ensureslotreader

c baseclass sd slotdescription reader

if genericfunctionp reader mixin slot reader

let r computeprimitivereaderusingclass c sd

addmethod reader methodlambda o c r o

reader

The slot writers are treated in an analogous way

Conclusion

We have discussed the design goals and approach of the TEO metaob ject

proto col They provide a b etter balance b etween supp ort for go o d software

engineering practice and supp ort for ecient programs than the CLOS

MOP

We gave an overall description of TEO including a metaob ject proto col

which provides the op enness needed for extensions and achieves eciency

by more static semantics for predened metaob jects mo dularizing their

op erations Simplicity and orthogonality supp ort b oth go o d software en

gineering practice as well as ecient programs The metaob ject system is

structured into mo dules taking into account the consequences for the com

piler It provides introsp ection op erations as well as extension interfaces

for new inheritance strategies new instance allo cation metho ds new slot

descriptions new slot access primitives new discrimination metho ds class

redenition and so on

With some minor variations the ma jor parts of the describ ed proto col

have b een implemented in Scheme Common Lisp LeLisp version

BRETTHAUER KOPP DAVIS PLAYFORD

and FEEL While the general goals and functionality are almost the same

as describ ed by Kiczales et al the approach shows dierent emphases

As a result eciency as well as robustness have b oth b een improved

Acknowledgments

First we want to thank Greg Nuyens and Julian Padget the main editors

of EuLisp as well as all memb ers of the EuLisp working group for the

very fruitful discussions during meetings and on the net

We thank Wolfgang Go erigk and Ingo Mohr for their suggestions from

the APPLY compiler builders p oint of view

We thank the CLOS designers for providing an excellent and useful

framework in which to study these issues and for altruistically not doing

everything right the rst time

We thank Gregor Kiczales Jim des Rivieres and Daniel G Bobrow for

their excellent b o ok The Art of the Metaob ject Proto col and for making

parts of the sources available to a wide community by ftp

References

LeLisp version Reference Manual ILOG SA Gentilly

Bradford R Telos in Common Lisp Submitted for publication

Bretthauer H and Kopp J The MetaClassSystem MCS A Portable

Ob ject System for Common Lisp Do cumentation Arb eitspapiere der

GMD GMD Sankt Augustin July

Bretthauer H Christaller Th and Kopp J Multiple vs Single In

heritance in Ob jectoriented Programming Languages Micropro cess

ing and Microprogramming

Bretthauer Harry Davis Harley Kopp Jurgen and Playford Keith

Balancing the eulisp metaob ject proto col In Yonezawa Akinori and

Smith Brian C editors IMSA Workshop on Reection and Meta

Level Architecture Tokio

Christaller Th Eine Einfuhrung in LISP In Christaller Th Hein H

W and Richter M M editors Kunstlic he Intelligenz Theoretische

Grundlagen und Anwendungsfelder SpringerVerlag Berlin

Christaller Th di Primio F Schnepf U and Vo A editors The

AIWorkb ench BABYLON Academic Press London

BALANCING THE EuLisp METAOBJECT PROTOCOL

Cointe P The Ob jVlisp Kernel a Reective Lisp Architecture to de

ne a Uniform Ob jectOriented System In Maes Pattie and Nardi

Daniele editors MetaLevel Architectures and Reection North Hol

land

di Primio F Micro Common Flavors Arb eitspapiere der GMD

GMD Sankt Augustin February

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

ject Proto col MIT Press Cambridge Massachusetts

Meyer B Eiel The Language Prentice Hall Ob jectOriented Series

Prentice Hall New York

Padget J and Nuyens G editors The EuLisp Denition Version

In preparation

Steele Jr Guy L Common Lisp The Language Second Edition

Digital Press Bedford Massachusetts

Szyp erski C A Imp ort is Not Inheritance Why We Need Both

Mo dules and Classes In Madsen O Lehrmann editor Pro c of the

ECOOP SpringerVerlag July