Balancing the EuLisp Metaob ject Proto col

x y x z

Harry Bretthauer and Harley Davis and Jurgen Kopp and Keith Playford

x

German National Research Center for Computer Science GMD

PO Box W Sankt Augustin FRG

y

ILOG SA avenue Gallieni Gentilly France

z

Department of Mathematical Sciences University of Bath Bath BA AY UK

techniques which can b e used to solve them Op en questions Abstract

and unsolved problems are presented to direct future work

The challenge for the metaob ject proto col designer is to bal

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

ance the conicting demands of eciency simplicity and

b etween expressiveness and ease of use on the one hand

extensibili ty It is imp ossible to know all desired extensions

and eciency on the other

in advance some of them will require greater functionality

Since the authors of this pap er and other memb ers

while others require greater eciency In addition the pro

of the EuLisp committee have b een engaged in the design

to col itself must b e suciently simple that it can b e fully

and implementation of an ob ject system with a metaob ject

do cumented and understo o d by those who need to use it

proto col for EuLisp Padget and Nuyens intended

This pap er presents a metaob ject proto col for EuLisp

to correct some of the p erceived aws in CLOS to sim

which provides expressiveness by a multileveled proto col

plify it without losing any of its p ower and to provide the

and achieves eciency by static semantics for predened

means to more easily implement it eciently The current

metaob jects and mo dularizin g their op erations The EuLisp

status of this work is reected in the EuLisp denition

mo dule system supp orts global optimizations of metaob ject

The ob ject system TEO has b een implemented with

application s The metaob ject system itself is structured into

minor variations in the public domain EuLisp implementa

mo dules taking into account the consequences for the com

tion FEEL in the commercially available dialect LeLisp

piler It provides introsp ective op erations as well as exten

version LeLisp in Common Lisp as the public

sion interfaces for various functionaliti es including new in

domain system MCS and in Scheme TEO is used as the

heritance allo cation and slot access semantics

base for a complex exp ert system workb ench called babylon

While general goals and functionality are close to those

Christaller et al as well as a set of articial intelli

in Kiczales et al the approach shows dierent em

gence and graphic programming to ols available from ILOG

phases As a result time and space eciency as well as

SA Most of these to ols extend the kernel ob ject language

robustness have b een improved

provided by TEO using the metaob ject proto col

This work builds not only on CLOS but also on a se

ries of Europ ean work on simple reective ob jectoriented

Intro duction

architectures in Lisp including work on ObjVLisp Cointe

the Micro Flavor System Christaller Micro

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

Common Flavors di Primio and the Meta Class Sys

scrib ed in The Art of the Metaob ject Proto col by Gregor

tem MCS Bretthauer and Kopp

Kiczales Jim des Rivieres and Daniel G Bobrow Kiczales

et al Indeed it is still an art rather than a science

to dene elegant and useful ob jectoriented programs and

Design Context

the problem is comp ounded for a program as general as a

TEO is an integrated part of the EuLisp language def

language Kiczales et al present an elab orate and tested

inition In describing it we cannot completely isolate the

metaob ject proto col MOP for the Common Lisp Ob ject

ob ject system from the rest of the language There is a

System CLOS Steele Jr Furthermore they intro

strong synergy b etween the rest of the language and the

duce the essential problems to the reader and show various

ob ject system esp ecially in the diverse ways that software



The work of this pap er was supp orted by the joint pro ject AP

engineering goals are supp orted For example the division

PLY ILOG SA the University of Bath the ARC program and the

of work b etween classes and mo dules is discussed in more

EuLisp working group

detail b elow

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

EuLisps primary goal is to serve as a general program

for Research and Technology BMFT The partners in this pro ject

are the University of Kiel the Fraunhofer Institute for Software En

ming language oering the traditional p ower of Lisp while

gineering and Systems Engineering ISST the German National Re

taking the b est concepts from other languages and striving

search Center for Computer Science GMD and VWGedas

for the p ossibili ty of simple ecient implementation s Eu

