Approaches to Automatic Programming

Transcription

1 MITSUBISHI ELECTRIC RESEARCH LABORATORIES Appoaches to Automatic Pogamming Chales Rich, Richad C. Wates TR92-04 July 1992 Abstact This pape is an oveview of cuent appoaches to automatic pogamming oganized aound thee fundamental questions that must be addessed in the design of any automatic pogamming system: What does the use see? How does the system wok? What does the system know? As an example of a eseach effot in this aea, we focus the Pogammeś Appentice poject. Advances in Computes, Volume 37, M. C. Yovits, ed., Academic Pess, 1993 This wok may not be copied o epoduced in whole o in pat fo any commecial pupose. Pemission to copy in whole o in pat without payment of fee is ganted fo nonpofit educational and eseach puposes povided that all such whole o patial copies include the following: a notice that such copying is by pemission of Mitsubishi Electic Reseach Laboatoies, Inc.; an acknowledgment of the authos and individual contibutions to the wok; and all applicable potions of the copyight notice. Copying, epoduction, o epublishing fo any othe pupose shall equie a license with payment of fee to Mitsubishi Electic Reseach Laboatoies, Inc. All ights eseved. Copyight c Mitsubishi Electic Reseach Laboatoies, Inc., Boadway, Cambidge, Massachusetts 02139

2 MERLCovePageSide2

3 Publication Histoy:{ 1. Fist pinting, MN92-04, July 1992

4 Automatic pogamming has been a goal of compute science and aticial intelligence since the st pogamme came face to face with the diculties of pogamming. As bets such a long-tem goal, it has been a moving taget constantly shifting to eect inceasing expectations. Much of what was oiginally conceived of as automatic pogamming was achieved long ago. Today, no one would call an assemble o a compile automatic pogamming. Howeve, when these devices wee st invented in the 1950's, the tem was quite appopiate. Compaed with pogamming in machine code, assembles epesented a spectacula level of automation. Moeove, Fotan was aguably a geate step fowad than anything that has happened since. In paticula, it damatically inceased the numbe of scientic end uses who could use computes without having to hie a pogamme. On the othe hand, cuent expectations egading the potential of automatic pogamming ae often based on an idealized view of eality and ae pobably unachievable. Nevetheless, a numbe of impotant developments ae appeaing in eseach eots and commecially available systems. As an example of a eseach eot in this aea, we focus on ou poject at MIT, called the Pogamme's Appentice (Section 5). The \cocktail paty" desciption of the potential of automatic pogamming uns something like this: Thee will be no moe pogamming. The end use, who only needs to know about the application domain, will wite a bief equiement fo what is wanted. The automatic pogamming system, which only needs to know about pogamming, will poduce an ecient pogam satisfying the equiement. Automatic pogamming systems will have thee key featues: They will be end-use oiented, communicating diectly with end uses; they will be geneal pupose, woking as well in one domain as in anothe; and they will be fully automatic, equiing no human assistance. Although this desciption is attactive, it is based on a numbe of faulty assumptions. 1.1 Myth: End-use-oiented automatic pogamming systems do not need domain knowledge It is no moe possible fo end uses to communicate eectively with an automatic pogamming system that knows nothing about the application domain than it is to communicate eectively with a human pogamme who knows nothing about the application domain. Rathe, the path fom an end-use's needs to a pogam involves a gadual change fom a desciption that can only be undestood in the context of the domain to a desciption that can be undestood without elying on auxiliay knowledge. Thee is no point at which someone who knows nothing about 1

5 pogamming communicates diectly with someone who knows nothing about the application domain. Fo example, suppose a lage company needs a new accounting system. Figue 1 shows the pincipal agents that would typically be involved. The bas on the ight indicate that nea the top of the gue accounting knowledge plays the cucial ole, while pogamming knowledge dominates towads the bottom. The manage at the top of the gue quite likely has only a udimentay knowledge of accounting. The manage's job is to identify a need and initiate the pogamming pocess by ceating a bief, vague equiement. The tem \vague" is used hee to highlight the fact that the only way this initial equiement can succeed in being bief is fo it to also be incomplete, ambiguous, and/o inconsistent. The next agent in the pocess is an accounting expet. The accounting expet's job is to take the manage's vague equiement and ceate a detailed equiement. A key featue of this equiement is that it is couched in the technical vocabulay of accounting and is intended to be evaluated by othe accounting expets. The accounting expet's knowledge of pogamming does not have to extend much beyond basic notions of feasibility. The thid agent in the pocess is some sot of system analyst. The analyst's job is to dene the basic achitectue of the pogam and to tanslate the equiement into a detailed specication. In contast to the equiement, the specication is couched in the technical vocabulay of pogamming, athe than accounting. To pefom this tansfomation, the system analyst must have a consideable undestanding of accounting in addition to an extensive knowledge of pogamming. (Section 5.1 demonstates an inteactive tool to assist systems analysts.) The nal agent in the pocess is a pogamme. The pogamme's job is to poduce code in a high level language based on the detailed specication. The pogamme does not have to know vey much about accounting. Howeve, it is vey unlikely that the accounting system will actually wok if the pogamme knows nothing about accounting. Although not shown in the gue, agents fo validation, testing, documentation, and modication ae equied as well. To do thei jobs, these agents also need significant domain knowledge. In eality, end-use-oiented automatic pogamming systems must be domain expets. In paticula, it is not possible to descibe something biey unless the heae knows at least as much about the domain as you do and can theefoe undestand the wods used and ll in what is left out. (Fo a futhe discussion of the necessity of domain knowledge in automatic pogamming, see Bastow (1984).) 1.2 Myth: End-use-oiented, geneal-pupose, fully automatic pogamming is possible A coollay of the need fo domain knowledge is that such an automatic pogamming system would have to be an expet in evey application domain. Unfotunately, 2

6 Figue 1. Agents in an accounting softwae poject and the kind of knowledge they use. 3

7 thee is no hint that aticial intelligence is anywhee nea suppoting this kind of supehuman pefomance. Given the pagmatic impossibility of simultaneously suppoting all thee featues mentioned above, it is not supising that all cuent appoaches to automatic pogamming focus on two of the featues at the expense of the thid. This has given ise to the following thee appoaches to automatic pogamming, typied by the featue given up: a. Bottom-up. This appoach sacices end-use oientation. It stats at the pogamme's level and ties to push the theshold of automation upwad. In the past, the theshold was aised fom machine-level to high-level languages. The cuent goal is to aise the theshold futhe to so-called vey high-level languages. b. Naow-domain. This appoach sacices being geneal pupose. Focussing on a naow enough domain makes it feasible ight now to constuct a fully automatic pogam geneato that communicates diectly with end uses. This appoach is advancing to cove wide domains. c. Assistant. This appoach sacices full automation. Instead, it seeks to assist in vaious aspect of pogamming. (The Pogamme's Appentice pioneeed the application of aticial intelligence technology to the assistant appoach.) With cuent technology, this appoach is epesented by pogamming envionments consisting of collections of tools such as intelligent editos, on-line documentation aids, and pogam analyzes. The goal hee is to impove the integation between tools and level of assistance povided by individual tools. 1.3 Myth: Requiements can be complete Since the cocktail paty desciption of automatic pogamming assumes that the only point of contact between the end use and the system is a equiement, this equiement must be complete. In the inteest of poducing an ecient pogam, the automatic pogamming system is expected to take full advantage of evey degee of feedom allowed by the equiement. The completeness of the equiement guaantees that anything the automatic pogamming system poduces will be acceptable to the end use. This point of view is commonly justied by likening equiements to legal contacts. Howeve, any lawye will tell you that contacts do not wok that way. Contacts only wok when both paties make a good faith eot to wok towad a common end. If good faith beaks down, the paties can always cheat without violating the \lette" of the contact. The poblem with equiements (and contacts) is that they cannot be complete. No matte how tivial the situation in question, thee is no pactical limit to what needs to be said when tying to pin down a potential advesay. 4

