Ob jectOriented Programming in Scheme

with FirstClass Mo dules and Op eratorBased Inheritance

Guruduth Banavar

Gary Lindstrom

Department of Computer Science

University of Utah Salt LakeCityUT

Abstract

Wecharacterize ob jectoriented programming as structuring and manipulating a uniform

space of rstclass values representing modules a distillation of the notion of classes Op erators

over mo dules individually achieve eects such as encapsulation sharing and static binding A

variety of idioms of OO programming nd convenient expression within this mo del including

several forms of single and multiple inheritance abstract classes class variables inheritance

hierarchy combination and reection Weshow that this programming style simplies OO

programming via enhanced uniformity and supp orts a exible mo del of ob jectorientation that

provides an attractive alternative to metaprogramming Finallyweshow that these notions of

OO programming are language indep endent by implementing a Mo dular Scheme prototyp e as

a completion of a generic OO framework for mo dularity

Pap er Category Research Topic Area Language design and implementation

Intro duction

Classbased ob jectoriented programming is usually thought of as creating a graph structured inher

itance hierarchy of classes instantiating some of these classes and computing with these instances

Instances are typically rstclass values in the language ie they can b e created stored accessed

and passed into and out of functions Classes on the other hand are usually not rstclass values

and inheritance is often considered an op erational and static structuring activity

Some dynamic languages like CLOS and Smalltalk p ermit access to classes at runtime

usually as ob jects of other metaclasses However even in dynamic OO languages there is often

a disparitybetween the manner in which classes and other values are manipulated Classes are

often not on an equal fo oting with other values for example classes are not passed into and out

of functions or stored and retrieved as attributes of other classes When a more equitable status

for classes is desired metaprogramming is resorted to A metalevel architecture assumes the role

of capturing and exp osing the prop erties of classes ob jects and their interactions via a collection

Primary contact author Email banavarcsutahedu Phone fax

of collab orating metaclasses Programmability of these metaclasses is a p owerful means by which

languages achieve exibility

In this pap er we present an alternative mo del of OO programming that we assert to b e

powerful exible and uniform all without recourse to metaprogramming In this mo del classes

are regarded as values just likeeverything else in the language Classes can b e created stored in

variables passed into and out of functions nested arbitrarily and inherited by other classes through

expressions over classes Classes are instantiated and computation p erformed with these instances

by accessing their data attributes and calling their function attributes Encapsulation sharing

and static binding are achieved via individual op erators over classes This p oint of view gives rise

to an expressive programming style that mo dels most existing idioms of OO programming while

providing the exibili ty to express many others

We illustrate this programming style with the programming language Scheme extended

with an abstraction mechanism called modules Hence we call our language Modular SchemeWe

b elieve that the presentday notion of ob jectorientation is really the most advanced stage of an

evolution towards mo dularity in programming languages Mo dularity aims to achieve imp ortant

requirements of largescale software development such as encapsulation separate developmentand

ease of maintenance Mo dule systems for many languages have traditionally supp orted these re

quirements with notions of isolated name spaces visibilitycontrol via exp ort op erations and sharing

and reuse via imp ort op erations OO languages supp ort these same requirements indeed more

eectively via analogous notions of ob jects publicprivate attributes and reuse via inheritance

In recognition of their role as the fundamental unit of mo derndaysoftware construction wehave

chosen to refer to a distilled notion of classes as mo dules in this work

The Scheme mo dule system presented in this pap er has the following imp ortant features

It supp orts the requirements of largescale software development such as encapsulation sep

arate development and intermo dule conformability

In the spirit of Scheme it supp orts mo dules as rstclass entities and it is dynamic and in

teractive Also the notion of mo dules and their instances have a clear denotational semantics

based up on recordgenerators

It supp orts several idioms of ob jectoriented programming such as single prexbased mixin

based and multiple inheritance metho d denition and call wrapping abstract classes class

variables inheritance hierarchycombination and reection

It is language indep endent In fact it has b een implemented by reusing the design and co de

of a generic OO framework for mo dules

Weintro duce our mo del in Section comparing and contrasting it to conventional mo dule

systems In Section we illustrate how our mo del supp orts common notions of single inheri

tance Section illustrates supp ort for three variants of multiple inheritance In Section we

briey cover the semantics and applications of nested mo dules a particularly expressive feature of

Mo dular Scheme In Section we describ e an implementation of our language as a completion of

a generic OO framework We then relate our work with other research and present conclusions

Mo dules and Instances

Weintro duce our mo del of mo dules by relating it to mo dule systems for Scheme such as those

given in In these systems a mo dule is essentially an environment for binding names to

values A mo dule is a name scop e that explicitly provides exp orts names and requires imp orts

other names All names in the environment are directly accessible within the environment itself

whereas public names imp orted from other environments are dynamically b ound

In contrast mo dules in our mo del conceptually abstract over environments Mo dule intercon

nection is established by actually combining mo dules with interconnection validation at combi

nation time Individual instances of mo dules represent concrete environments such as those in

traditional systems Sp ecicall y mo dules abstract over the notion of what self means until they

are instantiated This enables a remarkable degree of exibility in their manipulation

In Mo dular Scheme a mo dule consists of a list of attributes with no order signicance At

tributes are of two kinds Mutable attributes are similar to Scheme variables and can store any

Scheme value Immutable attributes are symb ols b ound to Scheme values in a readonly manner

ie they can b e accessed but not assigned to

A mo dule is a Scheme value that is created with the mkmo dule primitive Mo dules can b e

manipulated but their attributes cannot b e accessed or evaluated until they are instantiated via

the mkinstance primitive The syntax of these two primitives is

mkmo dule hmutableattributelist ihimmutableattributelist i

mkinstance hmoduleexpr i

The attributes of an instance can b e accessed via the attrref primitive and assigned to via

the attrset primitive Pro cedures within a mo dule can access sibling attributes via the selfref

primitive and assign to them with the selfset primitive These primitives are explained in more

detail in Section

Figure b ox a shows a mo dule b ound to a Scheme variable vehiclefuel The mo dule has one