Lisp features the following essential elements

 a mo dule system to supp ort separate compilation and encapsulatio n

 division into a core language and libraries to facilitate the scale of the mo dication Although the user should not

small application development have to know implementation details our exp erience shows

that revealing appropriate details at appropriate levels often

 parallel pro cesses based on threads and semaphores for

makes use easier A delicate question is the lowest level of

mo dern and future computer architectures

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

implementations

 a condition system for error handling

 downward continuations for exible control structures

Extensibility The range of ob ject mo dels and implemen

tations currently supp orted by various languages and to ols

 macros for syntactic extension

is quite large ranging from classless prototyp ebased sys

tems like Self to the complex intricate mo dels supp orted by

 an ob ject system based on classes and generic func

many exp ert system to ols If our goal is to provide a sin

tions with simple default b ehavior and a metaob ject

gle medium in which all of these mo dels can harmoniously

proto col

coexist sp ecial care must b e taken in the development of

exible general proto cols

All elements of the language except mo dules bindings and

This goal also interacts with robustness We consider exten

the predened syntax dening and sp ecial forms are rep

sion rather than mo dication to b e the appropriate mo del

resented by rstclass ob jects It is imp ossible to create or

for implementing new system b ehavior since it allows b oth

change a binding by computing its identier at runtime Al

the denition of new functionality and constant semantics

though functions can b e generated dynamically at runtime

for existing functionality

all co de patterns are known at compiletime All of this

helps generate small ecient applicatio ns allowing EuLisp

to comp ete favorably with more traditional languages Ease of use Using and extending the language must b e

natural and straightforward Ease of use should not how

ever b e confused with laziness of programmers supp orting

Design goals

quick hacks with unpredictable consequences The fact that

Certain design goals apply almost to all languages and sys

defgeneric is optional in CLOS is an example for such a

tems including robustness abstraction extensibili ty ease

doubtful supp ort in our view

of use and eciency

Kiczales et al claim to meet a numb er of these

Eciency MOPbased systems are intended for large and

imp ortant design criteria Why is it hard or even imp ossible

serious software pro jects the extensive freedom of a MOP

to meet all of them The criteria are in practice contra

cannot and should not b e p erceived by small application s

dictory if they must all b e met simultaneousl y However we

Using a metaob ject proto col appropriately should increase

can use the fact that the priority of the goals change during

the overall eciency of complex systems Eciency has the

the course of the software lifecycle to emphasize the most

highest priority at execution time and programs should fol

imp ortant goals at each lifecycle phase thereby reducing de

low the principle dont use dont lose Time and space

sign goal conicts For example abstraction and ease of use

are b oth imp ortant as the p ower of our hardware increases

apply mainly to the development and maintenance phases

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

while eciency is essentially a runtime goal

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

We prop ose the following classication of the ab ove goals

with next years computers

However since eciency concerns are esp ecially vulnerable

Robustness The programmer must b e able to dep end on

to conict with other goals they must b e emphasized in

the do cumented functionality of dened mo dules in other

the appropriate place Here we make the sweeping gener

words their semantic integrity must b e enforced Adapting

alization that compiletime and loadtime eciency are less

them should not mean changing them since other mo dules

imp ortant than runtime eciency In order to achieve high

used in the same system might stop working as a conse

eciency and extensibil ity we try to put the highcost op

quence CLOS and Common Lisp generally violate this

erations at loadtime Future research will b e directed in

constraint through its various redenition facilities Instead

putting more eort into compiletime extensions

we should distinguish b etween development time and execu

All the ab ove goals can b e structured reecting the two

tion time during development dynamic redenition is use

sides of a computer system A computer language is an

ful At execution time however the semantics of language

intermediary b etween a human and a machine b oth have

entities should b e xed Since the development environment

dierent needs which the language must try to balance It

is not generally considered to b e appropriate for sp ecica

must provide b oth

tion we have little to say ab out the extended development

capabiliti es oered by implementation s However we would

 Supp ort for go o d software engineering practice this

like to assure the programmer that he can write programs

