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