mutable attribute fuel and two immutable attributes empty b ound to a pro cedure whichchecks

to see if the fuel tank is empty and ll b ound to a pro cedure that lls the fuel tank of the vehicle

to capacityThell metho d refers to an attribute capacity that is not dened within the mo dule

but is exp ected to b e the fuel capacityofthevehicle in gallons In the vo cabulary of traditional

mo dule systems the ab ove mo dule exp orts the three symbols fuel emptyandll and implicitly

imp orts one symbol capacity

dene vehiclefuel mkmo dule

fuel

empty lamb da

a

selfref fuel

ll lamb da

selfset fuel selfref capacity

dene vehiclefuel hide vehiclefuel fuel

describ e vehiclefuel

b

fuel empty lamb da selfref privattr


dene vehiclecapacity mkmo dule

capacity

c

morecapacity lamb da v

attrref v capacity selfref capacity

dene vehicle merge vehiclefuel vehiclecapacity

d

dene v mkinstance vehicle

Figure Mo dule denition combination and instantiation

Encapsulation

One of the most imp ortant requirements of mo dule systems is encapsulation This is supp orted by

the primitive hide which returns a new mo dule that encapsulates the given attributes

hide hmoduleexpr ihattrnamelistexpr i

In b ox b of Figure the hide expression creates a new mo dule with an encapsulated fuel

attribute with an internal inaccessible name This is shown by the describ e primitiveaspriv

attr
Hiding results in what is known as ob jectlevel encapsulation ie the hidden attributes

of a particular instance of a mo dule are accessible only by selfreference primitives eg selfref

within that individual instance They are not accessible externally eg via attrref not even by

the incoming parameter of a binary metho d suchasthev parameter of the morecapacity metho d

of mo dule vehiclecapacity shown in b ox c of Figure

Interconnection

The mo dule vehiclecapacity given in Figure b ox c exp orts two symb ols capacity that represents

the fuel capacityofavehicle in gallons and morecapacity b ound to a pro cedure that determines

if the incoming vehicle argument has more fuel capacity than the currentvehicle

This style of encapsulation is similar to Smalltalk and in contrast to the classlevel encapsulation of C

The mo dule vehiclefuel canbecombined with vehiclecapacity to satisfy its imp ort requirements

This can b e accomplished as shown in b ox d via the primitive merge which has the following

syntax

merge hmoduleexpr ihmoduleexpr i

The primitive merge do es not p ermit combining mo dules with conicting dened attributes ie

attributes that are dened to have the same name

The new merged mo dule vehicle in b ox d exp orts ve symb ols and imp orts none An instance

of this mo dule suchasv in b ox d represents exactly the kind of mo dule interconnectivity that

can b e sp ecied by the use of imp ortexp ort op erations in traditional mo dule systems

Attribute Access

In this section we describ e attributes and their access in more detail Mutable attributes are

b ound to fresh lo cations up on mo dule instantiation and initialized with the value asso ciated with

each attribute The initialization value of a mutable attribute can b e changed via the primitive

override describ ed in Section Immutable attributes are b ound prior to instantiation but can

be rebound via overrideWe will refer to immutable attributes that are b ound to pro cedures as

methods b orrowing from OO programming Immutable attributes can also b e b ound to other

mo dules called nestedmodules dealt with in Section

The attributes of an instance are accessed with the following primitives

attrref hinstanceexpr ihattributename ihargexpr i

attrrefc hinstanceexpr ihattributename i

attrset hinstanceexpr ihattributename ihexpr i

The values of b oth mutable and immutable attributes are accessed with the primitive attrref

If the referenced attribute is a metho d it is applied with the given arguments and its value

returned Syntactically accessing the value of a nonmetho d attribute via attrref is exactly the

same as applying a metho d with no arguments A metho d can also b e accessed as a rstclass

closure without applying it via the primitive attrrefc For nonmetho d attributes attrrefc is

semantically equivalenttoattrref Mutable attributes are assigned with the primitive attrset

A metho d can access the instance within which it is executing via the expression self Thus

a metho d can access a sibling attribute within the same instance as attrref self hattrname i

However encapsulated attributes cannot b e accessed in this manner For this a metho d uses the

analogous primitives selfref and selfrefc to access the values of attributes and selfset to assign

to mutable attributes of the instance within which it is executing

selfref hattributename ihargexpr i

One can check if the imp ort requirements of individ ual mo dules are satised by using the introsp ection primitives

describ ed in Section

dene newcapacity

a

mkmo dule capacity

dene newvehicle override vehicle newcapacity

dene vehicle copyas vehicle capacity defaultcapacity

describ e vehicle

b

capacity defaultcapacity ll lamb da selfset fuel selfref

Figure Rebinding and copying

selfrefc hattributename i

selfset hattributename ihexpr i

Accesses via these primitivies are called selfreferences whereas accesses via attrref and attrset

are called external references Figure shows examples of the use of some of these primitives

Abstract Mo dules

An attribute is called undened if it is selfreferenced or referenced from a nested mo dule but is

not sp ecied in the mo dule A mo dule is abstract if any attribute is left undened In keeping

with dynamic typing in Scheme an abstract mo dule can b e instantiated since it is p ossible that

some metho ds can run to completion if they do not refer to undened attributes It is a checked

runtime error to refer to an undened attribute

Single Inheritance

Wenowgobeyond traditional mo dule systems and showhow our mo del supp orts idioms of OO

programming We start with single inheritance but we need to rst intro duce two primitives

override hmoduleexpr ihmoduleexpr i

copyas hmoduleexpr ihfromnamelistexpr ihtonamelistexpr i

The op erator override pro duces a new mo dule bycombining its arguments If there are conict

ing attributes it cho oses hmoduleexpr is binding over hmoduleexpr is in the resulting mo dule

For example the abstract mo dule newcapacity in b ox a of Figure cannot b e merged with vehi

cle since the two mo dules have a conicting attribute capacityHowever newcapacity can override

vehicle as shown This way immutable attributes can b e reb ound and mutable attributes can b e