8 Conside, fo example, specifying a contolle fo an automated telle machine. When descibing the withdawal opeation, it is easy enough to say that afte the bank cad is inseted, the custome should ente a passwod, specify an account, and then select an amount of cash which the machine then dispenses. Howeve, this is nowhee nea complete. To stat with, thee ae a lot of details missing with egad to the use inteface: What kinds of diections ae displayed to the custome? How is the custome to select between vaious accounts? What kind of acknowledgment is poduced? To be complete, these details must include the layout of evey sceen and pintout, o at least, a set of citeia fo judging the acceptability of these layouts. Even afte the inteface details ae all specied, the equiement is still fa fom complete. Fo example, conside just the opeation of checking the custome's passwod. What ae passwods to be compaed against? If this involves a cental epositoy of passwod infomation, how is this to be potected against potential faud within the bank? What kind of esponse time is equied? Is anything to be done to deal with possible tampeing with bank cads? One step deepe, a tuly complete equiement would have to list evey possible eo that could occu in the custome's input, the telle machine, the cental bank compute, the communication lines and state exactly how each eo should be handled. Going beyond what is computed, the use undoubtedly wants the pogam to be easonably ecient. This could be specied as maximum limits on space and time. Howeve, what is eally desied is fo the implemento to make a good faith eot to make the pogam as ecient as possible. Futhe, the code poduced should be easy to ead, easy to modify, and well documented. Finally, the end use also undoubtedly caes about the cost of implementing the pogam and how long it will take. This implies that tade-os must be made, paticulaly when it comes to the last few issues mentioned above. This makes it vey dicult if not impossible to make complete statements about these issues. In eality, equiements ae at best only appoximations. Instead of seving as a defensive measue between advesaies, equiements should be used as a tool fo communication between colleagues. Assuming that the implemento will make a good faith eot to ceate a easonable pogam, many of the points above can go unsaid. Just like human pogammes, an automatic pogamming system must make a good-faith eot to satisfy the spiit of the equiements given to it. The system must be oiented towad making easonable assumptions about unspecied popeties, athe than tying to minimally satisfy specied popeties. This obsevation einfoces the need fo domain knowledge as pat of an automatic pogamming system. 5