reects the asp ect human ) language

whose semantics is welldened

 Supp ort for ecient programs this reects the other

Abstraction There should b e dierent levels of granular

asp ect language ) machine

ity in the proto col reecting the dierent levels at which

users need to think ab out the systems functionali ty and ex

In the following we show how the TEO MOP tries to

tend it An imp ortant p oint is that not all extensions are

achieve b oth of these goals Note that the balance we de

equal Some extensions are only small mo dications in b e

scrib e is somewhat dierent than the balance mentioned in

havior from the default while others are quite large The

Kiczales et al where the tension is b etween exi

amount of work required to implement them should reect

bility and eciency Here we broaden exibility to include

general software engineering goals since the metaob ject pro Another way to lo ok at the distinction is to think of classes

to col is a part of a programming language as implementation devices and mo dules as interface devices

Common Lisp do es not care much ab out strict imp ort

exp ort and visibil ity asp ects Its package system considers

Design Approach

symb ols as sub jects of exchange Symb ols however are used

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

for many binding spaces global functions variables classes

goals

typ es etc Thus exp orting a symb ol for one purp ose op ens

the do or automatically for all the others

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

Languages like C or Eiel overload the classes by im

is b etter

p ortexp ort and visibili ty features That makes their class

concept as well as the general scop e rules to complex esp e

 Orthogonal language constructs are b etter

cially when inheritance comes into play

In EuLisp we use the ab ove distinction to provide a

 Distinguish b etween development and execution user

mo dule system orthogonal to the ob ject system supp orting

requirements

b etter software engineering practice as well as b etter e

 Distinguish b etween compiletime and runtime dep en

ciency

dencies b etween mo dules

Here is a simple example of a mo dule denition

 Try to pay eciency costs at loadtime rather than

defmodule nonreflectiveobjectsystem

runtime

interface

 Provide language supp ort for a clear separation b e

primitivelanguageelements runtime imports

reflectiveobjectkernel

tween extension denition and extension use

comfortablesyntax compiletime imports

 Make restrictions due to eciency concerns explicit in

export defclass defgeneric defmethod

genericlambda genericlabels

the language rather than in the do cumentation

callnextmethod

make initialize

The ab ove rules inuence b oth software engineering as well

implementation

as eciency The rst two rules warrant further explanation

they inuence each other and their violation often arises

from a single cause In order to nd out which constructs

defmodule nonreflectiveapplication

should b e provided by a language we must identify the prob

interface

lem solving metho ds and paradigms used by humans Dier

nonreflectiveobjectsystem runtime imports

ent metho ds should b e supp orted by orthogonal constructs

comfortablesyntax compiletime imp

which can then b e kept simpler

nonreflectiveobjectsystem

export startapplication

A go o d computer language should have a simple e

implementation

ciency mo del That is constructs in the language should

defun startapplication

map simply onto implementation s The TEO slot access

proto col is an example of a simple eciency mo del whereas

The example shows how the distinction b etween compile

the CLOS proto col and Common Lisp in general explic

time and runtime dep endencies can b e expressed by the

itly rely on clever implementations for achieving eciency

programmer Up to now the EuLisp committee has only

Clearly eorts in this direction must b e continual and we

sp ecied the semantics of imp orting macros as compiletime

do not claim that TEO is the last word in this evolution

imp orts However compiletime imp orts can also b e applied

Rather it p oints a direction in which further work can b e

to other metalevel features like metaob ject classes and their

done

op erations Using this information the compiler could more

TEO could b e viewed as a simplied version of CLOS

easily decide which optimizations to apply

and the CLOS MOP However we claim that the result

A mo dule can b e compiled separately generating a li

is not less p owerful nor is it less adequate for most users

brary or an entire application can b e completely compiled

indeed we claim the opp osite based on our exp erience with

including all its imp orted mo dules generating a standalone

MCS FEEL and LeLisp version The pro of of course

application While many global optimizations are dicult

must still b e provided by the exp erience of a wider range of