asso ciated with new initial values

The primitive copyas copies the denitions of attributes in hfromnamelistexpr i to attributes

with corresp onding names in htonamelistexpr iThefrom argument attributes must b e dened

deneclass vehicle f

fuel

capacity

a

ll lamb da selfset fuel selfref capacity

display lamb da format t fuel a capacitya

selfref fuel selfref capacity

deneclass landvehicle vehicle

wheels

b

display lamb da

selfref sup erdisplay

format t wheels a selfref wheels

dene landvehicle

hide override copyas vehicle display sup erdisplay

mkmo dule

wheels

c

display lamb da

selfref sup erdisplay

format t wheels a selfref wheels

sup erdisplay

Figure Single inheritance

An example is shown in b ox b of Figure

Sup er

With the op erators discussed thus far we can describ e supp ort for single inheritance Many single

inheritance systems such as Smalltalk and Mo dula ob ject typ es mo dulo static typing

share the notion of a class consisting of metho ds and encapsulated instance variables In these

systems it is p ossible to sp ecify a class declaration similar to that shown in b ox a of Figure

The deneclass construct will b e explained b elow In this example the attribute fuel is intended

to b e encapsulated as an instance variable and the Scheme constant f false indicates that the

class has no sup erclasses Such a class declaration is equivalent to writing a mkmo dule expression

and hiding the fuel attribute of the resultant mo dule

Subsequently a sub class landvehicle of vehicle can typically b e sp ecied in such systems in a

manner similar to b ox b In this denition a new attribute wheels is added and the display

binding is overridden with a metho d that accesses the shadowed metho d as selfref sup erdisplay

Such a sub class denition is exactly equivalent to sp ecifying the mo dule expression shown in b ox

c In this expression a mo dule with attributes wheels and display is created and is used to

let conicts conictsb etween mo d attrsof mo d

a

copyas mo d conicts prep end sup er conicts

b

hide vehicle mutableattrsof vehicle

c

dened vehicle selfrefsin vehicle morecapacity

Figure Introsp ection

override the sup erclass vehicle in whichthedisplay attribute is copied as sup erdisplay We then

hide away the copied sup erdisplay attribute to get a mo dule with exactly one display metho d in the

public interface as desired

One can write a macro in Mo dular Scheme to translate deneclass expressions such as those

for vehicle and landvehicle into mo dule expressions In fact a library of several such useful macros

accompanies Mo dular Scheme One macro for single inheritance accepts the following syntax

deneclass hname ihsuper ihinstvarlist ihmethodlist i

The general form of the mo dule expression shown in b ox c of Figure turns out to b e a

useful idiom in Mo dular Scheme It can b e used for expressing other eects such as prexbased

inheritance wrapping and mixin combination describ ed later We shall refer to this form as the

copyoverridehide idiom

Introsp ection

The macro deneclass given ab ove automatically nds conicting attributes b etween two mo dules

by using an introspective primitivecalledconictsb etween It then uses the copyoverridehide

idiom as shown in Figure to achieve single inheritance

There are several primitives available for determining various kinds of information ab out mo d

ules and instances Some of them are

conictsb etween hmoduleexpr ihattrnamelistexpr i

mo duleof hinstanceexpr i

attrsof hmoduleexpr i

mutableattrsof hmoduleexpr i

dened hmoduleexpr ihattrnamelistexpr i

selfrefsin hmoduleexpr ihattrnamelistexpr i

As mentioned the primitive conictsb etween returns a list of attribute names that are dened

in the given mo dule and also exist in the given list For example all the attributes of a mo dule

that conict with another mo dule can b e copied by using the expression in b ox a of Figure

The mo dule from which an instance was created can b e obtained with the primitive mo duleof

Thus mo duleof self is similar to self class in Smalltalk like current in Eiel and myclass

in The names of the publicly accessible attributes of a mo dule are accessible via the attrs

of primitives For example the mutable attributes of a mo dule can b e encapsulated with the

expression in b ox b of Figure The primitive dened is used to determine if an attribute is

dened in a mo dule It returns f if any one of the given attributes names is undened in the given

mo dule If all of them are dened it returns the incoming list of attribute names

It is sometimes useful to know the names of public attributes that are selfreferenced within

a metho d The primitive selfrefsin returns a at list comprising the set of all the selfreferenced

public attributes within the bindings of the given attribute names Argument attribute names

that are nonexistent or b ound to nonmetho d values are ignored For example to determine if a

metho d will execute without runtime errors relating to lo cally undened public attributes private

attributes are always dened one can evaluate the expression in b oxc

It is worth mentioning that the introsp ective op erations given ab ove do not violate encapsulation

since we do not p ermit any access to the private attributes of mo dules

Adaptation

Apart from hide and copyas there are three other primitives which can b e used to create new

mo dules by adapting some asp ect of the attributes of existing mo dules

freeze hmoduleexpr ihattrnamelistexpr i

rename hmoduleexpr ihfromnamelistexpr ihtonamelistexpr i

restrict hmoduleexpr ihattrnamelistexpr i

The primitive freeze statically binds selfreferences to the given attributes provided they are

dened in the mo dule Freezing the attribute capacity in the mo dule vehicle causes selfreferences to

capacity to b e statically b ound but the attribute capacity itself is available in the public interface for



further manipulation eg rebinding bycombination As shown in b ox a of Figure frozen self

references to capacity are transformed to refer to a private version of the attribute Op erationally

the binding of the private version is shared with the public version as long as the public version is

not reb ound to a new value via overriding This implies that frozen references to mutable attributes

are always shared since mutable attributes can never b e reb ound they can just b e initialized to

new values

The primitive rename changes the names of the denitions of and selfreferences to attributes

in hfromnamelistexpr i to the corresp onding ones in htonamelistexpr i An example is shown in

box b Undened attributes ie attributes that are not dened but are selfreferenced can also

b e renamed



This eect is similar to converting accesses to a virtual C metho d into accesses to a nonvirtual metho d The

dierence is that C allows nonvirtual metho ds to b e in the public interface of a class the general philosophy