9 1.4 Myth: Pogamming is a seial pocess In many ways, the wost aspect of the cocktail paty desciption of automatic pogamming is that it pepetuates the myth that ceating a pogam is a two step pocess: Fist, an end use ceates a equiement; second, the automatic pogamming system makes a pogam. This view is just as impactical in the context of an automatic pogamming system as it is in human-based pogamming. Fist of all, given the appoximate natue of equiements, a consideable amount of back-and-foth communication is equied to convey the end use's full intent. Second, uses typically stat the pogamming pocess with only a vague idea of what they want, and they need a signicant amount of feedback to esh out thei ideas and detemine the desied equiement. Also, what end uses want today is neve the same as what they want tomoow. Thid, uses do not want pogammes to follow equiements blindly. If poblems aise, they want advice. Fo example, the pogamme should tell the use if a slight elaxation in the equiement would allow a much moe ecient algoithm to be used. In eality, pogamming is an iteative pocess featuing continual dialogue between end use and pogamme. The desied equiement evolves out of pototypes and initial vesions of the system. The inheently iteative natue of pogamming has two impotant implications fo automatic pogamming. Fist, just as in nonautomatic pogamming, the focus of activity will be on changing equiements as much as on implementing them. Thus, thee will be no eduction in the need fo egession testing and othe techniques fo managing evolution. Second, to cay on a dialogue with the use, automatic pogamming systems will need to explain what they have done and why. In paticula, they will need to explain the assumptions they have intoduced into a equiement so that uses can debug those assumptions. 1.5 Myth: Thee will be no moe pogamming Thee will cetainly be many dieences between the input to futue automatic pogamming systems and what is cuently called a pogam. Howeve, pogamming is best typied not by what pogams ae like but by what pogamming tasks ae like. In paticula, these new inputs will undoubtedly still have to be caefully cafted, debugged, and maintained accoding to changing needs. Whethe o not one chooses to call these inputs pogams, the tasks associated with them will be stongly eminiscent of pogamming. In eality, end uses will become pogammes. As an example of this phenomenon, conside speadsheet pogams. When speadsheets st appeaed, they wee healded as a way to let uses get thei wok done without having to deal with pogammes o lean pogamming. Speadsheets have succeeded admiably in letting uses get esults by themselves. Howeve, maintaining a complex speadsheet ove time dies 6

10 vey little fom maintaining a pogam. The only eal dieence is that a speadsheet is a concise domain-specic inteface which makes it emakably easy to wite cetain kinds of pogams and statlingly dicult to wite othe kinds of pogams. 1.6 Myth: Thee will be no moe pogamming in the lage Even if we accept the fact that pogamming will be aound foeve, we might well hope that by continuing the tend of witing pogams moe compactly, automatic pogamming will convet all pogamming into pogamming in the small. Unfotunately, this deam ovelooks softwae's exteme elasticity of demand. Most of the poductivity impovements intoduced by automatic pogamming will almost cetainly be utilized to attack applications that ae enomous athe than meely huge. In eality, we ae unlikely to eve settle fo only those application systems that can be ceated by a few people. As a esult, thee will be no lessening of the need fo vesion contol, management aids, and all of the othe accoutements of coopeative wok and pogamming in the lage. The automatic pogamming systems of the futue will be moe like vacuum cleanes than like self-cleaning ovens. With a self-cleaning oven, all you have to do is decide that you want the oven cleaned and push a button. With vacuum cleanes, you poductivity is geatly enhanced, but you still have a lot of wok to do. The next thee sections discuss the thee fundamental technical issues in automatic pogamming that must be addessed in the design of any automatic pogamming system: What does the use see? How does the system wok? What does the system know? Fom the use's pespective, the most pominent aspect of an automatic pogamming system is the language used to communicate with it. We will discuss the ange of possibilities below using as an example the simple poblem of detemining the value of an octal numbe epesented as a sting. Figue 2 shows the Pascal implementation of a pogam that solves this poblem. We would like an automatic pogamming system to poduce a pogam like this fom one of the use inputs discussed below. Note that no single example can equally well illustate all of the impotant issues in selecting an input medium. 2.1 Natual Language Because they ae familia, natual languages such as English ae an attactive choice fo communication between end uses and an automatic pogamming system. Thee othe featues that make natual language attactive ae vocabulay, infomality, and 7

11 function EvalOctal (va S aay [M..N: Intege] of Cha): Intege; va I, V: Intege; begin I := M; V := -1; while S[I]=' ' do I := I+1; if S[I]<>ch(0) then begin V := 0; while ('0'<=S[I]) and (S[I]<='7') do begin V := 8*V+od(S[I])-od('0'); I := I+1 end; while S[I]=' ' do I := I+1; if S[I]<>ch(0) then V := -1 end; EvalOctal := V end Figue 2. Pascal implementation of a pogam that detemines the value of an octal numbe epesented as a sting. Note that to allow fo stings of zeo length, stings ae implemented as aays of chaactes whee the last chaacte is not pat of the sting. The function od etuns the intege chaacte code coesponding to a chaacte. syntax. Fo example, the following is a natual language specication of the EvalOctal pogam in Figue 2. The function EvalOctal is a ecognize that detemines whethe o not a given sting contains an octal numbe optionally suounded by blanks. If this is the case, the decimal value of the numbe is etuned; othewise -1 is etuned. The featue that contibutes the most to making natual language an ecient communication medium is the existence of a vocabulay of thousands of pedened wods. Among othe things, the natual language specication above assumes that the eade knows what a ecognize is, what an octal numbe is, and the elationship between the value and sting epesentation of an octal numbe. Infomality, such as the possibility of a statement's being ambiguous, incomplete, contadictoy, and/o inaccuate, is also vey impotant. In fact, it essential to a poweful stategy fo dealing with complexity: Stat with an almost-ight desciption and incementally modify it until it is acceptable. Fo example, the natual language specication above is vague about the data type of the output. (Intege was chosen in Figue 2.) It is also vague about whethe o not the octal numbe may be peceded by a sign. (Figue 2 assumes it may not, since if negative numbes wee allowed, then -1 could coespond to a valid input.) Finally, the specication above does not say what should happen if the octal numbe is too big to epesented. (Figue 2 allows oveow to occu.) 8