and unsafe in Common Lisp EuLisp provides direct sup

users The various public domain and commercial versions

p ort for making them straightforward and based on clear

of TEO are starting to provide that feedback now

semantics

Mo dular Decomp osition

Structuring TELOS Using Mo dules

Many language designers b elieve classesob jects and mo d

The dierent parts of the MOP are separated into mo dules

ules serve similar or identical purp oses Meyer How

to gain clarity and eciency for applicati ons

ever this b elief is not universally shared Szyp erski

We want to have a simple mo dule of ob jectoriented con

The classob ject construct provides data abstraction with

structs which can b e analyzed statically allowing signicant

sp ecializati on and generalizatio n of structure and b ehav

optimizations by the compiler when used in applicatio ns In

ior of ob ject classes while the mo dule construct deals with

particular all classes generic functions and metho ds should

scop e and extent of variable bindings and imp ortexp ort

b e known at compiletime We must keep the mass of a

relationship s b etween mo dules supp orting information hid

complex application nonreective in order to achieve the

ing and encapsulation Classes serve primarily to mo del the problem domain while mo dules aid problem decomp osition

same p erformance as in nonreective languages Further To achieve acceptable p erformance CLOS relies on

more programs are more understandable if reective and implementation s to circumvent this route whenever

nonreective parts are clearly separated p ossible while still honoring new metho ds added to

In the ab ove example we show through the exp ort list of the proto col functions Typically accessor functions

the mo dule nonreflectivemodule which language con are optimized in some way often via some new proto

structs we consider as nonreective These are the dening col for their computation leading to further problems

and anonymous creation forms for classes generic functions

Comp eting proto cols Consistency problems can often arise

and metho ds as well as the instance creation and initializa

b etween computed accessors and the dynamic proto

tion functions make and initialize

cols due to the instabili ty of the complex optimizations

The other mo dules can b e divided in those allowing intro

b eing employed The existence of these two metho ds

sp ection and those allowing sp ecializatio n of sp ecial kinds of

of slot access also raises uncertainty as to which is used

metaob jects like classes slot descriptions generic functions

by other areas of the MOP such as initiali zati on

and metho ds Furthermore there exists a mo dule exp orting

p ortable low level allo cation primitives

So although the CLOS slot access proto col provides a ex

ible means of extension the cost in terms of the complexity

The Metaobject Proto col

of ecient consistent implementations is to o great The

design goals for TEO suggest that it should b e replaced

The following sections summarize the salient p oints of the

by a proto col which while retaining exibili ty and simplic

TEO metaob ject proto col as it reects the design philos

ity maps more naturally to reasonable implementations

ophy describ ed ab ove We assume the reader to b e familiar

with the CLOS MOP and contrast the relevant asp ects of

The TELOS Approach

the two proto cols

The slot access mo del is describ ed in most detail serving

Rather than have a dynamic slot access proto col TEO

to illustrate the general principle of moving as much work as

provides a standard proto col for computing readers and writ

p ossible to loadtime The higher order capabili ties of Lisp

ers Every slot description contains one reader and one

are exploited by proto cols which compute functions to b e

writer capable of extracting and up dating the corresp onding

used at runtime a kind of congurable dynamic compila

slot within instances Accessor dening slot options within

tion pro cess By closing over all precomputable information

a defclass merely bind the slots single reader or writer to

we can avoid a great deal of runtime work

the appropriate name therefore two readers for the same

The proto cols controlling instantiation and inheritance

slot b ound to dierent names will always b e eq

are describ ed only briey in overview highlightin g mainly

Orthogonality of design is maintained by describing al l

their simpler default b ehavior when compared with their

slot accesses as taking place through calls to these accessor

2

analogs in CLOS Note that some dierences b etween the

functions No analog of SLOTVALUE is provided

TEO and CLOS proto cols go unrep orted here since they

are b eyond the immediate scop e of this pap er

The Slot Access Proto col

Accessors are computed and up dated as part of the initial

Slot Access

ization of a class A new slot ie inherited from no sup er