here is that all public attributes are rebindable or virtual like in Smalltalk

dene vehicle freeze vehicle capacity

describ e vehicle

a

capacity ll lamb da selfset fuel selfref privattr

dene vehicle rename vehicle capacity fuelcapacity

describ e vehicle

b

fuelcapacity ll lamb da selfset fuel selfref fuelcapacity

dene vehicle restrict vehicle capacity

describ e vehicle

c

ll lamb da selfset fuel selfref capacity

Figure Adaptation

The primitive restrict simply removes the denitions of the given dened attribute names from

the mo dule ie makes them undened An example is shown in b ox c of Figure

These mo dule manipulation primitives are applicative in the sense that they return new mo d

ules without destructively mo difying their arguments However destructiveversions of the op era

tors are also available so that comp osite mo dule op erations can b e expressed without compromising

eciency by making unnecessary copies The name of the destructiveversion of a primitive is writ

ten as the corresp onding name of the nondestructive primitive suxed with a eg hide is the

destructiveversion of hide Destructive mo dule primitives are to b e used with caution and used

only for optimizing stable programs

Prexing

The programming language Beta supp orts a form of single inheritance called prexing whichis

quite dierent from the single inheritance presented in Section In prexing a sup erclass metho d

that exp ects to b e reb ound by a sub class denition uses a construct called inner somewhere in its

body In instances of the sup erclass calls to inner amounttonull statements or noops Sub classes

can redene the metho d and in turn call inner In sub class instances the sup erclass metho d is

executed rst and the sub class redenition is executed up on encountering the inner statement

The ab ove eect can b e achieved in Mo dular Scheme with the macro deneprex illustrated

with the vehicle example in Figure Box a fo cuses on the display metho d of the vehicle class The

expression selfref innerdisplay corresp onds to the inner construct This class denition expands

to the mo dule expression shown in b ox b where a dummy innerdisplay attribute is merged in

In fact the deneprex macro adds such a dummy attribute prep ended with inner for every

denepre x vehicle f

a



display lamb da  selfref innerdisplay 

dene vehicle mkmo dule 



b

display lamb da  selfref innerdisplay 

innerdisplay t

denepre x landvehicle vehicle

c



display lamb da  selfref innerdisplay 

dene landvehicle

hide override copyas mergeinner sub display subdisplay

d

rename vehicle innerdisplay subdisplay

subdisplay

Figure Prexing

immutable attribute in the denition A sub class landvehicle of vehicle is dened in b oxc

which expands to the expression in b ox d In this expression the sub class is rst merged in

with a dummy innerdisplay with the function mergeinner sub The sub class display metho d is

then copied as subdisplay and overridden with the sup erclass in which innerdisplay is renamed to

subdisplay Lastly subdisplay is hidden away so that there is only one display metho d

This example also uses the copyoverridehide idiom intro duced in Section The dierence

here is that the sup erclass overrides the sub class as opp osed to the reverse in Section Indeed

this is the dierence b etween prexbased and sup erbased forms of single inheritance

Wrapping

Wrapping similar to the CLOS notion of around metho ds is useful in manycontexts In fact

wrapping metho d denitions can b e used to simulate b efore and after metho ds of CLOS as well

since new co de can b e interp osed b efore or after the call to the old co de It is easy to wrap metho d

denitions using the copyoverridehide idiom shown earlier Mo dular Scheme provides a macro

called wrapmetho d to achieve this eect but we shall omit its description here to conserve space

A more interesting and less often explored eect is to wrap selfreferenced cal ls to particular

metho ds Saywehave a mo dule vehsim shown in b ox a of Figure whichisintended to b e

combined with the vehicle mo dule Its metho d simll calls the undened metho d ll up on some

condition llconditionSaywewanttocount the numb er of calls to ll that simll makes Wedo

not want to wrap the metho d ll in vehiclesincewewanttocount only calls from simll Also

dene vehsim mkmo dule 

simll lamb da v

a

if llcondition v

selfref ll

dene countedvehsim

let countsim merge vehsim mkmo dule count

wrapcall countsim ll

b

lamb da

selfset count selfref count

selfref ll

hide merge rename countsim ll wrapll

mkmo dule

wrapll lamb da

c

selfset count selfref count

selfref ll

wrapll

Figure Wrapping calls to metho ds

we cannot wrap the simll metho d to do this since every call to it do es not necessarily result in a

call to ll due to the llcondition test

Thus we need to wrap cal ls to ll from the vehsim mo dule using the wrapcall macro shown

in b ox b Weaddamutable attribute count to vehsim and wrap its calls to ll to increment

the counter The mo dule expression that the wrapcall expands into is given in b ox c In this

expression werstrename the undened attribute ll to wrapllthus changing the selfreferences

corresp ondinglyWe then merge in a wrapll metho d that increments count and calls the old ll

metho d in the resulting mo dule

The general form of the expression in b ox c is another useful idiom in the language and will

b e referred to as the renamemergehide idiom The distinction b etween the copyoverridehide

idiom and the renamemergehide idiom is worth exploring Figure pictorially shows the use of

these idioms for metho d denitions in the rst row and metho d calls in the second In the gure

shaded b oxes represent hidden metho ds

For metho d denitions b oth the idioms are used when a metho d METH of M is b eing redened

by M and the old denition of the metho d is referred to in the redenition as METH The

dierence is that copyoverridehide is used when Ms references to METH are to refer to the new

METH in the combined mo dule Renamemergehide is used when Ms references are to refer to

the old denition renamed as METH while Ms references are to refer to the redenition As

an example scenario renamemergehide is not appropriate to achieve the right eect of single IDIOM COPY-OVERRIDE-HIDE RENAME-MERGE-HIDE

M1 METH METH’ METH’

METH’

M2 METH METH METH METHOD DEFINITION

METH METH

M3 WRAP WRAP Cannot COPY METH calls M5 METHOD CALL

M4

Figure Idioms in Mo dular Scheme

inheritance For example in b ox c of Figure renaming vehicles display metho d instead of