12 = 8 ' '0' '7' - Numbe 8 V := 8*V+ () @@@R '0' '7' = etun V () 8 = ' '? = ' ' - Blanks 0 0 othe 0 0 etun = 0 0 etun V othe etun ?? Done Figue 3. A state tansition diagam specication fo EvalOctal. The least impotant featue of natual language is its syntax. Natual syntax is convenient, because it is familia. Howeve, it is of elatively little value unless the othe featues ae suppoted as well. Unfotunately, enabling machines to convese in natual language is fa beyond the cuent abilities of aticial intelligence. As a esult, natual language input although an active aea of inquiy in its own ight is not a majo topic in cuent automatic pogamming eseach. Fo examples of ealy wok on automatic pogamming using natual language input, see Heidon (1976) and Ruth (1978). 2.2 Special-Pupose Languages Even when people communicate among themselves, natual language is not always the language of choice. Fo example, many application aeas have specialized symbolic o gaphical languages associated with them, such as mathematical fomulae and cicuit diagams, that expets outinely use in pefeence to natual language. Fo example, Figue 3 shows the specication of EvalOctal using the standad gaphical notation fo descibing state tansition netwoks. In this diagam, states ae epesented as ovals and tansitions between states ae epesented as aows. The aows specify what happens when an input chaacte is encounteed. (Fo instance, suppose the pogam is in the Blanks state. If it eceives a blank chaacte, then it stays in the Blanks state. If it eceives an chaacte indicating that thee is no moe input, then it goes to the Done state.) In addition, some of the aows ae 9

13 annotated with specications fo actions to be pefomed when tansitions occu. (Fo instance, if the pogam is in the Stat state and eceives one of the chaactes '0' though '7', it sets a vaiable V equal to the intege coesponding to the chaacte.) A key advantage of Figue 3 is that it is easy to undestand and modify. Specication changes can be easily made using, fo example, a gaphical edito. Figue 3 is also much moe fomal and detailed than the natual language desciption of EvalOctal in Section 2.1. Fo example, it species exactly what can appea in the input. Howeve, it is also still incomplete. Fo example, it does not say what to do if the input numbe is too big. Many kinds of special-pupose languages can be suppoted in staightfowad ways, as long as thei focus is suciently naow. A paticulaly successful example is so-called \what you see is what you get" intefaces. Sceen paintes allow end uses to specify the layout (and some of the semantics) of a data enty and etieval pogam simply by making a pictue of how the sceen should look. Then a code geneato automatically wites the code to dive the teminal and access the data base. Unfotunately, special-pupose languages have the fundamental poblem that they ae essentially useless outside of thei domains of applicability. This bings up a key unsolved poblem namely, how to combine seveal special-pupose languages o a special-pupose language with a geneal-pupose one. Almost evey cuent system that suppots a special-pupose language follows the naow-domain appoach to automatic pogamming, esticting itself to the situations whee the special-pupose language is appopiate. Even when multiple, specialpupose input languages ae suppoted (e.g., in Daco (Neighbos, 1984)), the use is only allowed to combine the languages in simple ways. Much moe wok needs to be done befoe special-pupose languages can each thei full potential as pat of the inteface to geneal-pupose systems. 2.3 Examples An attactive idea, pusued with some vigo in the ealy days of automatic pogamming, is to specify a pogam via examples of its behavio. Ealy wok in this aea (Hady, 1975; Shaw et al., 1975; Siklossy and Sykes, 1975) was ad hoc in natue. This changed with the wok of Summes (1977) who established theoetical foundations fo the eld. Most subsequent wok is based on Summes' appoach. Futhemoe, most of the wok on pogamming by example uses Lisp as the taget language (see suvey by Smith (1984)). The eason fo this is not intinsic to any of the techniques, but athe it is because the Lisp pogamming envionment facilitates witing pogams that opeate on pogams. The appeal of pogamming by example is that non-pogammes ae familia with examples as a communication technique, just as they ae with natual and specialpupose languages. Futhemoe, collections of examples ae easy to undestand and modify. Fo example, the following is a set of input-output examples which might be 10

14 used to specify EvalOctal. "132 " ) 90 " 42 ") 34 " 56" ) 46 "-17 " ) -1 "2.6 " ) -1 " 380" ) -1 Individually, these examples seem clea enough. Howeve, if this tuly was the only infomation given, it would be next to impossible fo a peson (let alone an automatic system) to undestand what the pogam was supposed to do. To stat with, consideable insight is equied to come up with the coect genealization of the st thee examples i.e., that the output is the value of the input viewed as an octal numbe. In addition, thee need to be many moe examples to addess questions like: What happens if thee ae moe than thee digits? What happens if thee is moe than one blank afte the numbe? What happens if thee is a '+' in font of a numbe. What happens if a numbe stats with a '0'? What happens if two numbes ae sepaated by blanks? What happens if thee ae lettes in the input? (Imagine how many examples would be equied if EvalOctal wee not a toy pogam!) Although it initially ceated a good deal of excitement, pogamming by example now appeas to be of only theoetical inteest. The poblem is that the techniques do not scale up to pogams of ealistic complexity. Unfotunately, as input-output pais become moe complex, the poblem of genealizing them appopiately becomes astonomically moe complex. Thee ae basically only two ways to cut the genealization poblem down to a manageable size. Fist, moe examples can be povided in ode to educe ambiguity, including examples of intemediate computation steps (see Biemann (1972), Biemann (1976), Biemann and Kishnaswamy (1976), and Baue (1979)). Unfotunately, when the numbe of examples becomes too lage, this becomes an inecient means of specication as compaed with othe fomal techniques. Altenatively, assumptions about the class of taget pogams can be built into the pogamming-by-example system. Fo example, Andeae (1985) synthesizes obot pogams fom examples. The system descibed by Hedick (1976) assumes that the synthesized pogam must be a ule-based poduction system. Unfotunately, when the stuctual assumptions begin to get this stong, the pogamming-by-example system ends up being essentially a special kind of pogam geneato. A dieent appoach to using examples is illustated by the Tinke system (Liebeman and Hewitt, 1980). Tinke does not attempt to genealize the examples automatically but athe povides a pogam development envionment that helps the use pefom the genealization. In this context, the input-output examples ae pehaps bette thought of as test cases. In summay, examples may be a useful technique only as an adjunct to othe specications o in a naow domain in which the possible pogams ae aleady highly esticted. 11

