TheTypeandClassSystemof EngineeringaProgramming ClemensSzyperskyStephenOmohundroy Language: StephanMurerz November1993 Sather TR-93-064 ofmanycriteria.itattemptstosupportapowerfulobject-orientedparadigmwithout sacricingeitherthecomputationalperformanceoftraditionalprocedurallanguagesor supportforsafetyandcorrectnesschecking.muchoftheengineeringeortwentintothe designoftheclassandtypesystem.thispaperdescribessomeofthesedesigndecisions andrelatesthemtoapproachestakeninotherlanguages.weparticularlyfocusonissues Sather1.0isaprogramminglanguagewhosedesignhasresultedfromtheinterplay Abstract surroundinginheritanceandsubtypingandthedecisiontoexplicitlyseparatethemin Sather. ICSI,E-mail:szyper@icsi.berkeley.edu. zicsiandeidgenossischetechnischehochschule(eth),zurich,switzerland.e-mail:murer@icsi.berkeley.edu. yicsi,e-mail:om@icsi.berkeley.edu.
ii
andhighcomputationaleciency. 1Introduction Satherisanobject-orientedlanguagedevelopedattheInternationalComputerScienceInstitute[22].It complex,performance-criticalapplications.suchapplicationsareinneedofbothreusablecomponents manceoftheeielimplementationsavailablein1990.eielintroducedanumberofimportantideas erfulobject-orientedparadigmwithoutsacricingeitherthecomputationalperformanceoftraditional typing,multiplesubtyping,multiplecodeinheritance,andgarbagecollection.itisespeciallyaimedat hasacleanandsimplesyntax,parameterizedclasses,object-orienteddispatch,statically-checkablestrong butalsomadecertaindesigndecisionswhichcompromisedeciency.satherattemptstosupportapow- procedurallanguagesorsupportforsafetyandcorrectnesschecking. madeavailablebyanonymousftp1inmay,1991anditwasquicklyretrievedbyseveralhundredsites. Thisversionachievedourdesiredeciencygoals[15]andwasusedforseveralprojects.Ourexperience withitandfeedbackfromotherusershasledtothedesignofsather1.0.thisimprovescertainaspects SatherwasinitiallybasedonEielandwasdevelopedtocorrectthepoorcomputationalperfor- oftheinitialversionandincorporatesanumberofnewlanguageconstructs. librariesandapplications.aparticularlydemandingapplicationistheextensibleicsiconnectionist networksimulator:icsim[24].theexamplesinthispaperaretakenfromtheactualcodeandstructure ofthesatherlibrariesandapplicationstomakethemrealistic.thedesigneortwascontinuallya Theinitial\0.1"releaseofthecompiler,debugger,classlibrary,anddevelopmentenvironmentwere balancebetweentheneedsofapplicationsandconstraintsonlanguagedesign,suchassimplicityand orthogonality. Thelanguagedesignprocesshasbeenintimatelycoupledwiththedesignandimplementationof Thispaperdescribesanumberoftheseissues.Wedonotdescribethewholelanguageherebutdo becomeincorrect. includetherelevantpartsofthegrammarinappendixa.thebulkofthepaperisdevotedtothe manylegalprogramsarerejected.addingnewclassestoasystemcancausepreviouslycorrectcodeto Thisisaconservativesystem-wideglobalcheck.Asystemwhichsatisesthecheckwillbetypesafebut Eielhasthesameproblem[5],andattemptstosolveitbyintroducingsystem-leveltype-checking[17]. thelanguagewerestronglytyped,butitwasnotpossibletostaticallycheckasystemfortypecorrectness. Sather1.0solvedthisandotherproblemsbycompletelyredesigningthetypeandclasssystem. OneofthemostfundamentalaspectsoftheSather1.0designisitstypesystem.Earlierversionsof object-orienteddispatch.italsodescribesthethreekindsofsatherobjects:referenceobjects,value functionswithinanobject-orientedcontext.section3describessomeofthesubtleissuesinvolvedin interplaybetweensubtypingandsubclassing.section2denestheseconceptsandmotivatesthedecision objects,andboundobjects.boundobjectsareaparticularlycleanwayofimplementinghigher-order codeinheritance.finally,section4describessomemoresystemlevelissues. 2SatherTypesandClasses toexplicitlyseparatetheminthelanguage.itdescribesthesatherversionofparameterizedclassesand Object-orientedterminologyisusedinavarietyofwaysintheprogramminglanguageliterature.Afew informaldenitionswillsuceforthepurposesofthispaper: ObjectsarethebuildingblocksofallSatherdatastructures.Objectsbothencapsulatestateand 2Thereissomeadditionalinformationinsignatureswhichareassociatedwithiterswhichwedonotdescribehere. 1Fromftp.icsi.berkeley.edu,directorypub/sather/ Atyperepresentsasetofobjects. Thesignatureofanoperationthatmaybeperformedonanobjectconsistsofitsname,apossibly supportaspeciedsetofoperations. emptytupleofitsargumenttypes,andanoptionalreturntype.sathersupportsbothroutines whichperformasingleoperationanditers[20]whichencapsulateiterationabstractions2. 1
Eachtypehasaninterfacewhichconsistsofthesignaturesoftheoperationsthatmaybeapplied TheSathertypegraphisadirectedacyclicgraphwhoseverticesaretypesandwhoseedgesdene Classesaretextualunitsthatdenetheinterfaceandimplementationoftypes. thesubtyperelationshipbetweenthem.wesaythatatypeaconformstoatypebifthereisa toobjectsofthetype.sathersupportsoverloadingwhichmeansthataninterfacemayhavemore directedpathfromatobinthetypegraph. presenceofareturntype. thanoneoperationwiththesamenameiftheydierinthenumberortypesofargumentsorinthe EveryobjectandeveryvariableinSatherhasauniquelyspeciedtype.ThefundamentalSathertyping 2.1SubtypingandMultipleSubtyping denedbyabstractclassesanddonotdirectlycorrespondtoobjects. ruleis:\avariablecanholdanobjectonlyiftheobject'stypeconformstothevariable'sdeclaredtype.". whichrepresentsetsofobjecttypesandarehowsatherdescribespolymorphism.abstracttypesare objectsitcanhold.wesaythatitisstaticallytype-safebecauseitisimpossibleforaprogramwhich compilestoassignanobjectofanincorrecttypetoavariable.thesathertypecorrectnesscheckingis canbedeclaredbyoneofthesetypes,butmayalsobedeclaredbyanabstracttype.thesearetypes signaturesintheinterfaceofthetypetowhichthecallisapplied.statically-checkedstrongtypingis purelylocalanddoesnotrequireasystem-wideanalysis.itisdonebycheckingcallsagainstthedeclared WesaythatSatherisstronglytypedbecauseeachvariablehasatypewhichspeciesexactlywhich Therearethreekindsofobjecttype:reference,value,andbound.Wedescribetheselater.Variables meansthatforeachsignatureinb'sinterfacethereisaconformingsignatureina'sinterface. typeaconformstothetypeb,thentheinterfaceofaisrequiredtoconformtotheinterfaceofb.this fundamentaltoachievingboththeperformanceandthesafetygoalsofsather. Typesafetyisensuredbecauseofaconformancerequirementontheinterfacesoftypes[3].Ifthe variable,thenitwillbetypecorrectwhenmadeonallpossibleobjectsthatmaybeheldbythatvariable. thisistypesafe3.allotherargumentsarecontravariantlytypedandthereturnvalueiscovariantlytyped. Together,theseconformancerequirementsensurethatifacallistypecorrectonthedeclaredtypeofa denedbytheclassthatimplementstheoperation. theroutine.withintheroutine,itisreferredtoasself.thetypeofself,denotedassame,isthetype ingtothetypeoftheobjectthecallismadeon.thisobjectmaybethoughtofastherstargumentof Satherallowsformultiplesubtyping:Atypecanbesubtypeofmorethanonetype.Thisisvery Underthesubtyperelation,theselfparameteriscovariantlytyped.Becauseofthedispatching, Object-orienteddispatchmeansthattheparticularimplementationforaroutinecallismadeaccord- oftenwantedtointroducemanyincrementallydierenttypes.ontheotherhand,hugetypehierarchies hierarchy,intermediateclassescanbeintroducedonlywhenneeded. anexistingclass.usingthisfacility,itispossibletointerposeanewtypebetweentwoexistingtypesina withmanysimilarclassesarehardtounderstandanduse.withtheabilitytoinsertnewtypesintoa hierarchy.thissolvesanolddilemmaofclasshierarchydesign.ontheonehand,forfutureexibilityone importantforusingsoftwaretypestomodeltypesintheworld.real-worldtypesareoftensubtypesof spurioussubtyperelationswhichcandestroytheconceptualintegrityofadesign. morethanonetype.inasystemwhichonlysupportssinglesubtyping,oneisoftenforcedtointroduce 2.2CodeInheritance,SubclassingandMultipleSubclassing AnewfeatureintroducedbySatheristhepossibilityforanewclasstodeclareitselfasasupertypeof Althoughoftenconfusedorcombinedwithsubtyping,anentirelydierentaspectofobject-oriented programmingiscodereusebymeansofcodeinheritance,alsocalledsubclassing.aclassaiscalleda sensediersfromtheuseoftraditionallibraryroutinesintwoimportantways.first,theinheritedcode subclassofaclassbifa'simplementationisbasedinpartonb'simplementation.codereuseinthis disadvantagesofmulti-methodsarediscussedinsection2.7.2 3ThelanguageCecil[4]usesmulti-methodstoallowmultiplecovariantlytypedparametersinatype-safeway.Some
hasdirectaccesstotheinternalrepresentationofthereusingclass.second,theinheritedcodemaymake callsonself.suchcallsmaycallotherinheritedoperationsoroperationsexplicitlydenedinthenew class.thisintricatetanglingofnewandoldcodeispowerfulbutcomplexity-prone[16]. Aswithsubtyping,Satherallowsmultiplesubclassing:Aclasscanbesubclassofmultipleclasses,i.e. itcanreuseportionsoftheimplementationsofmultipleclasses.multiplesubclassingintroducesmany complicationsthatrequirecarefulattention.mostlanguagescombinemultiplesubtypingwithmultiple subclassingintomultipleinheritance.thecomplexityintroducedbymultiplesubclassinghasgivenrise towidespreadambivalentfeelingsaboutmultipleinheritance.aparticularlytrickysituationariseswhen thesamecodeisinheritedbyaclassalongmultiplepaths.theresultingconictsandsather'sconict resolutionmechanismsaredescribedbelowinsection3. Onecouldimagineintroducingaconstructforcodeinheritancewhichisanalogoustothesupertyping constructdescribedabove(cf.section2.1).thiswouldbeaformof\codeinjection"inwhichclasses couldaddimplementationtootherclasses.thispossibilitywasrejectedinthesatherdesignbecause itgivesrisetomanyambiguitiesanderrorswhichwouldbehardtond.onewouldnolongerbeable todeterminethesourcecodeofaclassbymerelylookingattheclasstextandthoseclassesreachable fromreferencesinit.whenusingclassesfromanothersystem,itwouldnotbeclearwhichsource lescontributedcodetothedesiredclasses.also,becauseoftheseparationbetweensubclassingfrom subtyping,codecanbeinheritedintheoppositedirectionfromsubtypingifdesired. 2.3SeparatingSubtypingandSubclassing Traditionally,object-orientedlanguagesareeitheruntyped{e.g.Smalltalk[10]orSelf[27]{ortightly bindclassesandtypes{e.g.c++[8],eiel[17]modula-3[21],oroberon-2[19].(incontrasttooberon-2, Oberon[23]keepsthedispatchingofimplementationvariantsseparatefromsubtypingissues,essentially bynotprovidingmethodsatall.instead,oberonreliesentirelyonprocedurevariablestoimplement latebinding.nevertheless,oberonstilldoesnotcompletelyseparatesubtypingfromsubclassing,cf.section2.6.) Thedecisiontohavestatictypesafetycausedustorejecttheuntypedvariants.Giventhatthere willbetypes,onemustdecidehowtightabindingthereshouldbebetweensubtypingandsubclassing. Thetypedobject-orientedlanguagesmentionedabovebindthesenotionscloselytogether.Notseparating theseconceptsproperlyleadstoseveralproblems,however. Oneapproachrequiresthateverysubclassrelationshipobeystherulesoftype-safesubtyping.This leadstocontravarianttypingofroutinearguments.ithasbeenarguedthatthiseliminatesseveral importantopportunitiesforcodereuse[18,14]. Anotherapproachintroducessubclasseswhicharesubtypesbydeclarationbutnotintermsofthe interfacewhichissupported.thisapproachisadoptedasacompromiseinmanylanguages,including theoriginalversionofsatherandeiel[17].thisviolatestherequirementoflocaltypecheckability.in theoriginaleieldesignthiswasasafetyloop-hole[5].thelatestversionofeielrequires\system-level typechecking",whichgivesuponlocaltypecheckabilityandsometimesrejectsdynamicallytype-safe programs. Becauseoftheseproblems,[6]suggestedthatsubtypingshouldbeclearlyseparatedfromsubclassing. Emerald[11]isoneofthefewlanguagesthatactuallyimplementedthisseparation.InEmerald,however, theresultisasignicantburdenontheprogrammer.often,subtypingandsubclassingdogoalongin parallel,andemeraldrequiresseparatespecicationevenforthiscommoncase. Laterlanguagedesigns,suchasSather1.0andCecil[4],attempttoprovidemoreconvenientways tosupportthecommoncase.sincececilisbasedonprototypeobjects,quitesimilartoself,itscode inheritanceisnotbasedonclasses.still,cecil'scounterparttosubclassinghasthedefaultbehaviorof alsointroducingasubtype.thisbehaviorcanbeexplicitlyprevented,however,anditisevenpossibleto havecodeinheritanceandsubtypinggoinoppositedirections.satherfollowsasimilarpathofoptimizing thecommoncase.however,insteadofintroducingdefaults,satherintroducesspecialkindsofclasses andanexplicitmeanstoimplementsubclassingandsubtypinggraphsovertheseclasses. 3
Asdescribedabove,Satherdistinguishesbetweenabstractandconcretetypes(thenamesofabstracttypes aredistinguishedbyaleading\$"tohelpdistinguishthem).abstractclassescanhavedescendantsin thetypegraph,butcannotbeinstantiatedasobjects.concreteclassesarealwaysleaf-nodesinthe subtypegraph,butcanbeinstantiated.thisapproachissimilartothetypesystemformallydenedin [7].Abstractclassesmayprovidepartialimplementationstobeinheritedbysubclasses,whileconcrete 2.4SatherTypes,Classes,andVariables ofexactlythattypecanbeheldbyit.asaresult,allcallsonsuchvariablesaremonomorphisms,i.e. theactualimplementationinvokedisstaticallydetermined.thisisanimportantsourceofeciencyfor Satherprograms.Ifavariableisdeclaredbyanabstracttype,thenitcanholdobjectsbelongingtoany ofthesubtypesofthedeclaredtype.callsmadeonsuch\abstractvariables"arepolymorphisms.this meansthattheactualimplementationinvokedisdeterminedatrun-timeaccordingtothetypeofthe objectboundtothevariableatthetimeofthecall. classesarerequiredtofullyimplementtheirtype.sathercodeinheritanceisexplainedinsection3. AllSathervariablesarestaticallytyped.Ifavariableisdeclaredasaconcretetype,thenonlyobjects Multiplesubtypingisimportantinsituationswherethereisnotanobvioushierarchyofobjectproperties. IntheSatherlibrarysomecontainerclassesareinternallybasedonhashtables,othersarenot.Not 2.5ExamplesofSeparateSubtypingandSubclassing everyobjectdenesacorrespondinghashfunction,however.wemakeobjectswhichdoprovideahash functionbedescendantsoftheabstractclass$hashablewhoseinterfacedenesthesingleroutine\hash": serveforsubtypingpurposes.theimplementationoftherequiredfeaturesislefttothedescendants. inaparameterized,hashtable-basedsetclass(cf.section2.8.infigure1,aswellasintheother Figure1showsatypicalinheritancegraphfordeninganelementclasstobeusedasatypeparameter abstractclass$hashableis thatworksforalltypes.abstractclasseswithoutimplementationinformation,suchas$hashable,only endhash:int; Notethat$HASHABLEdoesn'tprovideanimplementationofhash,becausethereisnogenerichashfunction namessetinaplaintypefacedenoteabstracttypesandthoseinaboldtypefacedenoteconcretetypes. inheritancegraphs,solidanddashedarcsareusedtorepresentsubtypeandsubclassrelationships.class usesthisstyletolettheusercongurethepropertiesofneuronsites.sitesaresubsetsofaneuron's therearesituationswhereapplicationprogrammersprefertousemultiplesubclassing.itisusedin MultiplesubclassingismuchlesscommoninSatherprogramsthanmultiplesubtyping.Nevertheless, connectionswithidenticalproperties.siteshaveconnection-orientedpropertiesrepresentedby$port descendantsandcomputation-orientedpropertiesrepresentedby$computationdescendants.$siteisa themixinprogrammingstyleusedextensivelyinclos[2].icsim,theicsineuralnetworksimulator, Figure1:Typicalinheritancegraphfor$HASHABLE subtypeofboth$portand$computation. alsosubtypesof$anyicsim.theserelationshipsareshownintheinheritancegraphinfigure2.itis classesthatprovidebuildingblocksforconnectionandcomputationcode.alltypesusedinicsimare Typically,ICSIMusersdonotprogramtheirownsites,butinsteadchoosethemfrombuilt-in 4 $HASHABLE $MY_ELEMENT $SET{T} (cf.section2.3).my_hashable_element HASH_SET{MY_HASHABLE_ELEMENT}
interestingtonotethatthemysiteclassusesmultiplesubclassingbutsinglesubtyping(theoppositeof theusualcase). languages.inparticular,routinesdierfrompascal-likeproceduresbyhavinganadditionalimplicit parameterboundtotheobjectthattheroutineiscalledon. eldsinpascal-likelanguages.routinesaretheequivalentof\methods"insomeotherobject-oriented 2.6FeaturesofaClass ThefeaturesofaSatherclassareeitherattributes,routines,oriters4.Attributesaretheanalogofrecord Figure2:MultipleSubclassingforProgrammingbyConguration \x.a"inclientsoftheclass. oftypeandstructuredenitioninpascal-likelanguages,includingoberon.itisusedinsomeearlier elds.thepricetopayfordoingsoisthelossoftheintuitiveandlightweightattributeaccessnotation mayjustprovideaccessorandmodierroutines.thisisadeparturefromthetraditionalcoincidence bynotintroducingpublicattributes,as,forexample,canbedoneinoberonbynotexportingrecord object-orientedlanguages,however,suchasself.onemightarguethatthesameeectcanbeachieved interfaceofatype.oneconcretedescendantofanabstractclassmaydeneanattributewhileanother Attributesmaybedeclaredtobesharedamongallinstancesofatype.Suchsharedattributes Whetheraparticularoperationisimplementedasanattributeorasaroutineisnotvisiblefromthe servethefunctionofglobalvariables(andtheratherdiculttouse\oncefunctions"ofeiel).shared maybedeclaredconstant,inwhichcasethebindingestablishedbytheinitializerispermanent. attributesmayspecifyaninitializationexpressionthatisevaluableatcompile-time.similarattributes Variablesdeclaredbyanabstracttypecanholdobjectsofanydescendanttype.Routinecallsmade fromwithincodeexternaltotheclass. 2.7Object-OrientedDispatch onsuchvariablesdispatchontheruntimetypeoftheobjecttodeterminethecodetoexecute.this accessthem,andonlyrelativetoself.forattributes,itispossibletodeclaretheaccessorandmodier routinesindividuallyasprivateorpublic.thisallowsattributestoberead-write,read-only,orinvisible ThefeaturesofaSatherclassmaybedeclaredprivate,allowingonlytheroutineswithintheclassto responsiblefortheencapsulationoffunctionalityintotypes.theinterfaceofatypeencapsulatesthe oraconcretetype,theprogrammermaydecidetopaythepriceforroutinedispatchortorestrictthe intoclassesaccordingtothetypeof\self".thisprovidesanaturalorganizationprincipleandis lookupaddsasmallamountofextraoverheadtosuchcalls.bydeclaringavariablewithanabstract doesnotadoptthisapproachforbothsemanticandperformancereasons.insatherroutinesaregrouped generalityofthecodebypreciselyspecifyingtheobjecttypethatthevariablecanhold. 4Wedonotdescribeitersherebecauseitwouldtakeustoofaraeldandtheyhavebeendescribedelsewhere[20]. Somelanguagessupport\multi-methods"whichcandispatchonalltheargumentsofacall.Sather 5 $PORT $ANY_ICSIM VECTOR_PORT UNIT_LIST_PORT VIRTUAL_PORT $SITE BP_LEARNING QP_LEARNING MY_SITE $COMPUTATION
argumenttype.unlikeasimple\case"statementappliedtothetype,a\typecase"statementcan type.satherdealswithmulti-methodsituationsbyusing\typecase"statements.theseappearinthe abstractiondenedbythattype.withmulti-methodscodedoesnotnaturallybelongtoaparticular bodyofaroutinewhichdispatchesontherstargumenttypeandmayexplicitlydispatchonthesecond branchonabstracttypes.thismeanstheycanbeusedinthesamesituationsthatmulti-methodswould behelpful.thisapproachalsomakestheperformanceconsequencesofamulti-methodorganization explicitratherthanhidingitbehindacomplexlanguageconstruct. onanunboundvariableofconcretetype(self=void).direct-calledroutinesaresather'sversionof plainproceduresinpascal,classmethodsinsmalltalk,andstaticmemberfunctionsinc++. Satherallowsthedenitionofafamilyofclassesparameterizedbytypes.Thisisasimilarmechanismto 2.8ParameterizedClasses Satherroutinescanalsobecalleddirectly.Adirectcallisequivalenttodispatchingtheroutinecall anappropriatesupertype. suchconstraints.aconstrainttyperepresentinganarbitraryunionoftypescanbeintroducedbyforming inheritedcode.satherallowssuchtypestobedeclaredassame,similartoeiel'slike-current.if aclassainheritscodewhichreferstothetypesame,itbehavesasifthetypewerereplacedbya.for oftheseconstrainttypes.thesupertypingfeatureintroducedinsection2.1isquiteusefulfordening haveassociatedtypeconstraints.thevaluesspeciedforthetypeparametersarerequiredtobesubtypes thegenericpackagesofada[28]andtemplatesinthenewerversionsofc++.sathertypeparameters Section2.1.ThisisverydierentfromEiel'slike-current,whereasubclassformedinthiswayis asubclasstobealsoasubtype,however,thisreplacementhastofollowthesubtypingrulesstatedin automaticallyconsideredasubtype,eventhoughitmightwellhaveintroducedaconformanceconict. AsecondformofgenericityinSatherisrelatedtothetypingofargumentsandreturnvaluesin undertwonames).morepureobject-orientedlanguagessuchassmalltalkandselftrytounifythese Thesearealwayspassedbyvalueanditisnotpossibletoaliasthem(i.e.toreferencethesameobject objects.thesearepassedbyreferenceasroutineargumentsandmaybealiased.thefundamentaltypes representingbooleanvalues,integers,characters,oatingpointvalues,etc.arecalledvalueobjects. Satherdistinguishesbetweenreference,value,andboundobjects.Mostuser-denedobjectsarereference 2.9ReferenceandValueClasses notions. Avariableofabstracttypecanbeusedtostoreeithervalueorreferenceobjects. objectshaveanidentityandthestateofareferenceobjectcanbemodiedbywritingtoitsattributes. Oncecreatedtheyneverchange,andthereisnosuchthingasa\reference"toavalueobject.Reference side-eects. ideaofanobjectidentityboundtoamodiablestateintroducesreferentialopaquenessandallowsfor hand,referenceobjectsarebestusedtomodelentitiesthathaveanidentityplusacurrentstate.the denedonlyovervaluetypesareside-eectfreeandthereforereferentiallytransparent.ontheother Satherdistinguishesbetweentheseattheleveloftypes.Instancesofvaluetypeshavevaluesemantics: Languagesthatonlyoperateovervaluesaretypicallycalledfunctionallanguages,andoperations thiscopyingwheneveritcandeducethattheinvokedoperationcannotmodifytheobject. operationisinvokedonthecopy(callbyvaluesemantics).ofcourse,thecompilerisfreetoeliminate conicts.logically,whenvalueobjectsarepassedasarguments,theirvalueisrstcopiedandthenthe techniques.mostimportant,avalueobjectcanbecopiedfreelywithoutthepossibilityofaliasing otherreferenceclasses. Anabstractclasscanonlybeasubclassofotherabstractclasses;avalueclasscanonlybeasubclassof abstractclassesandothervalueclasses;areferenceclasscanonlybeasubclassofabstractclassesand Thespecialpropertiesofvalueobjectsmakethemespeciallyamenabletocompileroptimization Theintroductionofseparatevalueandreferenceclassesimposescertainrestrictionsonsubclassing: 6
2.10BoundRoutines Acontroversialfeatureofnon-functionalprogramminglanguagesareclosuresorhigher-orderfunctions. Whileexpressiveandpowerful,certainformulationsarediculttoimplementeciently.Hence,many non-functionalprogramminglanguagesprovidemorelightweightbutmuchlesspowerfulfacilities. Pascal[12]introducedprocedureparameters,butnoprocedurevariables.Thisallowedimplementationstostrictlyadheretoastackdiscipline,butpreventedtheuseofproceduresasrst-classvaluesin datastructures.inmodula-2[29]thiswaschangedtoallowforprocedurevariables,buttherestriction wasaddedthatonlyglobalprocedurescanbeassigned.c[13]hasfunctionpointerswithasimilar semantics.whilethisallowsrst-classprocedurevalues,itrestrictssuchprocedurestooperateonthe globalstateonly,whileinpascalitwaspossibletopassanestedprocedurethatinturncouldoperate onthecurrentbindingsoflocalvariablesofthepassingprocedure. Sather,asinC,hasnonestedroutines,hencetheC/Modula-2solutionwouldworkwithoutany constraints.however,theconstraintthatroutinesboundtoavariablecanonlyoperateontheglobal stateismuchweakerthanmanyapplicationsneed.forexample,toimplementaroutinewhichproduces thecomplementofabooleanargumentroutineorthecompositionoftwoargumentroutinestheremust beinternalstateassociatedwiththeroutine. TheSathersolutionistointroduceboundroutines5toexpresshigher-orderfunctionsandclosure-like constructs.thekeyideaisthattheparametersofaroutine,includingtheimplicitself,canbebound toobjects.theresultingboundroutinecanthenbeassignedtoaroutinevariableoftheappropriate type.forexample,itispossibletotakearoutinewithtwointegerparameters,bindoneofthesetoan integervalue,andthenassigntheresultingboundroutinetoavariablethatasksforaroutinewitha singleintegerparameter.boundtypesdescribetheresultingsignatureofaboundroutine.conformance isdenedascontravariantconformanceofthetypesignature. 3CodeInheritance 3.1TheTextualInclusionModelforCodeInheritance ThesemanticsofcodeinheritanceinSatherisdenedbytextualinclusionoftheinheritedcode.So-called \include"clausesareusedtoincorporatesourcecodefromaspeciedclass.thechoiceofthekeyword \include"wasmadetoindicatethetextualsemanticsfortheinheritancemodel.referencestothe type\same"intheinheritedcoderepresentthetypeoftheinheritingclass.newlydenedfeaturesina classoverrideinheritedfeatureswithaconformingsignature(asdenedinsection2.1).thisapproach diersfromthatusedinsmalltalkandmostotherobject-orientedlanguages,inwhichacallconceptually climbsupintheclasshierarchyuntilacorrespondingmethodisfound.formostcommoncases,the twoapproachesproduceidenticalresults.incomplexsituations,however,thetextualinclusionapproach seemseasiertounderstandandtoreasonabout. Itissometimesconvenientforanewversionofafeaturetocalltheoldversionthatitoverrides. Smalltalksolvesthisproblembyprovidingthe\super"-call,whichbypassesanymatchingimplementationsintheobject'sclassandpassesthecalldirectlytothesuperclass.WefoundthatinSather,this approachwouldbeconfusingincertaincircumstances.theproblemariseswhencodewhichmakesa supercallisitselfinherited.theambiguityforprogrammerswaswhethertheinherited\super"call referstothe\super"classoftheoriginaldeningclassoroftheinheritingclass. Toeliminatethisproblem,Satherreplacesthe\super"-callapproachwithageneral\renaming" facilityintheincludeclauseswhichdenecodeinheritance.theincludeclausecomesintwoforms: oneisusedtoincludeandpossiblyrenameasinglefeaturefromanotherclassandtheotherincludes anentireclassbutmaycausefeaturestobeundenedorrenamed.renamingisshallow,i.e.renamingaectsonlythedenitionofthespeciedfeaturebutnotcallsonthatfeature6.appendixa.10 includesthesyntaxoftheconstruct.figure3usestheexampleofextendingasimpleunit(neuron) inicsimtoaunitwithback-propagationlearningtoshowhowthe\super"-callproblemissolvedin 5Satheralsointroducesbounditers. 6Thus,renamingorundeningafeaturemaybreakinheritedcode.Ifthisisthecasethecompilersignalsa\subclassing error"associatedwiththecorrespondingincludeclause.7
\SIMPLEUNITaccumulatedinput"inSIMPLEBPUNIT. Sather.TheroutineaccumulatedinputinheritedfromSIMPLEUNITisrenamedastheprivateroutine: classsimple_unitis end; classsimple_bp_unitis accumulated_input:realis end; includesimple_unit res:=input_values.dot_v(weights) input_port.get_outputs_into_vec(input_values); --Computethedotproductofinputvalues*weights end accumulated_input:realis end;... accumulated_input->privatesimple_unit_accumulated_input...; --Computethedotproductofweights*inputs+thebiasvalue res:=simple_unit_accumulated_input+bias.val Ourexperienceshowsthatweusethisstyleofprogramminginfrequently,andifweneeditwemake approach. therenamedversionoftheoldroutineprivateinordernottoaecttheexternalinterfaceofaclass. Becauseeveryroutinehasaspeciedname,theapproacheliminatesanyambiguityintheinterpretation ofcode.asshowninthenextsection,therenamingapproachisalsomoregeneralthanthe\super"-call Onemayarguethattherenamingsolutionfor\super"-callsunnecessarilycluttersthenamespace. Figure3:Usingrenaminginsteadofa\super"-call. class.sincemorethanoneofthesuperclassesmayprovideafeaturewiththesamesignature,multiple Sathersupportsmultiplesubclassing(multiplecodeinheritance)byallowingmultipleincludeclausesper 3.2MultipleSubclassingandConictResolution subclassingleadstoinheritanceconicts.tworoutinesoritersaresaidtoconictiftheyhavethesame name,thesamenumberandtypesofarguments,andbotheitherhaveordonothaveareturnvalue. Reference[9]describesfourwaystocopewithinheritanceconicts: 2.Resolveconictsbyexplicitselection:Requiretheusertomakeaselectionincaseofaconict. 1.Disallowconicts:Signalanerrorinthecaseofaconict. 3.Formdisjointunionoffeatures:Createaseparatefeatureforeachconictingfeature.Thisisthe approachofc++wherefeaturenamesofsub-andsuperclassesareindierentscopes.theuser ThisisSather'sapproach,asdescribedbelow. atestancebetween3.and4.byimposingonlyapartialorderingonclasses,andrequiringanyremaining 4.Formcompositeunionoffeatures:Createonesinglefeatureforeachconictingfeaturebyalgorithmicallyresolvingtheconict.CLOS[1]followsthisapproachbylinearizingtheclasshierarchy. 1.to3.areexplicitconictresolutionmethods,4.isanimplicitmethod.Cecil[4]takesanintermedi- selectsbetweenconictingfeaturesusingthescoperesolutionoperator\::". 8
conictstoberesolvedexplicitlybytheprogrammer.weagreewith[25]thatclos-stylelinearization oftheinheritancegraphsmayleadtounexpectedmethodlookups,andresultinfaultyandhardtodebug programs. Sather,therefore,adoptsanexplicitconictresolutionschemeinwhichtheprogrammerhasto explicitlychooseincaseofconicts.aclassmaynotexplicitlydenetwoconictingroutinesoriters. Aclassmaynotdenearoutinewhichconictswiththereaderorwriterroutineofanyofitsattributes (whetherexplicitlydenedorincludedfromotherclasses).ifaroutineoriterisexplicitlydenedina class,itoverridesallconictingroutinesoritersfromincludedclasses.thereaderandwriterroutines ofaclass'sattributesalsooverrideanyincludedroutinesandmustnotconictwitheachother.ifan includedroutineoriterisnotoverridden,thenitmustnotconictwithanotherincludedroutineoriter. Renamingorundeninginincludeclausesisusedtoresolvetheseconicts. Anylanguagewhichsupportscodeinheritancemustdealwiththeproblemofthesamecodeinherited alongtwodierentpaths.somelanguagesintroducecomplexmechanismstodealwiththiscase,butthese tendtobeconfusingtoprogrammersandrarelydoexactlywhatisdesired.sather'ssolutionisimplied bytherulesgivenabove.satherdoesnotconsidertheoriginofcodeandresolvesinheritancesolelybased onthebodyoftheclassitselfandthebodiesoftheclassesitincludes(aftertheirowncodeinheritance hasbeenresolved).thisbehaveslikethenon-virtualinheritanceofc++fordiamond-shapedinheritance graphs,i.e.featuresfromacommonsuperclassareincludedalongeachedge.thissometimesnecessitates explicitlychoosingasingleversionofaroutineinheritedalongmultiplepaths,butiteliminatescomplex ruleswhichdependonthestructureofthecodeinheritancegraph. OurexperiencewiththeSatherlibrariesisthatweusemultiplesubclassingonlyrarely.Wetherefore feltthatthesespecialcasesweretooweakajusticationtointroduceacomplexgraph-basedsubclassing schemeorastrategybasedonstructuralequalityoffeaturedenitions. 3.3SeparateCompilation Satherhasnoexplicitnotionofstructuralunitscomprisingmultipleclasses.TheSatherprogramming environmentisintendedtomanageandmaintainthesourcecodeofmultipleclasses.inparticular,when compilinganewclassitisoftenrequiredthatthesathercompilerhasaccesstothesourcecode(orat leastthetypeinterfaceanddependencyinformation)ofallclassesreferredtobyit. Forexample,thecompilerautomaticallyinlinesshortroutinestoimproveeciency.Theretendto bemanyshortroutinesinobject-orientedprogrammingbecausearoutinewhichisneededonlyforthe purposesofanabstractinterfaceoftenjustcallsanotherroutine.inadditiontoeliminatinganextra routinecall,inliningallowsmuchmoreoptimizationtobedonewithinaroutinewithinlinedcode.onthe onehand,compiler-controlledinliningrequiresthatthecodetobeinlinedisavailabletothecompilerand tothecompiler'sanalysisprocess,i.e.thatthesourceisathand.ontheotherhand,inliningintroduces hiddendependenciesbetweenimplementations. Forlargesystems,thereareargumentsforintroducinganotherlevelofmodularity.Insomecases, onedoesn'twanttorequirethatallsourcecodebeavailableorallowarbitrarydependenciesbetween compiledunits.suchlargesystemsareusuallycomposedofsubsystems.foralimitedsubsystemthe globalanalysisisacceptable.foracomposedsystem,however,itshouldbepossibletodenethe subsystemsinawaythatglobalanalysisisnotrequired. ForSather,itispossibletoformsubsystemswithstrictboundariesintermsofcompileranalysis. Suchasubsystemmustbelimitedbyaninterfacepresentingonlytypes,i.e.emptyabstractclasses,to subtypingclients,andallowingfordirectcallstoroutines(c.f.section2.7)denedbyclasseswithinthe subsystem. Themostprominentmechanismthatcannotbeallowedtocrosssubsystemsiscodeinheritance, whichofcourseisadirectconsequenceofspecifyingthesemanticsofcodeinheritancebaseduponthe actuallyinheritedsourcetext.alsotobeexcludedfromasubsystem'sinterfaceareparameterizedclasses: ThecurrentSathercompilercannotcompletelycheckaparameterizedclassbeforeitsparametersactually getspecied.thisdefectinthecheckabilityofsather'sparameterizedclassesisunfortunateandanissue ofongoingresearch.however,thisproblemisnotspecictosather,thesameholdsforc++,where sucherrorsmightbedetectedaslateasatlink-time(!),eiel,andada.possiblesolutionstendto eitherrestricttheusefulnessofparameterizedclasses,ortointroduceacomplicatedapparatustospecify 9
sucientlystrongboundsontheparameters. tensiontosather.inparticular,amoduleconstructwouldhelptopackagehelperclasses,toexplicitly 4Foundations limitationstobeplacedandhowmuchofasourceneedstoberevealedforpurposesofcompilation.the theseissuesatthelevelofthedevelopmentenvironmentratherthaninthelanguage. treatsubsysteminvariants,toreducetheprobabilityofconictsintheglobalclassnamespace,andallow bestformforsuchaconstructisnotyetclear,however,andsothecurrentversionofsatherwilladdress Explicitsupportforexpressingsubsystemboundaries,suchasmodules[26],mightbeausefulex- Thetypesystemdescribedsofarneedstobegroundedinexplicitbuilt-inclasses.Aclasscandono world.forexample,asatherprogramshouldbeabletocallnon-satherlibraries,includingfunctionsof theunderlyingoperatingsystemandgraphicaluserinterface.itisnotreasonabletoexpectthataxed oroperationswithpredenedsemantics.insather,certainpredenedclassesservethispurpose. morethandeneattributesoftypesintroducedbyitselforotherclasses,ordeneroutinesoperating overitsownorsharedattributes,orinvokingotheroperations.whatismissingarethefoundational entitiestostartwith.suchfoundationentitiesarepresentinalllanguages7intheformofbuilt-intypes MostclassesaredenedbyexplicitcodeinaSatherprogram,butthereareseveralclasseswhichare 4.1Built-inClasses hasexternalclasses.predenedandexternalclassesaredescribedinthenexttwosubsections. setofbuilt-inclasseswilleversucetoservethispurposeinfullgenerality.forthesepurposessather Alanguagethatclaimstobe\general-purpose"alsohastobeabletoexpressinterfacestotheoutside denedinanimplementationdependentway.ineachcase,thechoicesmadebytheimplementationare automaticallyconstructedbythecompiler.theseclasseshavecertainbuilt-infeaturesthatmaybe describedbyconstantswhichmaybeaccessedbyaprogram.thissectionprovidesashortdescriptionof someofthemostimportantbuilt-inclasses.thecompleteanddetailedsemanticsandpreciseinterface isspeciedinthesatherclasslibrarydocumentation. BOOLdenesvalueobjectswhichrepresentbooleanvalues. CHARdenesvalueobjectswhichrepresentcharacters. STRdenesreferenceobjectswhichrepresentstrings. INTdenesvalueobjectswhichrepresentmachine-dependentintegers.Thesizeisimplementation $OBisautomaticallyanancestorofeveryclass.Variablesdeclaredbythistypemayholdanyobject. INTINFdenesreferenceobjectswhichrepresentinniteprecisionintegers.Theysupportarithmetic FLT,FLTD,FLTE,andFLTDEdenevalueobjectswhichrepresentoatingpointvaluesaccordingto operationsbutdonotsupportbitoperations. thesingle,double,extended,anddoubleextendedrepresentationsdenedbytheieee-754-1985 dependent.classesrepresentingxed-sizedintegerswithadierentnumberbitsmaybedenedby inheritingfromintandredeningtheconstant\bsize".alltheroutinesworkwithanarbitrary problems,though! 7Intheory,the-calculus,e.g.withsyntaxE::=xjEEjx:E,issucient.Suchlanguagestendtohaveeciency ARR{T}isareferenceclassdeningdynamically-sizedarraysofelementsoftypeT.Classeswhich TYPEdenesthevalueobjectsreturnedbythetyperoutine. standard. inheritfromthisarecalledarrayclasses.theyallocatespaceforthearrayandtheattribute asize:intwhosevalueisthenumberofelementsinthearray. 10
Sather'sexternalclassescanbeusedtointerfacewithcodefromotherlanguages.Externalclassesare Satherprovidesafewspecialbuilt-inclassestointerfacetoexternalcode,aslistedbelow.Additionally, 4.2InterfacingtoExternalCode externalclasses).theexternalobjectlemustprovideaconformingfunctiondenitionwiththesame theseexternalroutinesusingaclasscallexpressionoftheformext_class::ext_rout(5).similarly, nameaseachroutinewhichdoesn'thaveanimplementationintheexternalclass.sathercodemaycall subtyperelationshipwithanyotherclass.itismerelyforthesakeofuniformityofthelanguagethat externalroutineinterfacesaregroupedintoexternal\classes". notclassesinthetraditionalsense.theycanneitherbeinstantiated,norcantheybeinasubclassor Fortran.Externalclassesmayonlycontainroutineswithdistinctnames(overloadingisnotallowedin theexternalcodemaycalloneofthenon-abstractsatherroutines8denedintheclassbyusinganame consistingoftheclassname,anunderscore,andtheroutinename(eg.ext_class_sather_rout). BITSmaybeinheritedbyvalueclasseswhichrepresentasingleeldofdata.Thedescendantmay EachexternalclassistypicallyassociatedwithanobjectlecompiledfromalanguagelikeCor 5Conclusions $EXTOBisusedtoreferto\foreignpointers".Thesemightbeused,forexample,toholdreferences whichdisallowarithmeticoperations.theymaybepassedtoexternalroutines. itsalignmentrequirements. tocstructures.suchpointersareneverfollowedbysatherandaretreatedessentiallyasintegers denethetwoconstantsbsize:intandbalign:inttospecifythesizeinbitsoftheobjectand ThedesignofSather1.0involvedtradingoaninterestingsetofconstraintsregardingeciency,clarity, reusabilityandsafety.wehavedescribedseveralimportantaspectsofthetypeandclasssystemand relevanttothetopicsdiscussedinthispaper. tunen,chu-cheowlim,heinzschmidt,anddavidstoutamiremadesuggestionswhichwereespecially comparedthemwiththesolutionschosenbyotherobject-orientedlanguages.thesegiverisetoalanguage ManypeoplewereinvolvedintheSather1.0designdiscussions.JerryFeldman,BenGomes,AriHut- withauniquecombinationofconceptualclarity,safetyandsupportforhighperformance. ASyntaxoftheSatherClassandTypeSystem Acknowledgements followclauseswhichmayappearzeroormoretimes,anditalicplussigns\:::+"followclauseswhich grammarrules.thegrammarrulesarepresentedinavariantofbackus-naurform.non-terminal \[:::]"encloseoptionalclauses,verticalbars\:::j:::"separatealternatives,italicasterisks\:::*" mayappearoneormoretimes. symbolsarerepresentedbystringsoflettersandunderscoresinitalictypefaceandbeginwithaletter. typesetinthetypewriterfont.italicparentheses\(:::)"areusedforgrouping,italicsquarebrackets ThefollowingsectionsgiveexamplesofactualSathercodefragmentstogetherwiththecorresponding A.1Classdenitionlists Thenonterminalsymbolonthelefthandsideofagrammarruleisfollowedbyanarrow\)"and classais...end;classbis...end right-handsideoftherule.theterminalsymbolsconsistofsatherkeywordsandspecialsymbolsandare classdeflist)[classdef]jclassdeflist;[classdef] 8Thecallingconventionsandthelayoutofobjectsaredescribedintheimplementationmanualofindividualversions. 11
A.2Classdenitions classinheritance)[<typespec(,typespec)*] paramdec)ident[<typespec][:=typespec] classa{s,t:=int,u<b}is...end valueclassb<$c,$dis...end classdef)[valuejabstractjexternal]classclassname abstractclass$e>g,his...end A.3Typespeciers [>typespec(,typespec)*] [{paramdec(,paramdec)*}]classinheritanceisclasseltlistend A{B,C{$D}} ROUT{A,B,C}:D ITER{A,B!,C} typespec)[classname][{typespeclist}]j typespeclist)typespec(,typespec)* classeltlist)[classelt]jclasseltlist;[classelt] A.4Features ITER[{typespec[!](,typespec[!])*}][:typespec] ROUT[{typespeclist}][:typespec]j classelt)constdefjshareddefjattrdefjroutdefjiterdefjincludeclause A.5Constantattributedenitions identlist)ident(,ident)* constr:flt:=45.6 privatesharedi,j:int privateconsta,b,c readonlysharedc:char:='x' shareds:str:="name" constdef)[private]constident(:typespec:=exprj[:=expr][,identlist]) shareddef)[privatejreadonly]shared A.6Sharedattributedenitions attrdef)[privatejreadonly]attr attra,b,c:int privateattrc:char:='a' readonlyattrs:str:="astring" A.7Objectattributedenitions (ident:typespec:=exprjidentlist:typespec) (ident:typespec:=exprjidentlist:typespec) 12
a(flt):fltprearg>1.2postres<4.3is...end A.8Routinedenitions privated:intis...end bis...end A.9Iterdenitions elts!(i:int,x:flt!):tis...end argdec)[identlist:]typespec c(s1,s2,s3:str) iterdef)[private]itername[(iterargdec(,iterargdec)*)][:typespec] routdef)[private]ident[(argdec(,argdec)*)][:typespec][preexpr][postexpr][isstmtlist end] iterargdec)[identlist:]typespec[!] privateincludede:str->readonlyf; includeaa:int->b,c(int)->,d:flt->privated; itername)ident! A.10includeclauses [preexpr][postexpr][isstmtlistend] References eltmod)ident[(typespeclist)][:typespec]-> includea::a(int)->b; includeclause)includetypespec::eltmodj [1]D.G.Bobrow,L.G.DeMichiel,R.P.Gabriel,S.Keene,G.Kiczales,andD.A.Moon.Thecommon [[privatejreadonly]ident] [private]includetypespec[eltmod(,eltmod)*] [3]LucaCardelli.Typefulprogramming.Technicalreport,DECSystemsResearchCenter,PaloAlto, [2]GiladBrachaandWilliamR.Cook.Mixin-basedinheritance.InProceedingsoftheConference Notices,25:10,Oct.1990. OrientedProgramming(OOPSLA/ECOOP'90),Ottawa,Canada,October1990.AlsoinSIGPLAN onobject-orientedprogramming,systems,andapplicationsandeuropeanconferanceonobject- ofsigplannotices23(sep.1988)andlispandsymboliccomputation(jan.1989). lispobjectsystemspecication.technicalreport88-002r,x3j13,june1988.alsoinspecialissue [4]CraigChambers.TheCecillanguage-specicationandrationale.TechnicalReport93-03-05, CA,May1989. [6]WilliamR.Cook,WalterL.Hill,andPeterS.Canning.Inheritanceisnotsubtyping.InProceedings [5]WilliamR.Cook.Aproposalformakingeieltypesafe.InProceedingsoftheThirdEuropeanConferenceonObject-OrientedProgramming(ECOOP'89),pages57{70,Nottingham,England,1989. DepartmentofComputerScience,UniversityofWashington,Seattle,WA,March1993. oftheacmconferenceonprinciplesofprogramminglanguages(popl'90),pages125{135.acm CambridgeUniversityPress. Press.Addison-Wesley,1990. 13
[9]RichardP.Gabriel,JonLWhite,andDanielG.Bobrow.CLOS:Integratingobject-orientedand [8]MargaretA.EllisandBjarneStroustrup.TheAnnotatedC++ReferenceManual.Addison-Wesley, [7]MaheshDodaniandChung-SinTsai.ACTS:Atypesystemforobject-orientedprogrammingbased 1990. Programming(ECOOP'92),pages309{328,Utrecht,Netherlands,1992. onabstractandconcreteclasses.inproceedingsofthesixtheuropeanconferenceonobject-oriented [11]NormanHutchinson.Emerald:AnObject-OrientedLanguageforDistributedProgramming.PhD [12]KathleenJensenandNiklausWirth.PASCAL:UserManualandReport.Springer-Verlag,2ded. [10]AdeleGoldbergandDavidRobson.Smalltalk-80,TheLanguageanditsImplementation.Addison- thesis,departmentofcomputerscienceandengineering,universityofwashington,seattle,wa, Wesley,1985. January1987. functionalprogramming.communicationsoftheacm,34(9):29{38,september1991. [14]B.B.Kristensen,O.L.Madsen,B.Moeller-Pedersen,andKristenNygaard.TheBETAprogramminglanguage.InB.D.ShriverandP.Wegner,editors,ResearchDirectionsinObject-Oriented ReportTR-91-034,InternationalComputerScienceInstitute,May1991. Programming.MITPress,1987. corr.printedition,1978. [15]Chu-CheowLimandAndreasStolcke.Satherlanguagedesignandperformanceevaluation.Technical [13]BrianW.KernighanandDennisM.Ritchie.TheCProgrammingLanguage.Prentice-Hall,1978. [16]BorisMagnusson.Codereuseconsideredharmful.JournalofObjectOrientedProgramming,4(3), [18]BertrandMeyer.Object-orientedSoftwareConstruction.Prentice-Hall,1988. [17]BertrandMeyer.Eiel-TheLanguage.Prentice-Hall,1988. [19]HanspeterMossenbockandNiklausWirth.TheprogramminglanguageOberon-2.StructuredProgramming,12(4),1991. [20]StephanMurer,StephenOmohundro,andClemensA.Szyperski.Satheriters:Object-oriented November1991. [22]StephenOmohundro.Satherprovidesnonproprietaryaccesstoobject-orientedprogramming.ComputersinPhysics,6(5):444{449,1992. Addison-Wesley,1992. [21]GregNelson,editor.SystemsProgrammingwithModula-3.PrenticeHall,1991. iterationabstraction.technicalreporttr-92-xxx,internationalcomputerscienceinstitute,1993. [23]MartinReiserandNiklausWirth.ProgramminginOberon.StepsBeyondPascalandModula. [24]HeinzW.SchmidtandBenedictGomes.ICSIM:Anobject-orientedconnectionistsimulator.TechnicalReportTR-91-048,InternationalComputerScienceInstitute,November1991. [26]ClemensA.Szyperski.ImportisnotInheritance{whyweneedboth:ModulesandClasses.InProceedingsoftheSixthEuropeanConferenceonObject-OrientedProgramming(ECOOP'92),Utrecht, [25]AlanSnyder.EncapsulationandInheritanceinobject-orientedprogramminglanguages.InPro- (OOPSLA'86),pages38{45,Portland,OR,November1986.AlsoinSIGPLANNotices,21:11,Nov. TheNetherlands,June1992. ceedingsofthefirstacmconferenceonobject-orientedprogramming,systems,andapplications 14
[28]U.S.DepartmentofDefence.AdaReferenceManual:ProposedStandardDocument,July1980. [27]DavidUngarandRandallB.Smith.Self:Thepowerofsimplicity.InProceedingsoftheSecondACM [29]NiklausWirth.ProgramminginModula-2.Springer-Verlag,1982. ConferenceonObject-OrientedProgramming,Systems,andApplications(OOPSLA'87),Orlando, FL,October1987.AlsoinSIGPLANNotices,22:12,Dec.1987. 15