copying it would not work since in that case selfreferences to display in vehicle would also b e

renamed wewant selfreferences in the sup erclass to refer to the new reb ound display metho d

For metho d calls only the renamemergehide idiom applies since undened attributes cannot

b e copied In Figure mo dule M has a call to METH which is wrapp ed to pro duce M as shown

An example was given in the rst half of this section

Multiple Inheritance

Wehave seen in the previous section how to express the creation of a sub class from a single

sup erclass With multiple inheritance there is the additional problem of how to comp ose the

sup erclasses by resolving conicts and sharing attributes b etween them Typically a language

supp orting multiple inheritance makes available to the programmer a small number of choices

for attribute sharing and conict resolution The advantage of OO programming with op erator

based inheritance is that the programmer has numerous options for and negrained control over

decisions taken while combining multiple mo dules Also inheritance history do es not intrude into

op erator semantics making the approach more comp ositional

Mixins and Linearized Multiple Inheritance

Consider the case of linearized multiple inheritance as in Flavors and Lo ops where the graph of

ancestor classes of a class are linearized into a single inheritance hierarchyEach of these languages

sp ecies a dierent default rule for the linearization of ancestor classes For example b oth these

dene landvehchars mkmo dule

wheels

display lamb da selfref sup erdisplay

format t wheels a selfref wheels

a

dene seavehchars mkmo dule

surface t

display lamb da selfref sup erdisplay

format t surface a selfref surface

denesub c lass landvehicle landvehchars vehicle

b

denesub c lass seavehicle seavehchars vehicle

denesub c lass amphibian landvehchars seavehchars vehicle

dene amphibian

hide override copyas vehicle display sup erdisplay

hide override copyas seavehchars display sup erdisplay

c

landvehchars

sup erdisplay

sup erdisplay

Figure Linearized Multiple Inheritance

languages do a depthrst lefttorighttraversal of ancestor classes up to join classes ie classes

that are encountered more than once which get traversed on their rst visit in Flavors and last

visit in Lo ops

It has b een argued that currently used linearizations do not ensure that the inheritance mech

anism b ehaves naturally relative to the incremental design of the inheritance hierarchy

Perhaps it is b etter to let the programmer select the precedence order of sup erclasses as dictated

by individual applications In the case of CLOS a programmer with considerable exp ertise can

use the metaob ject proto col of the language and adapt the default rule In contrast programming

with op eratorbased inheritance gives the programmer direct control over combination as shown

in Figure

Saywewant to create mo dules for land vehicles and sea vehicles as sub classes of vehicleWe

can dene mo dules with the characteristics of land vehicles numb er of wheels and sea vehicles

surface vessel or submarine as shown in b ox a In these mo dules one can think of the expression

selfref sup erdisplay as b eing the equivalentofcallnextmetho d in CLOS Abstract mo dules such

as these are sometimes called mixins reusable abstractions that require other abstractions in

order to b e usefully applied Such abstractions havebeencharacterized as functions from classes

to classes However the approach of op eratorbased inheritance given here uniformly treats all

asp ects of inheritance as op erations over mo dules as was rst develop ed in

With the denitions in b ox a we can create landvehicle and seavehicle sub classes of vehicle

dene color

mkmo dule

a

color white

setcolor lamb da newcolor selfset color newcolor

display lamb da format t color a selfref color

dene carclass

hide merge merge rename color display colordisplay

rename landvehicle display vehicledisplay

b

mkmo dule

display lamb da selfref vehicledisplay

selfref colordisplay

colordisplay vehicledisplay

Figure Multiple Inheritance with no common ancestors

as shown in b ox b This is achieved using the copyoverridehide idiom Figure but with

the macro denesub clas s which accepts a slightly dierentsyntax Similarlywe can chain the

creation of sub classes so that the call to sup erdisplay in each class calls the display metho d of the

next lower precedence sup erclass Thus we can create an amphibian class that inherits b oth the

characteristics of land and sea vehicles The denesub class macro for amphibian expands to the

mo dule expression shown in b ox c note the cascaded use of the copyoverridehide idiom and

extends to an arbitrary numb er of sup erclasses as desired

Multiple Inheritance with No Common Ancestors

Let us now consider the case of multiple sup erclasses that are not linearized and have no common

ancestor Saywehave a mo dule color dened as in b ox a of Figure We can combine color

with the mo dule landvehicle shown earlier into carclass as shown in b ox b This expression uses

the renamemergehide idiom intro duced in Section The metho d display that conicts in the

sup erclasses vehicle and color is renamed in each and the sup erclasses are merged together A

new mo dule that denes a display metho d that calls the renamed display metho ds is then merged

in to create the desired carclass This example can b e extended to more than two sup erclasses

and can b e automated via a macro that uses the introsp ective primitive conictsb etween to rename

attributes

The renamemergehide idiom works ne for this example since there are no selfreferences to

the renamed attribute in the sup erclasses However the right eect of inheritance can only b e

obtained with copyas so that selfreferences in the sup erclasses are not changed followed bya

merge so that accidental conicts b etween sup erclasses do not get quietly reb ound The problem

with copying conicting attributes and merging is that the conicts will still p ersist This can b e

override override rename landvehicle fuel landfuel

rename seavehicle fuel seafuel

mkmo dule

display lamb da

format  selfref landfuel selfref seafuel 

Figure Multiple Inheritance with common ancestors

remedied by restricting Section after copying and then merging and hiding There is some

similaritybetween such a copyrestrictmergehide op eration and the copyoverridehide idiom

Multiple Inheritance with Common Ancestors

In the case of sup erclasses with a common ancestor such as in the diamond problem of multiple

inheritance the situation gets more complex In this case the attributes of the common ancestor

are clearly conicting in the sup erclasses Furthermore there is the choice of inheriting either a



single copyormultiple copies of mutable attributes from the common ancestor

To illustrate consider the two previously given mo dules landvehicle and seavehicle whichhave

each inherited from the vehicle mo dule Saywewant to create an amphibian mo dule that inherits