15 2.4 Logical Fomalisms Logic is the most poweful (and geneal) fomal desciption language known. As a esult, it is easonable to suppose that it might make a good communication medium between a use and an automatic pogamming system. Unfotunately, thee ae two fundamental baies to the use of logical fomalisms. Fist, most inteesting tasks in geneal logical systems (fo example, detecting contadictions) ae computationally intactable (see the discussion of deductive methods in Section 3.2). Second, complex logical fomulae ae notoiously dicult fo most people to wite and undestand. Fo example, the following is a logical specication fo EvalOctal in the fom of pe- and postconditions. This specication assumes that the notion of a sting is built into the logic. In paticula, a sting S is teated as a function that maps fom the intege ange 1::jSj to chaactes, whee jsj denotes the length of a sting. input: S pecondition: (S) output: V postcondition: (V ) ^ ( (S)! (S; V )) ^ (: (S)! V = 01) whee: (S) (8i 1 i jsj!s(i) 2f' '; '0'; '1'; '2'; '3'; '4'; '5'; '6'; '7'g) ^ (9i 1 i jsj!s(i) 6= ' ') ^ (:9ijk 1 i<j<kjsj^s(i) 6= ' ' ^ S(j)=' '^ S(k) 6= ' ') (S; V ) 8ij (1 i<jjsj^s(i) 6= ' ' ^ S(j) 6= ' ' ^ (j = jsj _S(j+1) = ' '))! ( (S(i)) = ( (V;8 j0i01 );8 j0i02 ) ^ ((i=1_ S(i01)= ' ')! V<8 j0i )) The essence of this specication is contained in the denitions of and. The pedicate is tue of a sting i evey chaacte is an octal digit o a blank, at least one chaacte is a digit, and thee ae no blank chaactes between digits. The elation holds tue i each digit in S is coectly epesented in V and V contains no othe values. (The function etuns the intege coesponding to a digit chaacte. and ae the intege division and emainde opeatos, espectively.) The specication above has the vitue of being vey pecise without biasing possible implementations. Unfotunately, it is fa fom obvious, fo example, that the elation in fact guaantees that V is the value of the octal numbe epesented in S. Reseach on logic as a communication medium between man and machine is being caied out pimaily unde the topics of fomal specication languages and logicpogamming languages. A key issue in both of these aeas is the intoduction of 12