class has a fresh reader and writer computed for it which

The slot access mo del adopted within TEO is something

are then stored in its slot description The proto col generic

of a departure from that of CLOS Before explaini ng the

functions

new proto col we will rst justify this rethink by identifying

the features of the CLOS approach which make it at o dds

COMPUTESLOTREADER class slotd slotds

with our stated design philosophy

COMPUTESLOTWRITER class slotd slotds

are used to compute these functions Accessor functions

The CLOS Approach

computed in this way are not guaranteed to work for direct

From our design standp oint the proto col that CLOS de

instances of a particular class unless they have b een ensured

nes in this area do es not represent a reasonable solution

for that class Typically COMPUTESLOTREADER will return

Although it provides well for straightforward extension of

a generic function without any metho ds dened on it

default slot access b ehavior its following prop erties present

Inherited slots either sp ecialized in some way or left un

problems

changed take the reader and writer from the corresp onding

slot description ob jects of the sup erclasses For two or more

Inherent ineciency Slot access time is crucial to the

inherited slot descriptions to b e validly combined they must

p erformance of ob jectoriented application s Recog

have a common ro ot and thus share the same accessor func

nizing this a simple eciency mo del as dened ab ove

tions Note then that there is a onetoone corresp ondence

is desirable for this asp ect of the MOP

b etween logical slots and their accessor pairs

The primary route to the value of a slot of a CLOS

Before inheritance is complete the accessors of the slot

ob ject is through the SLOTVALUE chain This is a dy descriptions of the class must all b e ensured The proto col

generic functions

namic protocol a MOP proto col that must b e honored

at runtime even in principle in a nonreective ap

ENSURESLOTREADER class slotd slotds reader

plication with all of the considerable runtime over

ENSURESLOTWRITER class slotd slotds writer

1

head this entails

denitions from the class ob ject

1

2

Every slot access requires at least one standard function call two

Although such can b e written simply in terms of accessors

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

In cases where it might b e desirable to use a dynamic pro are called to guarantee that the accessors will work on direct

to col it is a simple matter to sp ecialize COMPUTESLOTREAD instances of the new class Typically ENSURESLOTREADER

ER to return a standard closure which honors that new pro will add a metho d to reader capable of reading the appro

to col Similarly it should b e p ossible to implement the com priate slot of direct instances of class In cases where the

puted proto col as an extension to CLOS but this would b e slot has not moved relative to its p osition within instances

somewhat more involved of the sup erclasses of class there may b e no need to up date

the reader

The ensuring functions use a subproto col for computing

Implementation and Eciency

primitive accessors standard functions capable of accessing

a particular slot in direct instances of a given class These

Despite an increase in the numb er of functions over its dy

proto col functions are the direct analog of the SLOTVAL

namic counterpart implementation of the computed proto

UEUSINGCLASS tier in CLOS and are the generic functions

col is no more dicult a naive implementation need take

most commonly used to change the b ehavior of slot access

no more than a few lines of obvious co de to implement each

of them

COMPUTEPRIMITIVEREADERUSINGSLOTDESCRIPTION

It should also b e noted that using generic accessors to

slotd class slotds

COMPUTEPRIMITIVEWRITERUSINGSLOTDESCRIPTION

access the slots of standard metaob jects in a fully general

slotd class slotds

reective implementation shifts the p otential innite regres

COMPUTEPRIMITIVEREADERUSINGCLASS class slotd slotds

sion in slot access away from the SLOTVALUE chain and into

COMPUTEPRIMITIVEWRITERUSINGCLASS class slotd slotds

generic function dispatch It is the generic functions and

accessors called during metho d lo okup that must b e sp e

For example COMPUTEPRIMITIVEREADERUSINGCLASS re

cially treated for the standard metaob jects to ground the

turns a function of one argument that when applied to a

recursion

direct instance of class returns the value of the slot de

The clearest dierence in terms of runtime eciency is

scrib ed by slotd Its b ehavior on instances of other classes

that the computed accessor proto col reduces slot access in