from these two mo dules but needs two copies of the fuel attribute to mo del two dierent kinds

of fuels for amphibians This can b e achieved with the expression in Figure In this example

the fuel attribute is renamed for eachtyp e of mo dule The two mo dules are then overridden since

the conicting attributes capacity and ll are known to b e identical and the metho d display will

be overridden in the nal mo dule Anew display metho d that displays all the attributes in an

appropriate way is included in the nal comp osition to get the desired mo dule

The distinction b etween programming with rstclass mo dules and the op erational style more

often found in OO languages is illustrated by this example Firstly problems of conicts and

sharing clearly manifest themselves and comp ell the programmer to resolve them as the particular

situation demands using introsp ection and inheritance op erators For example conicts b etween

sup erclasses can b e insp ected with conictsb etween and sup erclasses can b e overridden in some

appropriate order to resolve attribute conicts If multiple copies of mutable attributes from the

common ancestor are desired they can b e renamed within each sup erclass as shown in the example

ab ove However the burden of resolving conicts in each individual case can b e removed by writing

macros that p erform a userchosen metho d of comp osition Secondly the inheritance history of

sup erclasses is not imp ortant only the attributes of sup erclasses must b e known in order to derive

a sub class



This of course is the rationale for virtual and nonvirtual base classes in C

Nested Mo dules

Since mo dules are rstclass values attributes of mo dules can themselves b e mo dules Mo dules

that are b ound to immutable attributes of other mo dules are referred to as nestedmodulesWe

will give brief examples in this section to give some insightinto the semantics and applications of

nested mo dules a full treatmentisbeyond the scop e of this pap er

Semantics

The metho ds of mo dules can explicitly refer to bindings in their surrounding scop es using the

following primitives which refer to the given name in a lexically surrounding scop e that has a

binding for the name

envref hattributename ihargexpr i

envrefc hattributename i

envset hattributename ihexpr i

These three primitives serve functions analogous to the three selfreference primitives It is a

checked runtime error to refer to a name that do es not have a binding in some surrounding scop e

Mo dules follow static scoping rules just like the rest of Scheme The environment of a mo dule

is determined by the lexical placement of the mkmo dule expression that creates it In Figure

box a typ e and typ e are nested mo dules whose ll metho ds refer to the capacity attribute of

the outer mo dule Individual vehicles are represented by instances of the nested mo dules

The mkmo dule expressions for these nested mo dules are evaluated at the time the outer mo dule

vehiclecategory is instantiated Thus nested mo dules have an instance of their surrounding mo dule



as their environment and are b ound to their environment at the time of instantiation of the outer

mo dule Thus v in b ox a is a vehicle that shares the capacity attribute of vehiclecategory with

other instances of typ e and typ e Thus the attribute capacity serves the purp ose of a class

variable a variable that is shared among the instances of a class

With static scoping a mo dule and its nested mo dules interact in nonobvious ways For example

envrefs in nested mo dules are equivalenttoselfrefs in the outer mo dule Thus changes to a

mo dules attributes eg via rename freeze static binding and hide result in mo dications to the

environment of nested mo dules and hence mo dify the environment references in nested mo dules

However once the outer mo dule is instantiated environment references in nested mo dules are

p ermanently b ound regardless of whether the nested mo dule is moved to and combined in another

environment with other nested mo dules created in yet other environments This is analogous to

the creation and manipulation of rstclass closures ie pro cedures with environment references

in Scheme



Nonnested mo dules haveastheirenvironmenttheScheme environment in eect when they are created

dene vehiclecategory

mkmo dule

capacity

typ e mkmo dule  ll lamb da  envref capacity 

a

typ e mkmo dule  ll lamb da  envref capacity 

car lamb da override selfref typ e

mkmo dule color white

dene mycategory mkinstance vehiclecategory

dene v mkinstance attrref mycategory typ e

dene cap mkmo dule

typ e mkmo dule capacity

dene vehcap

merge merge restrict copyas vehiclecategory typ e vehtyp e

b

restrict copyas cap typ e captyp e

mkmo dule

vehicle lamb da

override selfref vehtyp e selfref captyp e

dene manager mkmo dule

new lamb da mkinstance selfref class

c

ref lamb da inst attr args

eval app end attrref inst attr args

Figure Nested Mo dules

Applications

Shared rep ository A mo dule provides a lo cal namespace for nested mo dules It can serveas

a shared data rep ository for nested mo dules in addition to serving as a factory that pro duces

initialized instances of nested mo dules An interesting consequence of this is that names that are

not b ound within the toplevel environment can b e considered p ersistent names this is left as

future work

Hierarchy combination An inheritance hierarchy in OO programming is usually thought

of as a graph of inheriting classes In Mo dular Scheme an inheritance hierarchy is represented

simply by a collection of mo dule expressions some of which are mkmo dule expressions and others

which combine and adapt these mo dules Such a hierarchy of mo dules can b e nested within another

mo dule That is the base class of the hierarchy can b e a nested mo dule and other mo dules that

inherit from it can b e computed via mo dule expressions within metho ds of the outer mo dule since

mo dules are rstclass For example a hierarchy consisting of a typ e mo dule and its sub class

car are shown in b ox a of Figure

Entire hierarchies such as the ab ove can b e combined with other hierarchies by manipulating

the outer mo dules Consider a hierarchy cap with a nested mo dule typ e with a single attribute

capacity as given in b ox b of Figure Supp ose we wish to extend the hierarchy vehiclecategory

with the hierarchy cap so that an attribute capacity is added to the typ e mo dule ie the su

perclass which will b e automatically inherited by car ie the subclass This can b e achieved

with the expression shown in b ox b of Figure Several applications of this style of hierarchy

combination are given in

Manager mo dules Reection is a means by which programs can access and manipulate them

selves Mo dular Scheme supp orts a form of reective programming on mo dules with the intro

sp ective primitives given in Section in conjunction with what are called manager modulesA

manager mo dule consists of a nested mo dule along with metho ds that manipulate some extensible

functionality to b e supp orted on the nested mo dule In a sense a manager mo dule can b e used to