16 extensions and estictions that ende logic moe tactable to man and machine. Fo example, Polog (Cohen, 1985) guaantees executability of logical desciptions by placing stong estictions on the fom of expessions. 2.5 Vey High Level Languages While specication languages and logic pogamming languages essentially extend \downwad" fom logic, vey high level languages build \upwad" fom cuent high level languages. Typically, vey high level languages add poweful abstact datatypes, such as sets and mappings (to allow pogammes to ignoe the details of data stuctue implementation), and a few featues of logical notation, such as quantication ove sets (to allow pogammes to ignoe cetain kinds of algoithmic detail). The achetype of vey high level languages is SETL (Schwatz et al., 1986). SETL suppots most of the standad constucts of Algol-like pogamming languages. In addition, it suppots two convenient univesal data stuctues tuples and sets. Fo example, a mapping is teated as a set of 2-tuples. SETL also suppots the use of univesal and existential quanties in a pogam. Fo example, the following is the fom of the SETL statement fo pefoming some computation on evey element of the set S. (foall x in S) ::: end foall; One of the main goals of poviding such expessive facilities is to fee the pogamme fom having to think about the detailed design of data stuctues. The SETL compile will decide how data stuctues should be implemented. This decease in what the pogamme has to woy about is a key to the poductivity gains that should be obtained by the use of vey high level languages. The following shows how one could wite EvalOctal in SETL. pocedue EvalOctal(S); if (foall C in S C in {' ','0','1','2','3','4','5','6','7'}) and (exists C in S C /= ' ') and (not exists Ci in S(i), Cj in S(j), Ck in S(k) i<j and j<k and Ci/=' ' and Cj=' ' and Ck/=' ') then Digits := [abs C - abs '0': C in S C/=' ']; etun +/[D*8**(#Digits-i): D in Digits(i)]; else etun -1; end if; end pocedue EvalOctal; The fom of this pogam closely follows the fom of the logical specication in the peceding section. The condition of the if statement illustates that many logical expessions can be endeed moe o less diectly in SETL. Howeve, this cannot be done with non-constuctive logical expessions such as elation. When the input is well-fomed, the SETL pogam above computes the output value as follows. Fist, it selects all of the input chaactes that ae digits and ceates a tuple (odeed sequence) of the coesponding numbes in the same ode. (The SETL 13

17 opeato abs is the same as the Pascal function od.) It then ceates a tuple of the digits multiplied by the appopiate powes of 8. (The SETL opeato # detemines the length of a tuple.) Finally, it computes the sum (using the opeato +/) of the elements of this tuple. A key featue of this computation is that it contains two uses of the SETL tuple fome constuct: [element: va in tuple { selecto}]. To illustate how this constuct is used in the pogam above, conside the following examples. [abs C - abs '0': C in " 124 " C/=' '] etuns [1,2,4] [D*8**(#Digits-i): D in [1,2,4](i)] etuns [64,16,4] +/[64,16,4] etuns 84 Patly because it has a somewhat cyptic and unfamilia syntax, a signicant amount of taining is equied in ode to use SETL's featues to full advantage. Howeve, it is possible to wite SETL pogams that ae vey compact and eadable. In addition, unlike the othe specications discussed above, a SETL pogam is complete since it is diectly executable. Fo example, it species that oveow will occu if the numbe epesented by the input is too lage. The Rene language (Abaido-Fandino, 1987) is in many ways simila to SETL. The GIST language (Feathe and London, 1982) is epesentative of a moe ambitious diection in eseach on vey high level languages. The goal of GIST is to povide the expessiveness of natual language while imposing fomal syntax and semantics. Two examples of capabilities povided in GIST that distinguish it fom SETL-like languages ae: histoical efeence (the ability to efe to past pocess states) and constaints (estictions on acceptable system behavio in the fom of global declaations). Fo a geneal discussion of othe desiable featues of a specication language, see Balze (1985). Not supisingly, the moe advanced featues that you put into a vey high level language, the hade it is to compile (and to some extent, undestand; see Swatout (1983)). Compiles fo SETL and Rene have both been implemented and commecially distibuted. In contast, although it has been an active aea of eseach, a complete GIST compile has not yet been constucted. When compiling languages such as SETL and Rene, the paamount poblem is deciding how to implement the abstact data stuctues in the pogam. These decisions ae needed not only to epesent the data, but also to decide how to use loops to implement quanties in the pogam. Some eseaches (e.g., Low (1978) and Rowe and Tonge (1978)) have focused on the poblem of data stuctue implementation sepaate fom the details of any specic vey high level language. The SETL compile opeates in a pocedual fashion somewhat simila to a conventional optimizing compile. It is only modeately successful at poducing ecient code. In ode to make implementation choices that lead to moe ecient un-time pefomance, the SETL compile will have to pefom a deepe analysis of the input pogam. Meanwhile, a declaation language is povided that the pogamme can 14

18 use to tell the SETL compile how to implement paticula sets. Although this is an appealing compomise in the spiit of incemental automation, it is less than satisfactoy in pactice. The poblem is that if the full expessive powe of SETL is used in witing a pogam, it can be vey dicult fo a pogamme to gue out what to ecommend. The cuently favoed technique fo compiling vey high level languages is to use a pogam tansfomation system to emove the vey high level constucts. Fo example, this appoach is used fo the Rene language. As discussed in Section 3.3, tansfomational systems equie advice on what tansfomations should be applied whee. Unfotunately, as in the case of explicit declaations, it can be vey dicult fo a pogamme to come up with the needed advice. Anothe impotant tend in vey high level languages is towad specialized languages fo paticula application aeas. Fo applications like business data pocessing (Cheng et al., 1982), quite high level languages have been developed that can be successfully compiled using easonably staightfowad techniques. 2.6 Othe Communication Issues The following ae thee geneal issues that apply to any communication medium fo automatic pogamming Wide spectum What should uses do when they want to say something moe detailed than the abstaction level suppoted by the input medium? The puists' answe is that it is a bad idea fo uses to say such things the automatic pogamming system should be left to make all such decisions. Howeve, pagmatists ealize that (at least fo the foeseeable futue) automatic pogamming systems cannot opeate without getting a cetain amount of advice at all levels. A good way to suppot this pagmatic appoach is to povide uses with a widespectum language, i.e., one that povides both high level and low level constucts in a single coheent famewok. Fo example, a vey high level language like SETL is wide spectum because it etains the featues of cuent high level languages e.g., it etains the odinay looping mechanisms while adding quantication. English is inheently wide spectum unless the vocabulay is seveely esticted. In contast, special-pupose languages ae not typically wide spectum. (The ideal automatic pogamming system would pobably be one that suppots a geneal-pupose widespectum language plus a numbe of naowe special-pupose languages.) Lage vocabulay In pinciple, any of the languages associated with the bottom-up appoach to automatic pogamming can make use of a pedened vocabulay of tems. Fo example, a logical specication can efe to any numbe of pedened pedicates and functions. 15

19 Similaly, a pogam witten in a vey high level language can efe to any numbe of pedened suboutines. Howeve, as discussed in Section 4, each of these languages implicitly limits what can be dened as a vocabulay item. In addition, eseach on these languages has geneally focused on poviding a elatively small set of vey poweful pimitives. An altenate appoach is to make the utilization of an extensive, pedened (including domain specic) vocabulay be the pimay goal. This can be thought of as an attempt to peseve the vocabulay intensive natue of English while still getting id of most of the infomality. As an example of what a vocabulay intensive language might look like, conside the following, which is simila to desciptions poduced and used in the Pogamme's Appentice. EvalOctal is a function fom sting S to intege V. EvalOctal implements a egula expession ecognize whee: The ecognized expession is "blank * { } + blank * ". The failue output is -1. The success output, V, is the decimal value of the octal numbe in the non-blank substing of S. The undelined wods and phases above ae all taken to be pedened tems. This specication of EvalOctal is eminiscent of the English desciption above. Howeve, it is dieent in seveal impotant ways. To stat with, it uses a highly simplied syntax, including indentation to show hieachical elationships between the pats of the specication. Also, this specication is not infomal: Eveything is spelled out in detail including exactly what it means fo the input to contain an octal numbe. The featue which the specication above does shae with English is the use of a lage vocabulay. Given a choice, most uses would be much happie to use an awkwad medium in which almost eveything they want is aleady dened, athe than an othewise convenient medium in which eveything needs to be dened fom st pinciples Dialogue Because of the inheently iteative natue of the pogamming pocess, a medium must be able to suppot a dialogue between the use and the automatic pogamming system. In paticula, the medium of communication must be capable of expessing \meta level" infomation, e.g., infomation about changes to the state of knowledge. One can imagine how natual language would seve well as a dialogue medium. Resticted notations, such as vey high level languages, ae clealy not sucient by themselves. As an illustation of the impotance of suppoting dialogue between the use and an automatic pogamming system, suppose that an automatic pogamming system has been given the vocabulay intensive specication of EvalOctal in the peceding section. While attempting to wite the coesponding pogam, it would be helpful if 16

20 the system emaked about the poblem with oveow and gave the use a chance to x it, as shown below. System: Thee does not appea to be any limit on how lage the output can be. Howeve, the lagest intege value is Use: Have EvalOctal etun -1 if oveflow occus. Inteactive dialogue bings two new featues into the automatic pogamming pictue. Fist, inteaction makes it possible to x mistakes. If uses ae going to be bief, they will inevitably un the isk of being misundestood. An inteactive mode of opeation gives uses immediate feedback on the eects of thei statements and allows them to make claications. (Fom this point of view, batch systems ae just inteactive systems with fustatingly long communication delays. Almost any system can benet fom becoming moe inteactive.) Second, inteaction makes it natual fo uses to talk about the pocess of pogamming as well as about what the taget pogam should do. Fo example, a use might ask the system to change the taget pogam in a cetain way o to foget about some paticula thing that was said ealie. This kind of communication is a pominent featue of the way pogammes talk to each othe, but is not captued by specication languages that meely addess what taget pogam is supposed to do. Fo example, suppose that at a late time the use wanted to change the EvalOctal pogam. It would be desiable if the change could be made by talking about the pogam at a high level athe than using, say, a text edito. In addition, the system should espond by indicating poblems caused by the change. Use: Change EvalOctal so that an optional minus sign is allowed to appea befoe the fist digit of the input. System: The failue value -1 is no longe guaanteed to be distinct fom the set of outputs coesponding to valid inputs. Automatic pogamming systems map a conguation of domain-specic tems (a equiement stated in tems of one of the input mediums above) into a conguation of implementation-specic tems (a pogam). Fou mechanisms cuently being pusued as the basis fo such systems ae pocedual methods, deductive methods, tansfomational methods, and inspection methods. 3.1 Pocedual Methods To date, the most successful appoach has been to simply wite a special-pupose pogam that gets the ight esults. Fo example, othe than the pasing components, most cuent compiles and pogam geneatos ae essentially pocedual in natue (although some use tansfomations to some extent). 17

21 The big advantage of pocedual methods is that they let you get o the gound fast. It is vey seldom dicult to suppot the st few desied featues. Futhemoe, you can always (ty to) modify the code to suppot any paticula additional featue. Unfotunately, as moe and moe featues ae added to a pocedual system, you each a point of apidly diminishing etuns, because the system becomes pogessively moe dicult to modify. As a esult, it is unlikely that the pocedual appoach can suppot the boad-coveage, end-use-oiented automatic pogamming systems of the futue. 3.2 Deductive Methods The poblem of synthesizing a pogam satisfying a given specication is fomally equivalent to nding a constuctive poof of the specication's satisability. This fundamental idea undelies the deductive appoach to automatic pogamming (Manna and Waldinge, 1980a). In pinciple, any method of automated deduction esolution, natual deduction, easoning about anonymous individuals can be used to suppot automatic pogamming. Unfotunately, in pactice, none of these methods ae yet capable of poving the kinds of complex theoems equied to synthesize pogams of ealistic size. Deduction is basically a poblem of seaching fo an infeence path fom some initial set of facts to a goal fact. The seach is exponential in natue because at evey step thee ae many ways fo infeence ules to be applied to facts. Cuent deductive systems cannot discove complex poofs because they ae unable to eectively contol the seach pocess. To deal with this contol poblem, deductive systems typically must adopt the assistant appoach that is, they seek advice fom the use. Unfotunately, uses who want to avoid pogamming pobably want to avoid theoem poving as well! An even moe fundamental poblem with the deductive appoach is that it is at odds with the need fo an automatic pogamming system to make a good faith eot to satisfy the \spiit" of a equiement. Fo example, the theoem-poving pocess contains no bias towad nding the poof coesponding to the most ecient pogam, o even a easonably ecient pogam. Despite these limitations, deductive methods have seveal advantages. In paticula, they ae vey geneal and quite eective, as long as they ae limited to poving simple theoems. As a esult, deductive methods ae cetain to play an impotant ole in the automatic pogamming systems of the futue. The challenge is to combine automated deduction with othe methods so that its inheent limitations can be avoided. 3.3 Tansfomational methods Tansfomational implementation systems (e.g., TI (Balze, 1985) and PDS (Cheatham, 1984)) have dominated eseach in automatic pogamming. In this appoach, 18

22 the input to the automatic pogamming system is a pogam witten in a vey high level language. A sequence of tansfomations is applied to convet this input into a low-level implementation. A tansfomation has thee pats: a patten, a set of logical applicability conditions, and an action pocedue. When an instance of the patten is found, the logical applicability conditions ae checked to see whethe the tansfomation can be applied. If the applicability conditions ae satised, the action can be evaluated to compute a new section of code, which is used to eplace the code matched by the patten. Typically, tansfomations ae coectness peseving, meaning that the matched code and its eplacement epesent logically equivalent computations. Thee ae two basic kinds of tansfomations. Some tansfomations (often called vetical tansfomations) eplace specication-like constucts (e.g., quantication ove a set) with conventional constucts (e.g., iteating ove a list). These tansfomations encode knowledge of how to implement algoithms and data stuctues. Othe tansfomations (often called hoizontal tansfomations) pefom eaangements and optimizations (e.g., moving an unchanging computation out of a loop), which do not change the level of abstaction. In pactice, these two kinds of tansfomations ae inteleaved in long sequences, passing though multiple levels of abstaction. The cental featue of tansfomational methods is the tansfomational ewite cycle. The state of the tansfomation pocess is epesented as a pogam in a widespectum epesentation that is capable of expessing both the use's input and the nal pogam. On each cycle, a tansfomational system selects a tansfomation and applies it to some place in the pogam. The cycle continues, accumulating the esults of longe and longe chains of tansfomations, until some temination condition is satised (e.g., until thee ae no moe vey high level constucts). As an example of how tansfomational implementation woks, let us follow the steps by which pat of the SETL pogam in Section 2.5 could be tansfomed into an ecient low level pogam. In paticula, we focus on the statement in EvalOctal that computes the value of a tuple of integes viewed as an octal numbe: etun +/[D*8**(#Digits-i): D in Digits(i)]; The two most impotant tansfomations that need to be applied hee ae vetical tansfomations which dene how the summation and tuple fomation opeations can be implemented. Each of these tansfomations is dened below in a simplied, infomal notation in which the applicability conditions ae expessed in English and the action pocedue is shown in the fom of a template fo the esulting code. (Italics in the patten and the esult elds denote vaiables that match against abitay pats of the pogam. <Temp> stands fo a tempoay vaiable name geneated by the action pocedue.) 19

23 name: tuple-fome patten: X := [E: V in T(I) P]; conditions: X, V, T, and I ae distinct vaiables. X does not appea in E, T, o P. esult: X := []; fo I := 1 to #T; if P then X := X with E; end fo; name: summation patten: X := +/T; conditions: X and T ae distinct vaiables. esult: X := 0; fo <Temp> := 1 to #T; X := X+T(<Temp>); end fo; Although these two tansfomations captue the essence of the implementation of the etun statement above, they cannot be diectly applied to the statement because thei pattens do not exactly match: Both tansfomations expect to match against assignment statements; the tuple-fome tansfomation expects thee to be a selection pedicate, which is missing in the statement above. (These kinds of poblems ae typical.) In ode to apply the two vetical tansfomations above, the following two hoizontal tansfomations st need to be used. The facto-out tansfomation pulls a subexpession out of a statement and ceates a sepaate assignment statement. The add-tuple-selecto tansfomation intoduces a degeneate selection pedicate (tue) into a tuple fome which does not contain a selection pedicate. name: facto-out patten: S; conditions: S is a statement containing a subexpession E. E can be evaluated sepaately befoe the est of S. esult: <Temp> := E; S <with Temp substituted fo E>; name: add-tuple-selecto patten: [E: V in Exp] conditions: none esult: [E: V in Exp tue] Applying facto-out twice and add-tuple-selecto once poduces: Temp1 := [D*8**(#Digits-i): D in Digits(i) tue]; Temp2 := +/Temp1; etun Temp2; The vetical tansfomations can then be applied poducing: 20

24 Temp1 := []; fo i := 1 to #Digits; D := Digits(i); if tue then Temp1 := Temp1 with D*8**(#Digits-i); end fo; Temp2 := 0; fo Temp3 := 1 to #Temp1; Temp2 := Temp2+Temp1(Temp3); end fo; etun Temp2; Although coect, the code poduced above is fa fom satisfactoy. The biggest poblem is that it slavishly follows the details of the initial SETL code. In ode to achieve easonable eciency, the two loops have to be meged, eliminating the computation of the intemediate tuple Temp1. This can be done using the tansfomation below. name: seial-fo-loop-combination patten: V := []; fo I := 1 to L; S1 V := V with E; S2 end fo; fo J := 1 to #V; S3 end fo; conditions: V, I, J, and E ae distinct vaiables. S1, S2, and S3 ae zeo o moe statements. S1, S2, and S3 cannot cause loop temination. S1 and S2 cannot change I. S3 cannot change J. S1 and S2 do not efe to V. Evey efeence to V in S3 is of the fom V(J). Thee ae no efeences to V in the suounding pogam. esult: fo I := 1 to L; S1 <Temp> := E; S2 S3 <with Temp substituted fo V(J)> end fo; As was the case above, this tansfomation is not quite applicable to the pogam as it stands. Fist, the following hoizontal tansfomations have to be applied in ode to get id of the unnecessay if statement and to move the assignment statement out fom between the loops. name: emove-if patten: if tue then S; conditions: none esult: S; 21