Abstract Oncewerelaxtheassumptionthatitmustbepossibletospecifyprogramssolelyintermsof Fax:

Transcription

1 inanintegratedsoftwaredevelopmentenvironment Exploringtheroleoftheprogramminglanguage KeithJ.Ransom&ChrisD.Marlin, TheFlindersUniversityofSouthAustralia, DisciplineofComputerScience, Adelaide,SouthAustralia (PositionPaper) textandentertheminisolationfromothertools,therangeofpossibleprogramdevelopmentmechanismsissignicantlyincreased.thus,inthelightofadvancesintheeldofintegratedsoftware Abstract Oncewerelaxtheassumptionthatitmustbepossibletospecifyprogramssolelyintermsof Fax: reconsiderthewayweperceive(and,hencedesign)programminglanguages.thispaperdescribes developmentenvironmentsandinviewofthewideravailabilityofsuitableworkstations,weshould on-goingworkaimedatexploringtheroleoftheprogramminglanguageinthecontextofmodern softwaredevelopmentenvironments.theworkiscurrentlyfocusedontwofronts:thedevelopment 1Introduction complementingthosetraditionallyprovidedbyprogramminglanguages. nisms,andthedesignofenvironmentmechanismsthatsupportsoftwaremaintenanceandreuse, ofaformalismfordescribingbothaprogramminglanguageandassociatedenvironmentmecha- VLSItechnologyhasenabledtheproductionoflow-costhigh-poweredCPUsanddedicatedgraphics andadvancedgraphicscapabilities.inmanyapplicationareas,thishascausedashiftawayfrom hardware,leadingtotheproliferationofpersonalcomputerworkstationswithhigh-resolutiondisplays Advancesinhardwaretechnologyinevitablyleadtochangesinsoftwaretechnology.Theadventof batch-orientedsoftware,designedtorunwithaminimumofuserinteraction(oftenrelyingsolelyon le-basedinput-output),towardshighlyvisual,highlyinteractiveapplicationswhichaimtoallowthe 1

2 usertoenterinputandviewoutputinamoreappropriatemanner,andprovidevaluablefeedback inatimelyfashion.oneapplicationareainwhichthisshifthasbeenparticularlypronouncedis thatofengineeringcalculationsrelatedtoelectricalcircuits,wherecalculationsoncecarriedoutin shifthasbeensurprisinglyslowtotakeholdisthatofsoftwaredevelopmentitself.despitethefact punchcardsystems,throughtoscreen-basededitorswithgraphicaluserinterfaces,thepreceptthat abatch-orientedwayarenowpartofinteractivecadsystems.oneapplicationareainwhichthe programcodeismerelyasequenceoftextcharactershasremainedlargelyunchallenged.indeed,for thatthetechnologyforprogramentryhasprogressedthroughaseriesofstagesfrompapertapesand couldviaaneditorwithagraphicaluserinterface. programscouldbespeciedequallywellusingpunch-cards(speedofentrynotwithstanding)asthey themajorityofprogramminglanguagesusedtoday,eventhosedesignedduringtheworkstationera, integratedsoftwaredevelopmentenvironmentonamodernworkstation;insuchanenvironment,a coherentcollectionofsoftwaretoolssharerepresentationsoftheartefactstheymanipulate,andmay operateinsynchronywithoutexplicitinvocationbytheuser(whereappropriate).suchalevelof Thebasictenetofourworkisthatprogramsshouldalwaysbedevelopedunderthecontrolofan developmentwhereprogramsareentered,changedanddisplayed,allintextualform.stipulating theoneusedtoenterit,northeforminwhichitisdisplayed;thisiscontrarytotraditionalprogram adevelopmentenvironmentwithsupportforbitmappedgraphicsimpliesthatwecanabandonthe integrationimpliesthattherepresentationofasectionofcodeunderconstructionneednotmatch moreappropriatevisualrepresentationsofexistinglanguageconstructscanbeemployed,andnew linearsequenceofcharactersasthecanonicalrepresentationofprogramsunderconstruction.hence, constructscanbedesignedwhichmayhavebeenoverlookedpreviouslyforlackofaconvenienttextual meansofspecication.although\twodimensional"programlayoutswithvariousgraphicalelements environment,sincethestructureofaprogramisnotinferredbyitsvisualappearance,butratherby (lines,boxes,circles,etc.)canstillbesupportedinnon-itegrated,batch-orientedenvironmentsby employingparsertechnology,therangeofnotationsthatmaybeusedislimitedtothoseforwhich parsingstrategiesexist(suchasthosedescribedin[1]);thereisnosuchrestrictioninanintegrated theoperationsusedtoconstructit. 2