simulate a metaclass in more conventional designs this has already b een shown by using blo ck

structure in the programming language Beta page

For example a generic manager mo dule can b e sp ecied as in b ox c of Figure This mo dule

sp ecies a metho d new that returns an instance of an undened attribute called class and a metho d

ref that accesses the attribute attr of inst Basicallythenew and ref metho ds act as surrogates for



mkinstance and attrref for mo dules b ound to the attribute class The idea is that any mo dule

can b e b ound to the attribute classandthenew and ref metho ds can b e sp ecialized appropriately

for that mo dule via manipulation of the manager mo dule

Implementation

Most of the notions of mo dule manipulation nesting and introsp ection describ ed ab ove are inde

p endent of the language into which they are emb edded In fact an ob jectoriented framework

called Etyma incorp orating these generic notions has b een designed and implemented in C

The language describ ed here has b een realized as one completion of Etyma Among the other

completions of Etyma are a linker and a compiler for an interface denition language describ ed

in This section describ es the OO design and implementation of the mo dular extension to a

basic Scheme interpreter

The overall architecture of the implementation is shown in Figure The interpreter for

Mo dular Scheme is implemented as an extension of the Scheme interpreter provided in the STk

package The basic Scheme interpreter is implemented in C The co de for the extension is

designed as a set of C classes that inherit from classes in Etyma The Scheme library shown



The new and ref metho ds could actually b e named mkmo dule and attrref ETYMA

C++

library basic interpreter glue Scm completion

C C++

Figure Architecture of extended Scheme interpreter

on the left includes the macros for OO programming presented in this pap er as well as other

functions

A complete description of the design of the C framework Etyma is b eyond the scop e of

this pap er Briey Etyma mo dels generic linguistic notions that are found in mo dular languages

such as Mo dular Scheme thus constituting a metaarchitecture for mo dular systems For example

Etyma sp ecies abstract classes Mo dule and Instance that mo del the corresp onding notions with

the op erators for manipulation as their metho ds Etyma also sp ecies classes Interface PrimValue

Metho d Lo cationandLab el that mo del the corresp onding notions Standard concrete implementa

tions of C classes for mo dules instances and interfaces are available as StdMo dule StdInstance

and StdInterface All these classes collab orate with one another to mo del the linguistic concepts of

ob jectoriented languages

ETYMA classes

LabelPrimValue Method Location StdModule StdInstance StdInterface

SchLabel SchValue SchMethod SchLocation SchModule SchInstance SchInterface

Completion subclasses

Figure Design of classes in the framework completion

Reuse parameter New Reused reuse

Classes

Etyma Metho ds

Lines of Co de

Etyma STk Lines of Co de

Figure Reuse of framework design and co de

In order to construct an interpreter for Mo dular Scheme we mo deled Scheme concepts as sub

classes of generic concepts in Etyma The only sub classes created to implement Mo dular Scheme

are shown in Figure The reusability of the framework design in conjunction with the extensi

bility of the basic Scheme interpreter made the degree of reuse so high in this case that most of

Mo dular Scheme was designed and implemented in ab out a week Figure shows several mea

sures of reuse for this completion The p ercentages for class and metho d reuse give an indication

of design reuse whereas those for lines of co de give a measure of code reuse

Related Work

The design of Mo dular Scheme is based up on a semantic notion of mo dules that go es backto

record calculi Classes were mo deled as record generators byCook who also rst

intro duced some of the op erators used here Based on this Bracha and Lindstrom in develop ed

a comprehensive suite of op erators to supp ort sharing encapsulation and static binding Here

wehave augmented the ab ove mo del with the detailed semantics of nested mo dules designed and

implemented a generic framework based on these notions completed it to realize a realistic language

design and illustrated typical programming styles and idioms in the language

Mo dular programming has traditionally dealt with issues of structuring encapsulation and

indep endent developmentofsoftware Known byvarious names suchaspackages structures etc

mo dules have long played the role of static design artifacts However it has not yet b een

widely recognized that OO programming is but a sophisticated form of mo dular programming The

power of rstclass mo dules as given here is even less recognized In the context of Scheme several

mo dule systems havebeendevelop ed These systems essentially provide the functionality

describ ed in Section although supp orts explicit interfaces Lisp packages and Scheme

rstclass environments are much restricted forms of mo dularity compared to the system presented

here

Beta provides a uniform mo del of programming via patternsHowever it do es not supp ort rst

class mo dules or op eratorbased inheritance Betas style of prexing is describ ed and simulated in

Section Beta supp orts arbitrary nesting of mo dules with which metaclasses can b e simulated

as with manager mo dules Section There is also some similaritybetween manager mo dules and

the concept of ob ject managers given in the language Paragon a language for programming

with abstract data typ es

A p opular language family for OO programming with Lisp is the CLOS family of languages

CLOS supp orts a quite dierent mo del of OO programming than the one describ ed

here with multipledisp atch generic functions and weak encapsulation Mo dular Scheme on the

other hand supp orts only single dispatch CLOS also supp orts a proto col to interact with its

metaarchitecture Dexterityofmultiple inheritance as given in Section was a primary practical

motivation for the CLOS MOP

Systems such as the CLOS metaob ject proto col MOP and Op en C exp ose the

implementation ob jects of the language pro cessor to the programmer via a controlled proto col

Many asp ects of the languages implementation such asobjectdatalayout are controllable via

such a metaproto col The approach to OO programming describ ed here is to provide the exibili ty

of metaprogramming without exp osing the metaarchitecture to direct user programming Our

approach do es not give the user the full p ower of altering a languages b ehavior as a MOP can

However wefavor a small set of welldesigned primitives that can as eectively provide a uniform

and exible mo del of OO programming

Other sp ecic related languages and semantics are cited throughout the pap er

Conclusions

Mo dule systems and OO programming have long strived to achieve the requirements of largescale

programming such as encapsulation comp onentwise development and reuse In this pap er we

showed that these requirements can b e met in a uniform and exible manner by programming