even sub classes of the sp ecied class is undened

standard classes to a single generic function call in even the

simplest implementation This has b een done without any

Comparing Use

loss of generality or signicant reduction in the ease with

which the b ehavior of the ob ject system may b e extended

From the p oint of view of the application s programmer

The uniform use of accessors also ensures that this p otential

there is little to cho ose b etween working with the CLOS

improvement is propagated into other areas such as initial

and TEO slot access proto cols The dierence b etween

ization

the two can b e illustrated by a simple example Lets say

In addition one exp ected kno ckon eect of reducing the

we want to implement a new slot description which veries

relative signicance of slot access as a p erformance b ottle

that a slot value when set matches a certain predicate In

neck is to allow implementors to concentrate their optimiza

b oth CLOS and TEO we can store the predicate in the

tion eorts on a smaller set of hot sp ots

slot description ob ject The dierence lies in how to sp ecify

the b ehavior of writing to such a slot

Metho d Lo okup and Generic Dispatch

Here is the CLOS metho d

TEO uses the generic function mechanism intro duced by

defmethod setf slotvalueusingclass

CLOS to implement p olymorphic b ehavior However the

newvalue class standardclass

default generic function mechanism of TEO is simplied

object slot predicateslot

compared to CLOS rather than intro ducing dubious and

assert funcall predicateslotpredicate slot object

costly extensions in the kernel we cho ose to relegate certain

callnextmethod

functionality to extension mo dules and provide enough ex

tensibili ty to allow p ortable versions of them to b e written

Here is the equivalent TEO metho d

For example the default generic function dispatch in

TEO is purely class based eql metho ds are excluded

defmethod computeprimitivewriterusingslotdescription

However eql metho ds like those found in CLOS can b e

slot predicateslot class class slotds

let prevwriter callnextmethod

p ortably implemented in an extension mo dule by dening a

predicate predicateslotpredicate slot

new generic function class and new metho ds on the metho d

lambda object newvalue

lo okup generic function Additionall y the argument prece

assert predicate object

dence order is by default always left to right

prevwriter object newvalue

Allo cation and Initialization

We can note that the TEO metho d is slightly more com

plicated but more ecient since it accesses the predicate

In the current sp ecication of TEO the instance creation

just once compared to on every write as in the CLOS case

proto col is very similar to that of CLOS However we intend

In this small example the eect of this is minimal but it

to apply the loadtime priority principle to instance creation

can b e quite signicant in others Also note that the func

as well Classes will then have asso ciated allo cator and ini

tion returned by the TEO metho d is called directly by

tializer metho ds computed for them at class creation time

the writer generic function

Extensions to allo cation or initiali zati on will thus b e done

All primary metho ds for SLOTVALUEUSINGCLASS could

by extending the allo cator or initialize rgenerati ng metho ds

b e translated trivially indeed mechanically into correct COM

rather than some general allo cating or initial izi ng generic

PUTEPRIMITIVEREADERUSINGCLASS metho ds

function as is done in CLOS and the current version of

TEO

Class Denition and Inheritance Acknowledgments

TEO supp orts a standard inheritance proto col as exible

First we want to thank Greg Nuyens and Julian Padget the

as that prop osed in Kiczales et al and of a slightly

main editors of EuLisp as well as all memb ers of the Eu

ner granularity splitting the work into a numb er of explicit

Lisp working group for the very fruitful discussions during

phases

meetings and on the net

The move towards a more loadtime weighted proto col

We thank the CLOS designers for providing an excellent

translates into more work b eing done at class instantiation

and useful framework in which to study these issues and for

time includin g the computation and up date of accessors al

altruistical ly not doing everything right the rst time

lo cators and initiali zers as describ ed ab ove The generation

We thank Gregor Kiczales Jim des Rivieres and Daniel

of these functions constitutes a phase in itself

G Bobrow for their excellent b o ok The Art of the Metaob

The default inheritance metho ds implement just single

ject Proto col and for making parts of the sources available