3 seektoextendthebenetsofcertain\programmingmechanisms"todocumentsfromotherstagesof feasible,agoalofourworkistore-examinetheroleofprogramminglanguages(andhence,theirdesign) inthelightofadvancesintheeldofintegratedsoftwaredevelopmentenvironments.inaddition,we Giventhattheabovetenetdirectlyimpactsthekindsofprogramminglanguageconstructsthatare thedevelopmentlife-cycle(suchasdesigndocumentsandsoftwareprocesses,forexample).questions thatarisefromsuchconsiderationsinclude: 3.Whichpartsofalanguageandenvironmentshouldbeformallyspecied,andwhichofthese 2.Whereistheboundarybetweentheprogramminglanguageandenvironment? 1.Whatshouldthedenitionofaprogramminglanguageencompass? 5.Whatareconvenientformsforentering,andfordisplayingcommonprogramminglanguage 4.Whichmechanismsarebestprovidedbytheprogrammingenvironment,andwhichbythelanguage? partsshouldberegardedas\standard"? constructionthatwedesiretosupport,anddiscussestherstthreeofthequestionsstatedabove. atedenvironmentmechanisms.section2classiesvariousaspectsoftheextendednotionofprogram Wearecurrentlydevelopingaformalismfordescribingbothaprogramminglanguageandassoci- constructs? TheformalismwehavedevelopedisdescribedinSection3.Sometentativeconclusionsandon-going Adescriptionofatraditionaltext-basedprogramminglanguagetypicallyinvolvesthespecicationof workrelatedtothelasttwoquestionsabove,arediscussedinsection4. thetextualsymbolswhichcanbearrangedtoformaprogram,thevalidcombinationsofsuchsymbols, 2Extendingthenotionofprogramconstruction theformusedtoconstructprograms,theformusedtodisplaythem,andtheformwithwhichthe aswellasadescriptionofthemeaningsascribedtothevariouscombinations.insuchdescriptions, 3

4 softwaredevelopmentenvironment,wewishtoavoidsucharestriction.thus,wehaveadoptedan howprogramminglanguagesmightdierifweassumethefacilitiesofaworkstation-basedintegrated alternativeviewofprogramminglanguagedescriptionswhichreectsourdesireforacleardivide semanticsrulesaredirectlyassociated,arenecessarilythesame.aspartofourinvestigationof wellasruleswhichstatewhenaprogramhasavalidinterpretation(i.e.staticsemantics)andrules ofaprogramminglanguageperse,tobethatwhichdescribesthefundamentalconceptualelements ofwhichprogramsarecomprised(suchasstatements,declarations,andexpressions,forexample),as betweentheconceptualnotionofaprogramandthewaythatoneisbuilt.weviewthedescription whichspecifywhatitmeanstoexecuteavalidprogram(i.e.dynamicsemantics).suchadescription maybeusefulforreasoningaboutprograms,writingcompilers,etc.,butcontainsnoinformation dependentupontheenvironmentinwhichprogramsaretobedeveloped.hence,forthoseinterested abouthowtobuildordisplayaprogram.theseactivities,buildinganddisplayingprograms,are inhowtoconstructaprograminagivenlanguage,orhowtointerpretavisualrepresentationofsuch aprogram,aprogrammingenvironmentdescriptionisalsonecessary.aprogrammingenvironment oftheconceptualelementsdescribedinthelanguagedescription,andintermsofthefacilitiesoered bytheenvironment(suchasmouse,keyboard,textandgraphics,forexample). descriptionshoulddenethevariousconstructionanddisplayoperationsintermsofmanipulations basedintegratedsoftwaredevelopmentenvironment,makingappropriateuseofallavailableinputand bothprogramminglanguageandenvironmentdescriptionsoftheformdiscussedabove,descriptions displaytechnologies,notmerelykeyboardandtext.thus,weseekaformalismsuitableforproviding Asstatedpreviously,wewishtosupportthedevelopmentofprogramsinthecontextofaworkstation- tobeemployedbyusersanddesignersofprogramdevelopmentmechanisms.morespecically,we haveusedthefollowingcriteriatodecideuponasuitableformalism: Theformalismmustbesuitableformodellingthestaticsemanticsof\conventional"programminglanguagemechanisms.Sinceweareconcernedwiththeimpactofsoftwaredevelopment environmentsuponprogramconstruction,andnotprogramexecution,wecurrentlyhaveno requirementthattheformalismshouldsupportthespecicationofdynamicsemantics. 4

