Robertson, D.

Vargas-Vera, M.

English

Edinburgh Research Explorer

     Edinburgh Research Explorer                                      An Environment for Building Prolog Programs Based onKnowledge about their ConstructionCitation for published version:Vargas-Vera, M & Robertson, D 1994, 'An Environment for Building Prolog Programs Based on Knowledgeabout their Construction'. in Proceedings of the 10th Workshop on Logic Programming (WLP 94), Zurich.Link:Link to publication record in Edinburgh Research ExplorerDocument Version:Author final version (often known as postprint)Published In:Proceedings of the 10th Workshop on Logic Programming (WLP 94), ZurichGeneral rightsCopyright for the publications made accessible via the Edinburgh Research Explorer is retained by the author(s)and / or other copyright owners and it is a condition of accessing these publications that users recognise andabide by the legal requirements associated with these rights.Take down policyThe University of Edinburgh has made every reasonable effort to ensure that Edinburgh Research Explorercontent complies with UK legislation. If you believe that the public display of this file breaches copyright pleasecontact openaccess@ed.ac.uk providing details, and we will remove access to the work immediately andinvestigate your claim.Download date: 20. Feb. 2015An Environment for Building Prolog ProgramsBased on Knowledge about their ConstructionMara VargasVera and Dave RobertsonDepartment of Articial IntelligenceUniversity of Edinburgh South BridgeEdinburgh EH HN UKemail fmariavdrg	aisbedacukProgram combination can be used to promote the reuse of software by allowing complexprograms to be built by repeated combination of other programsPrevious attempts at automatic systems which assist programmers in the task of combining programs have generally required lots of interaction from a user who also typicallyneeds a good understanding of the particular program transformation process being applied A system for transforming programs expressed as recursion equations is given inBD but its use requires intervention of a human with a good understanding of program transformation methods In procedural languages there are ways HPR to mergeprograms derived from an initial generic template however this approach is restricted toa limited class of programs In TS	 TS an unfoldfold based transformation system was given but requires user intervention and is restricted to programs with the sameow of control In LS SL methods were given for combining Prolog programs withthe same basic ow of control metainterpreters but these also require user interventionThe method of FF employs basic schemata supplied by an expert to combine listprocessing programs The method is very ecient however it can present the user with adicult choice between possible output schemata The method in PP combines logicprograms with the same ow of control using basic foldunfold transformations but relieson userguidance and its eciency depends on the decisions made by the userGiven these problems of overreliance on the user and lack of exibility we started outwith three basic ideas as to how the situation could be improved  Possibly having a high level description of the workings of the programs would beuseful  Such a highlevel description was potentially available from Prolog techniques editorsby modifying them so as to record the history of the program development which wecall the program history The advantage of using the program history is that it wouldgive information about the program that would otherwise be dicult to reextractfrom the nished program  We should develop many special purpose combination methods rather than attemptto nd a small number of general purpose methods This was motivated by initialexperiments in combining various standard programs with the known methodsTo investigate these ideas we took Sterlings notion of initial control ows  extendedit with additional mutations and developed it into a program classication schemeWe then designed combination methods that were typically only to be used for particular classes We found that this had the advantage that the method could then make mostof the choices necessary in the combination process choices that the user would otherwisehave to make and also work eciently for its intended class of programs The methodswere able to do this using the knowledge contained in the program history Furthermorethe program history itself could be used to classify the program and so select the correctmethodThe initial system was then further improved by renements to the classication systemand the development of new methods that were tailored to make an eective use of theprogram history whilst also ensuring that we could still use the program history to selectthe correct methodIn some cases when the user had underspecied the requirements of the combinedprogram the classication of programs using the highlevel description in the programhistory implicitly allowed the method to make an informed estimate of what were theusers likely intentions see the example presented later The methods were also able tocombine programs with dierent ows of control and for a common class of programs witharithmetic operations the system can deduce which arithmetic laws can be applied in orderto get a more optimal combined program More detailed description of these methods canbe found in VVThus our ideal program construction system consists of a Prolog techniques editor anda composition system We have not built a techniques editor because such systems alreadyexist Rob Bow	 and could easily be modied to record the choices that the usermakes when building a program In these editors such choices include selecting the initialcontrol ow skeleton and the techniques standard Prolog practices These choices arestored in the program history which therefore contains a highlevel description of theprogram that is close to the way that an expert might think about the program simplybecause the editors are designed to use methods that experts might use themselves butallow novices to use them easilyThe composition system allows users to construct more complex programs by combiningsimpler programs which have been built by means of a techniques editor as describedabove A component of this system is the selection procedure which automatically selectsa combination method according to the program histories of the simpler programs Theselectedmethod then controls the application of transformation rules taken from a librarymaking its decisions according to the information it nds in the program history We havedesigned the methods so that when they meet an underspecied combination then theywill tend to do transformations that preserve the spirit of the program histories and hencetheir functionalities rather than the simplest logical alternative again we refer the readerto the example later We believe this is more likely to match user intentions in the future This basis for the classication scheme was not chosen randomly but was based on our studies inwhich we found that knowledge of the ow of control was important in guiding the combination processwe would also allow user conrmation at this stageIn this way the composition system produces as output the combined program and anew history for the combined program These can be stored and used as input for furthercombinations The main characteristics of our composition system are  The system decides the combining method by analysing the pair of programs to becombined using the program history  The user does not need to take major decisions in the composition system such aswhich clauses need to be unfolded or folded ie the user does not need to knowabout program transformationLet us now proceed to the promised example Suppose we have two predicatesposListElementPosnds Element in the List with position Poscounting from the head of the listpathListElementPathnds Element in the List with path Pathmeaning sequence of elements up to andincluding the ElementposX X	 pathX XX	pos TXN  pathHTXHR posTXNP pathTXR	N is NP	Now suppose that the user requests that we combine these two programs Most transformation systems will take the join specication to be the Prolog programp pathLXPLP posLXPpathLXLP	and then convert this to the logically equivalent programp pathX XX	p pathXTXXRpathTXR	p pathXTXNX posTXNPN is NP	p pathHTXNHR p pathTXNPRN is NP 	In this case if we give the query p pathPPath then Prolog will givefour answersP 	 Path 	 P 	 Path 	 P 	 Path 	 P 	 Path 	 In our opinion this would usually not correspond to the users intentions Instead itseems more likely that the user would want to combine the functionalities of the programsto get	p pathListElementPosPathnds Element in the List with position Pos and pathPathin which case the last two solutions would be unwanted because they correspond to ndingdierent copies of the same element in the list and returning the path for one but theposition for the other Systems that rely only on the join specication written in theProlog form have no way to know that the user wanted exactly the same Element Thatis we want to synchronise the list search performed in pos and path There is no wayto express this requirement directly in Prolog using only the given predicatesHowever our system does not rely on the Prolog form of the join specication buteectively has an extended join specication which we can write asp pathLXPLP posLXP  pathLXLP	where the underlined arguments provide ows of control which we want to synchroniseSince we assume knowledge of the history of development of the program we can checkwhich arguments were intended to provide the ow of control and assess whether they willbe compatible in combination In this case it will observe from the program history thatboth programs have the same ow of control called search and only dier in that onehas a count technique added and the other an accumulator technique We assume thatthe user would also like the ow of control of the output to be search and would simplylike to have both the count and search techniques added This gives the output programp pathX XX	p pathHTXNHR p pathTXNPRN is NP 	which will indeed only return the rst two desired solutions and not the last two undesiredsolutionsLet us look at this in a bit more detail The search ow of control issearchH H  tH	searchHTXtHsearchTX	where t and t are tests The simplied versions of the program histories for theprograms pos and path arehistorypos  search truetrueno testsearchTXposTXNPno testcounthistorypath  search truetrueno testsearchTXpathTXRno testaccumulatorSonamed because it functions to search for a particular elementFor each history the rst argument is the name of the program the second is the aritythe third is the name of the initial control ow used in the construction of the program thefourth argument is a list recording for each clause how the subgoals in the initial controlow were transformed and the fth is the technique usedThe program histories thus say that both programs were built starting from searchthat the test literals were trivially true but that the techniques used were dierent In thiscase the composition system then selects the join method that makes the combinationby combining only corresponding clauses rather than combining all pairs of clauses thusachieving the desired synchronisation in the unpacking of the listsThe basic results of this investigation were The classication in terms of control ows and techniques was a useful classicationin that it allowed us to develop methods for each class in turn that were far morepowerful and required less user direction that was possible for programs in generalThis is not so surprising after all such classications arose out of experts trying toreason about Prolog programs and they would try to nd useful reasoning methods Storing the program history is useful It acts as a set of highlevel machinereadablecomments to the code In this case these comments contained the informationnecessary to classify the program by the above classication and hence select thecorrect combination method These comments could also be used by the combinationmethods to further reduce the need for user interaction In particular the commentscould be used to infer the users intentions in requesting the program combinationand so deal with cases of underspecication So the use of the program history wasa powerful way to render program combination more eectiveIn VVVR	 VVRI	 we describe our resulting set of methods the correspondingprogram classication system and how these elements can be combined into an almost fullyautomatic program combination system Of course our set of methods is not completebut it does cover a wide range of combinations A possible extension of this work wouldbe to use these comments in the program history in order to aid a highlevel dialoguewith the user The system could talk in the language of control ows and their associatedfunctionalities instead of in terms of lowlevel guidance of the combination methodWe believe that many of these lessons should also apply to languages other than PrologWe would like to give acknowledgements to Andrew Parkes and Rolando Carrera fortheir useful comments on this paperReferencesBD Rod Burstall and John Darlington A Transformation System for DevelopingRecursive Programs Journal ACM  Bow	 Andy Bowles A Techniques Editor for Prolog novices Internal note submittedfor publication DAI 	FF Norbert E Fuchs and Markus P J Fromherz SchemaBased Transformationsof Logic Programs In Logic Program Synthesis and Transformation Workshopsin Computing Springer Verlag HPR Susan Horwitz Jan Prins and Thomas Reps Integrating NonInterfering Versions of Programs In Proceedings of the Fifteenth Annual ACM Symposium onPrinciples of Programming Languages San Diego California January LS Arun Lakhotia and Leon Sterling Composing Logic Programs with ClausalJoin Tr  Computer Engineering and Science Department Case WesternReserve University PP Maurizio Proietti and Alberto Pettorossi Bestrst Strategies for IncrementalTransformations of Logic Programs In Second International Workshop onLogic Program Synthesis and Transformation Rob Dave Robertson A Simple Prolog Techniques Editor for Novice Users In G AWiggins C Mellish and T Duncan editors rd UK Annual Conference onLogic Programming pages  Springer Verlag April SL Leon Sterling and Arun Lakhotia Composing Prolog MetaInterpreters InKowalski and Bowen editors th Symposium of Logic Programming pages		 TS	 Hisao Tamaki and Taisuke Sato A Transformation System for Logic Programswhich Preserves Equivalence Tr 	 ICOT Research Center 	TS Hisao Tamaki and Taisuke Sato UnfoldFold Transformation of Logic Programs In Proceedings of the Second International Conference on Logic Programming pages 	 Sweden VV Maria VargasVera Guidance during Program Composition in a Prolog Techniques Editor PhD thesis Department of Articial Intelligence EdinburghUniversity  In preparationVVRI	 Maria VargasVera Dave Robertson and Robert Inder Combining PrologPrograms in a Techniques Editing System In Third International Workshopon Logic Programming Synthesis and Transformation Springer Verlag July	 Also published as DAI Research Paper 	VVVR	 Maria VargasVera Wamberto Vasconcelos and Dave Robertson BuildingLargeScale Prolog Programs Using a Techniques Editing System In International Logic Programming Symposium The MIT Press October 	 Presented as a poster and also published as DAI Research Paper 	

An Environment for Building Prolog Programs Based on Knowledge about their Construction

Abstract

Similar works

Full text

Available Versions

Edinburgh Research Explorer