inheritance The proto col however is designed so that gen

to a wide community by ftp

eral multiple inheritance or mixin inheritance Bretthauer et

al can b e easily and p ortably implemented in exten

3 References

sion mo dules

Neither class redenition nor changing the class of an

Bretthauer and Kopp H Bretthauer and J Kopp

instance is supp orted by standard classes It is this in com

The MetaClassSystem MCS A Portable Ob ject System

bination with the guarantee that the b ehavior of standard

for Common Lisp Do cumentation Arb eitspapiere der

generic functions cannot b e mo died for standard classes

GMD GMD Sankt Augustin July

due to no supp ort for metho d removal nor nonstandard

metho d combination which imbues programs expressed in

Bretthauer et al H Bretthauer T Christaller and

terms of the default metaob jects with static semantics

J Kopp Multiple vs Single Inheritance in Ob ject

Class metho d and generic function redenition together

oriented Programming Languages Microprocessing and

with class change may all b e p ortably implemented as li

Microprogramming

brary extensions as has b een done in MCS They are also de

Christaller et al T Christaller F di Primio

sirable features of an interactive development environment

U Schnepf and A Vo editors The AIWorkbench

It is envisaged that such development environments may

BABYLON Academic Press London

transparently by simple mo dule substitution allow co de to

b e develop ed in terms of a set of metaob jects supp orting

Christaller T Christaller Eine Einfuhrung in LISP

these facilities in place of the standard metaob jects If nec

In T Christaller HW Hein and M M Richter editors

essary to gain sp eed or space eciency the program may b e

Kunstliche Intel ligenz Theoretische Grund lagen und An

recompiled in terms of the standard metaob ject set without

wendungsfelder volume of InformatikFachberichte

change

pages SpringerVerlag Berlin

Cointe P Cointe The Ob jVlisp Kernel a Reective

Conclusion

Lisp Architecture to dene a Uniform Ob jectOriented

System In P Maes and D Nardi editors MetaLevel

We have discussed the goals and the approach of the design

Architectures and Reection pages North Hol

of the TEO metaob ject proto col They provide a b et

land

ter balance b etween supp ort for go o d software engineering

practice and supp ort for ecient programs than the CLOS

di Primio F di Primio Micro Common Flavors Ar

MOP

b eitspapiere der GMD GMD Sankt Augustin Febru

We gave an overall description of TEO including a

ary

metaob ject proto col which provides the op enness needed for

Kiczales et al G Kiczales J des Rivieres and

extensions and achieves eciency by more static semantics

D Bobrow The Art of the Metaobject Protocol MIT

for predened metaob jects mo dularizin g their op erations

Press Cambridge Massachusetts

Simplici ty and orthogonality supp ort b oth go o d software en

gineering practice as well as ecient programs The metaob

LeLisp ILOG SA Gentilly LeLisp version Ref

ject system is structured into mo dules taking into account

erence Manual

the consequences for the compiler It provides introsp ection

Meyer B Meyer Eiel The Language Prentice

op erations as well as extension interfaces for new inheri

Hall Ob jectOriented Series Prentice Hall New York

tance strategies new instance allo cation metho ds new slot

descriptions new slot access primitives new discriminati on

metho ds class redenition and so on

Padget and Nuyens J Padget and G Nuyens edi

With some minor variations the ma jor parts of the de

tors The EuLisp Denition Version April

scrib ed proto col have b een implemented in Scheme Com

University of Bath unpublished

mon Lisp LeLisp version and FEEL While the gen

Steele Jr G L Steele Jr Common Lisp The

eral goals and functionality are almost the same as in Kicza

Language Second Edition Digital Press Bedford Mas

les et al the approach shows dierent emphases As

sachusetts

a result eciency as well as robustness have b oth b een im

proved

Szyp erski C A Szyp erski Imp ort is Not Inheri

3

tance Why We Need Both Mo dules and Classes In

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

by standard EuLisp library mo dules O L Madsen editor Proc of the ECOOP LNCS

pages SpringerVerlag July