5 Theformalismmustbesuitableformodellinginteractionwiththeprogramrepresentation(an Theformalismmustalsobeabletospecifyhowthevariousprogramconctructsaredisplayed. Foragivenenvironmentmechanism,itmustbepossibletodescribetheactionsrequiredbythe usertoinvokethemechanism,aswellasthehowsuchinvocationaectstheprogram. arrangementoftheconstructsdescribedinthelanguagedenition)viaenvironmentmechanisms. Certainformsof\code"whichwouldtypicallybedisplayedinanon-textualway,donotmap Inadditiontoplaintext,graphicalelements(suchaslines,circles,boxesandwindows)should besupported. Abandoningbatch-orienteddevelopmenttoolsinfavourofanintegratedprogrammingenvironmentadmitsthepossibilityofincrementalsemanticanalysis,providingmorerapidfeedbackfor whicharecommoninthepre-implementationstagesofthesoftwaredevelopmentlife-cycle. rangementofprogramconstructs.theformalismshouldallowthedescriptionofsuchnotations, welltohierarchicalprogramrepresentations;inparticular,theycorrespondtoagraph-likear- ofasemanticanalyserthatactsinunisonwiththevariousprogramconstructionmechanisms. thatwewishtoinvestigate.thus,theformalismmustbeamenabletosupportingthegeneration cribemeaningtopartiallyspeciedprogramsisnecessaryforsupportingthereusemechanisms theprogrammerandgivingmeaningto\incomplete"programs;furthermore,theabilitytoas- Documents(\code")fromthevariousstagesofthesoftwarelife-cycledonotexistinisolation, ple).theformalismmustbeabletocapturethesemanticsofsuchrelationships,andsupport thespecicationofenvironmentmechanismswhichspanmultiple\languages". rathertheyareoftenrelatedinmeaningfulways(\programaimplementsdesignb",forexam- 3Modellingprogramdevelopmentmechanisms WearecurrentlydevelopingaformalismthatmeetstherequirementsstatedinSection2,theintention ofwhichistoenablethedescriptionoflanguageandenvironmentmechanismsinaclearandunambiguousmanner,andtoallowtheimplementationofsuchmechanismstoproceedautomaticallyfrom 5

6 ahorizontallineindicatesthatthelayerabovethelineexplicitlyreferstoinformationdenedinthe andassociatedenvironmentmechanisms,layeredinthemannerillustratedbyfigure1.inthegure, layerbelowtheline. theirformaldescription.usingtheformalism,thespecierbuildsamulti-layeredmodelofalanguage includesadescriptionofwhatitmeansforapieceofcodetobeinaconsistentstate.figure2illustrates informationstructuresthatareusedtorepresentsectionsofcodeforthelanguagebeingmodelled1;this ThelowestlayerinFigure1,thestructurelayeriscomposedofadeclarativespecicationofthe Figure1:Modellayers. thenotationusedinthislayer.line1ofthegureshowsthataconstructcalledifstatementis beingdened,asaspecialisationofthestatementconstruct(denedelsewhere).lines4,5&6dene Structure anifstatementhasapartnamedconditionwhichisitselfanexpression.line9speciesthat thereisonesemanticvalue(avaluethatcanbederivedfromasectionofcode),abooleanvaluecalled validcondition.theruleonline12impliesthatanifstatementhasavalidconditionpartifthe thepartsofanifstatementthatmustbespeciedbytheuser.forexample,line4indicatesthat typeoftheconditionexpressionisbool(whereboolisaconstantdenedelsewhereinthelanguage denition). operationsexplicitlyspecied,operationsthatallowthereadingandwritingofthesyntacticpartsofa thatmaybeperformedonthestructuresdenedinthestructurelayer.asimpleexampleofan operationwhichswapsthetwobranchesofifstatementisshowninfigure3.inadditiontothe ThemanipulationsemanticslayerinFigure1providesimperativedescriptionsoftheoperations alsobesupportedforifstatement,toprovideaccesstotherstofthesyntacticpartsinfigure2. constructareimplicitlydeclared.forexample,operationssetconditionandgetconditionwould 1Recallthatcodeneednotimplythetraditionalnotionofprograms. ThemanipulationsyntaxlayershowninFigure1consistsofadeclarativespecicationwhichmaps 6 Editing Schema Manipulation Syntax Manipulation Semantics

7 if_statement:statement::= {syntacticparts semanticvalues alternative_action:statement condition:expression conditional_action:statement if_statement } semanticrules valid_condition:boolean {Swap_Branches{ valid_condition<-(condition.type='bool') }... conditional_action:=alternative_action alternative_action:=temp lettemp:=conditional_action Figure2:Deningstructure. denestworulesrelatedtoamoduleinterconnectiondiagram.line1ofthegureimpliesthatwhen sequencesofabstracteventstotheoperationsdescribedinthemanipulationsemanticslayer.figure4 }Figure3:Deningthesemanticsofmanipulations. m1passedasanargument;addclientinthisexampleisanoperationdenedinthemanipulation thelinkeventisinvoked,thentheaddclientoperationshouldbeperformedonmodulem2,with twomodules,m1andm2,havebeenselectedviatheinterfacetothisenvironmentmechanismand calledappropriately. andsubsequentlydeleted,thentheremoveclientoperationdenedinthepreviouslayershouldbe semanticslayer.similarly,line2ofthegureimpliesthatwhenalinkbetweentwomodulesisselected Select_Module(m1),Select_Module(m2),Link=>m2.Add_Client(m1) toactualuserinterfaceeventsviaaseriesofdeclarationswithintheeditingschema,theuppermost Theabstractevents(likeSelectModule)denedinthemanipulationsyntaxlayerarebound Select_Link(m1,m2),Delete=>m2.Remove_Client(m1) layerinfigure1.forexample,figure5speciesthattheabstracteventselectmoduleoccursasa Figure4:Deningthesyntaxofmanipulations. 7

8 arectangularframe;textboxissimplyadisplayprimitive,denedelsewhere.itisimportantto denedinthestructurelayershouldbedisplayedonthescreen.forexample,line6offigure5implies resultoftheactualeventdoubleclick2.theeditingschemaalsodescribehowthevariousstructures notethat,ingeneral,thereneednotbeaone-to-onecorrespondencebetweenvisualartefactsandthe structuresusedtorepresentasectionofcode. thatamoduleiconisdisplayedasthenameofthecorrespondingmoduleconstructsurroundedby } Module_Icon {State Events DisplayasTextBox(m.Get_Name()) m:module Double_Click=>Select_Module(m) languageandthedescriptionoftheprogrammingenvironment.whichofthelayersshowninfigure1 shouldbeconsideredasstandardascrossallimplementationsofalanguageandenvironment,remains TheemboldenedlineinFigure1indicatesthedivisionbetweenthedescriptionoftheprogramming Figure5:Aneditingscheme. anopenquestionatthisstage.regardingthebottomlayeronly,thestructurelayer,asstandard impliesthatprovidersoflanguagesystemsarefreetoimplementtheirownconstruictionanddisplay (anoviceprogrammermaychooseadierentenvironmentthanaskilledprogrammer,forexample),it mechanisms.whilethismightimplythatuserscanchoosetheenvironmentthatbestsuitstheirneeds theanalogsoftokensinourextendednotionofprogramconstruction;thus,thereissomeprecedent languagedenitions([2],forexample)havedenedprogramminglanguagesyntaxdowntothelevel oftheformatforparticulartokens;userinterfaceevents,suchasdoubleclickcanberegardedas mightalsocreateforprogrammersshiftingfromoneenvironmenttoanother.inthepast,programming beingused. relationtothestructurelayer,therehavebeenmanyformalismsproposedfordescribingthesemantics forsuggestingalevelofstandardizationclosetothetoplayerinfigure1. 2Strictlyspeaking,DoubleClickisitselfanabstractterm,boundattheleveloftheparticularwindowingsystem Thereisalargebodyofworkthatisrelevanttothedevelopmentoftheformalismoutlinedabove.In 8

9 ofprogramminglanguages,includingattributegrammars[3],twolevelgrammars(describedin[4]), productionsystems[5],andmanymore.suchformalismshavetypicallybeendesignedonlywith traditionaltext-basedlanguagesinmind,orarenotwellsuitedtothegenerationofincremental non-hierarchicalprogramstructures.relatedtothemanipulationsemanticslayerareapproaches suchasthosein[9]and[10].relatingtotheuppertwolayersoffigure1areunparsingschemes semanticanalysers;thus,wehavechosentoemployourownnotationinspiredbytheuseofattribute fortext-basedprogramminglanguages(suchasthatin[11]),andworksuchasthatin[12,13]on grammarsbyreps[6],horwitz[7],hedin[8]andmanyothers,butextendingthenotiontosupport 4Summary prohibitathoroughtreatmentofthisrelatedworkinthispaper. theconstructionofuser-interfacefacilitiessuitableforprogrammingenvironments.spaceconstraints On-goingworkonthedesignofcomplementaryprogramminglanguageandsoftwaredevelopment environmentmechanismstosupportsoftwareengineeringactivitieshasbeenoutlined.thisworkis basedontheassumptionthatsoftwarecomponentswillalwaysbedevelopedandcomposedwithinan integratedsoftwaredevelopmentenvironmentofsomekind. semanticswhichencompassestheextendednotionof\language"impliedbyhavingcombinationsof traditionalprogramminglanguagefeaturesworkinginconcertwithsoftwaredevelopmentenvironment mechanisms.thismodelwasoutlinedinsection3ofthepaper,andiscurrentlybeingusedinthe Animportantpartofthisworkhasbeenthedevelopmentofamodelofprogramminglanguage descriptionofsomeexamplesofcombinedlanguage/environmentprogramconstructionparadigms. Twosuchexamplesarediscussedbelow3: Onewayinwhichthecreationofmoregenericcodecomponentscanbefosteredistosupplementthetext-basednamebindingmechanismsoftraditionalprogramminglanguageswith apointing-orientedbindinginterfaceandaccompanyinggraphicaldisplay,whilstretaininga textualspecicationofthealgorithmicaspectsofacomponent. 3Furtherdetailscanbefoundin[14]. 9

10 Inordertosupportsomelevelofposthocreuse,andtoeasethetaskofmaintainingmultiple whenderivinganewcomponentfromit.byestablishingtherelationshipbetweenaderived versionsofrelatedcode,anenvironmentmechanismisbeingdevelopedwhichsupportsthe creationofderivedcomponentsbymonitoringthewayinwhichanexistingcomponentismodied References [1]S.S.ChokandK.Mariott.Parsingvisuallanguages.TechnicalReport94/200,MonashUniversity, theformerasaresultofmodicationstothelatter. componentandthecomponentfromwhichitisderived,itispossibletoautomaticallyupdate [3]D.E.Knuth.Semanticsofcontext-freelanguages.MathematicalSystemsTheory,2(2):127{145, [4]J.C.CleavelandandR.C.Uzgalis.GrammarsforProgrammingLanguages.Elsevier,New [2]Referencemanualfortheadaprogramminglanguage.TechnicalReportANSI/MIL-STD-1815A, [5]H.F.Ledgard.Productionsystems:OrcanwedobetterthanBNF?Communicationsofthe UnitedStatesDepartmentofDefense,1983. [7]S.Horwitz.Addingrelationalqueryfacilitiestosoftwaredevelopmentenviornments.In [6]T.Reps.GeneratingLanguage-BasedEnvironments.M.I.T.Press,Cambridge,Massachusetts, ACM,17(2):94{102,1974. Holland,Inc.,NewYork, H.Ganzinger,editor,ESOP88:2ndEuropeanSymposiumonProgramming,volume300,pages [10]F.Are,C.Hughes,andD.Workman.Automaticallygeneratingvisualsyntax-directededitors. [9]L.R.DykesandR.D.Cameron.Towardshigh-leveleditinginsyntax-basededitors.Software [8]G.Hedin.Anobject-orientednotationforattributegrammars.TechnicalReportLU-CS-TR-89- EngineeringJournal,5(4):237{244, ,LundInstituteofTechnology, {283.Springer-Verlag,NewYork-Heidelberg-Berlin,1988. [11]N.Habermann,R.Ellison,R.Medina-Mora,P.Feiler,D.S.Notkin,G.E.Kaiser,D.B.Garlan, CommunicationsoftheACM,33(3):349{360,1990. [13]P.DewanandM.Solomon.Anapproachtosupportautomaticgenerationofuserinterfaces. [12]M.Young,R.Taylor,andD.Troup.Softwareenvironmentarchitecturesanduserinterface Science,Carnegie-MellonUniversity,Pittsburgh,Pennsylvania,May,1982. facilities.ieeetransactionsonsoftwareengineering,14(6):697{708,1988. ands.popovich.thesecondcompendiumofgandalfdocumentation.departmentofcomputer [14]K.J.RansomandC.D.Marlin.Supportingsoftwarereusewithinanintegratedsoftwaredevelopmentenvironment.Submittedtothe1995SymposiumonSoftwareReuse,1995. ACMTOPLAS,12(4):566{609,