with rstclass mo dules and op eratorbased inheritance Mo dules are manipulated with a suite

of op erators that individuall y achieve eects such as encapsulation combination sharing and

introsp ection This mo del of mo dularity has b een smo othly integrated into the programming

language Scheme while keeping with its original design philosophy that a very small number

of rules for forming expressions with no restrictions on how they are comp osed suce to form a

practical and ecient programming language that is exible enough to supp ort most of the ma jor

programming paradigms in use to day

The ab ove language is expressive and exible enough to mo del most previously existing tech

niques of OO programming without recourse to metaprogramming Wehaveshown by examples

that the language can emulate an unprecedentedly broad array of idioms such as single prexbased

mixinbased and multiple inheritance abstract classes wrapping of metho d denitions and calls

class variables inheritance hierarchycombination and a form of reection Thus the language

provides mechanisms to supp ort all of the ab ove but do es not enforce any one inheritance p olicy

In eect this language represents a unication of the design space of dynamic singledispatch OO

programming languages

Finallywe show that the underlying concepts of this programming mo del are language inde

p endent Wehave designed and implemented a generic reusable OO framework in C that

incorp orates the basic abstractions of mo dularity and completed it to realize an interpreter for

our language Language indep endence is conclusively proved byshowing that the design and co de

reuse levels for our completion are very high

Some imp ortant areas of future work remain Static typing is desirable and p ossible within

our mo del although it would intro duce several restrictions to the programming style presented

here Compilation is a much more challenging issue esp ecially to devise comp osable techniques

paralleling the semantic one and to express in a language indep endent manner in our generic

framework

Acknowledgements

We gratefully acknowledge supp ort and several useful comments on this work from Jay Lepreau Bjorn

FreemanBenson Bryan Ford Doug Orr Rob ert Mecklenburg and Nevenka Dimitrova

References

Reference manual for the Ada programming language ANSIMILSTD A

Guruduth Banavar Gary Lindstrom and Douglas Orr EtymaAframework for mo dular systems CS

Dept TR UUCS University of Utah Decemb er Short version p ersented at the workshop

on OO Compilation at OOPSLA Portland OR

Gilad Bracha The Programming Language Jigsaw Mixins Modularity and Multiple InheritancePhD

thesis University of Utah MarchTechnical rep ort UUCS pp

Gilad Bracha and William Co ok Mixinbased inheritance In Proc OOPSLA ConferenceOttawa

Octob er ACM

Gilad Bracha and Gary Lindstrom Mo dularity meets inheritance In Proc International Conferenceon

Computer Languages pages San Francisco CA April IEEE Computer So ciety

Also available as Technical Rep ort UUCS

P Canning W Co ok W Hill and W Oltho Interfaces for stronglytyp ed ob jectoriented pro

gramming In Norman Meyrowitz editor Proceedings of the ACM Conference on ObjectOriented

Programming Systems Languages and Applications pages

Luca Cardelli James Donahue Lucille Glassman Mick Jordan Bill Kalsow and Greg Nelson Mo dula

rep ort Technical Rep ort Digital Equipment Corp oration Systems ResearchCenter August

Luca Cardelli and John C Mitchell Op erations on records Technical Rep ort Digital Equipment

Corp oration Systems ResearchCenter August

Shigeru Chiba and Takashi Masuda Designing an extensible distributed language with a metalevel

architecture In Proceedings of the th European Conference on ObjectOrientedProgramming Springer

Verlag LNCS

William Clinger and Jonathan Rees Revised rep ort on the algorithmic language scheme ACM Lisp

Pointers

William Co ok and Jen Palsb erg A denotational semantics of inheritance and its correctness In Proc

ACM Conf on ObjectOrientedProgramming Systems Languages and Applications pages

Pavel Curtis and James Rauen A mo dule system for scheme In ConferenceRecordoftheACM Lisp

and Functional ProgrammingACM

R Ducournau M Habib M Huchard and M L Mugnier Prop osal for a monotonic multiple inheri

tance linearization In Proceedings of OOPSLA pages pages Octob er

Erick Gallesio STk reference manual Version

Adele Goldb erg and David Robson Smal ltalk The Language and its Implementation Addison

Wesley

Rob ert Harp er and Benjamin Pierce A record calculus based on symmetric concatenation In Proc of

the ACM Symp on Principles of Programming Languages pages January

Ralph E Johnson and Vincent F Russo Reusing ob jectoriented designs Technical Rep ort UIUCDCS

University of Illinois at UrbanaChampagne May

Sonya E Keene ObjectOrientedProgramming in Common Lisp AddisonWesley Reading MA

Gregor Kiczales Jim des Rivieres and Daniel G Bobrow The Art of the Metaobject Protocol The

MIT Press Cambridge MA

Gregor Kiczales and Luis Ro driguez Ecient metho d dispatchinPCLInProceedings of the

ACM ConferenceonLispandFunctional Programming pages ACM

Bent Bruun Kristensen Ole Lehrmann Madsen Birger MollerPedersen and Kristen Nygaard The

BETA programming language In Research Directions in ObjectOrientedProgramming pages pages

MIT Press

David MacQueen Mo dules for Standard ML LFCS rep ort Dept of Computer Science Univ of

Edinburgh Scotland Part I I I of StandardMLby Rob ert Harp er David MacQueen and Robin

Milner

Ole Lehrmann Madsen Blo ck structure and ob jectoriented languages In Research Directions in

ObjectOrientedProgramming pages pages MIT Press

Bertrand Meyer ObjectOriented Software Construction Prentice Hall

Harold Ossher and William Harrison Combination of inheritance hierarchies In OOPSLA Proceedings

pages Octob er

Mark Steven Sherman Paragon A Language Using Type Hierarchies for the Specication Implemen

tation and SelectionofAbstract Data Types SpringerVerlag New York NY

Guy L Steele Jr Common Lisp The Language Digital Press Bedford MA

ShoHuan Simon Tung Interactive mo dular programming in scheme In Proceedings of the ACM Lisp

and Functional Programming Conference pages pages ACM

Last mo died February