Automatic Programming Using Abstract Data Types - IJCAI
AUTOMATIC PROGRAMMING USING ABSTRACT DATA TYPES
Gerard Guiho
U n i v e r s i t e Paris Sud LRI - B a t . 490 91405 ORSAY - FRANCE ABSTRACT In t h i s paper we f i r s t t r y to c h a r a c t e r i z e one meaning of automatic programming. We consider it to be one part of the Programming environment r e l a t e d t o A r t i f i c i a l I n t e l l i g e n c e techniques. We then i l l u s t r a t e an automatic programning process, on a simple example, using an A b s t r a c t Data Type theory to which we add the not ion of schemes which are p a r t i c u l a r l y useful in program d e r i v a t i o n from Abs t r a c t Type decomposition. We conclude that a l l the concepts treated in t h i s paper must be c o n t a i ned in one way or another in any automatic programming system. However t h i s necessitates f u r t h e r study in such t h e o r e t i c a l f i e l d s as Abstract Data Type Theory, S p e c i f i c a t i o n languages, Theorem p r o vers or proof cheekers and r u l e r e w r i t i n g systems. I GENERALITIES I . I . In my o p i n i o n the concepts implied in the words "Automatic Programning" are not very precise and may even seem completly u n r e a l i s t i c . However many people, l i k e myself may consider t h a t even if they seem vague and sometimes u n r e a l i s t i c they appear worthwhile f o r s t u d y i n g . In the f i r s t part of my paper, I w i l l t r y to s p e c i f y the d e f i n i t i o n of these concepts, created by the j u x t a p o s i t i o n of the two words "Automatic" and "Programming". In Webster's d i c t i o n a r y , we can see t h a t " a u t o m a t i c " can be the o b t e n t i o n of something which can be produced w i t h o u t t h i n k i n g , by h a b i t or r e f l e x . In t h i s case, Automatic Progranming could be considered as a kind of programming methodology, which is s u f f i c i e n t to f o l l o w to o b t a i n a good program. This can only be applied in areas where the programing process is r e p e t i t i v e enough t h a t a method can grasp the mechanical aspect. In t h i s w a y . i n the b u s i n e s s - o r i e n t e d programming f i e l d , some program generators or methodologies can be considered as automatic programming. A second meaning to the word automatic concerns one a c t i o n which is done by i t s e l f . We could then look f o r a programming technique which is ent i r e l y produced by any k i n d of mechanism. This is a more A r t i f i c i a l I n t e l l i g e n c e approach. In t h i s sense we could consider b u i l d i n g a system which would receive the s p e c i f i c a t i o n of a problem as i n p u t and which w i l l give a program as o u t p u t . This f i e l d is o f t e n c a l l e d Program Synthesis. The
input s p e c i f i c a t i o n can be formal s p e c i f i c a t i o n s (as l o g i c ) [ l l [ 2] , Examples [ 3] [ 4] f 5] or Natural Language. Taking i n t o account the research which has been done on t h i s subject d u r i n g the l a s t f i v e years and my own personal experience, I t h i n k that t h i s approach i s only possible f o r r e s t r i c t e d f i e l d s of a p p l i c a t i o n and toy problems. In other cases the s p e c i f i c a t i o n language is close to a programming language and it is more a compiling technique than automatic programming. I am t h e r e fore convinced t h a t t h i s approach can be u s e f u l l o c a l l y but t h a t programming, in the general sense, w i l l never be completly automatic. A t h i r d sense to the word automatic w i l l also help us. It c h a r a c t e r i z e s one a c t i o n which is done using automatic equipment. This d i c t i o n a r y d e f i n i t i o n is in f a c t r e c u r s i v e ! ! That leaves us now to consider that it is not the a c t i o n of programming which has to be automatic but the equipment which could help do t h i s a c t i o n . L a s t l y we can i n t e r p r e t "Automatic Programming" as the programming a c t i o n using a computer, which allows us to w r i t e p r o grams in the best way p o s s i b l e " . That does not imp l y t h a t the whole programming process has to be automatic. U n f o r t u n a t e l y , t h i s d e f i n i t i o n i s too g e n e r a l . If any system used d u r i n g the programming process is r e l e v a n t to automatic programming then most of the programmers are in f a c t using automatic p r o gramming techniques w i t h o u t knowing i t . Is a t e x t e d i t o r , a compiler, a l i n k e r , . . . r e l e v a n t to automatic programming ? And is there any d i f f e r e n c e between "Automatic Programming" and "Programming Environment" ? In f a c t I consider that automatic programming is a p a r t of what is c a l l e d programming environment. It consists of the t o o l s which are the most advanced in the programming environment and which are d i r e c t l y r e l a t e d to the programmer. We are very close here to an A r t i f i c i a l I n t e l l i g e n c e paradigm because the a c t i o n of programming can be considered as one of the most d i f f i c u l t and i n t e l l i g e n t a c t i o n a human can do. S o f i s t i c a t e d t o o l s which could help the programmer d u r i n g t h i s powerful act i o n may be r e l e v a n t to the A r t i f i c i a l I n t e l l i g e n ce f i e l d . However, even i f the l i n e between A r t i f i c i a l I n t e l l i g e n c e and c l a s s i c a l Computer Science is not r e a l l y precise in Automatic Programming, I c o n s i der t h a t it is a domain in which many d i f f e r e n t
2 G. Guiho
A r t i f i c i a l I n t e l l i g e n c e techniques can be extreme ly u s e f u l . This must be a challenge f o r A r t i f i c i a l I n t e l l i g e n c e people. I t i s not a coincidence i f the f i r s t and most powerful programming environments came from the A r t i f i c i a l I n t e l l i g e n c e community, (lnterlisp, Maclisp...) 1.2. I w i l l summarize some f i e l d s of A r t i f i c i a l I n t e l l i g e n c e and j u s t give some areas where they could be p r o f i t a b l e in automatic programming. - Natural Language Understanding—This subf i e l d could be very u s e f u l , not in the command to be given to a system but to help the programmer in the various commands and u t i l i t i e s of the program ming environment. For an experienced programmer, the the commands he knows have to be very s h o r t . They are g e n e r a l l y keys. The problem is that when we want to explore some new p o s s i b i l i t i e s , we do not know p r e c i s e l y the keys or the successions of keys to use f o r these new p o s s i b i l i t i e s . Looking through the documentation (even in l i n e ) is some times b o r i n g . The "a propos" command under emacs is u s e f u l but is only a key word search. The develop ment of a n a t u r a l language i n t e r f a c e would allow a s o p h i s t i c a t e d help system which would then be very effective. - Expert Systems—I do not t h i n k an expert system can be constructed at the present in the program-creating process because i t i s too d i f f i c u l t and may even be outside of c l a s s i c a l expert systems approach. However, in many parts of the programming process an expert system viewed as an a s s i s t a n t can be used. These systems have to be se parate t o o l s : . The o r g a n i s a t i o n of large programs. How to f i n d some i n f o r m a t i o n in a large base of programs or data types ? What has been done u n t i l now and what would be the most s u i t a b l e to do now e t c . . . ? I t i s a knowledge-based o r i e n t e d system [ 6 ] . . The process of transforming programs [7 ] . . R e s t r i c t e d areas. When the f i e l d is very small and the d e r i v a t i o n of the program from the s p e c i f i c a t i o n very easy, i t would b e f r u i t f u l t o design some small expert systems. . The v a l i d a t i o n of programs using t e s t s e t s . The generation of the t e s t set f o r programs is ne ver completly s a t i s f a c t o r y and is a d i f f i c u l t a r t . Testing a program can be r e l e v a n t to Expert System techniques. - Theorem Proving—Testing programs are not s u f f i c i e n t and in the f u t u r e most of the programs w i l l have to be proven, at l e a s t p a r t i a l l y . Many i n t e r a c t i v e systems w i l l have to be designed in or der to help the programmer prove the correctness of t h i s work. This domain is h i g h l y r e l a t e d to Theore t i c a l Computer Science because most of the concepts in languages or programs have not yet been s u f f i c i e n t l y s t u d i e d to be used in p r a c t i v e f o r r e a l programs. Some systems as GYPSY [ 8 ] , STP [ 9 ] , FORMEL [ 10] are milestones towards t h i s approach. The r e s t of t h i s paper w i l l t r y to show t h a t even f o r small examples, the proof can be long and the m a t e r i a l involved very s o p h i s t i c a t e d . - Other techniques—Many other aspects which only use h e u r i s t i c s can be very u s e f u l in the p r o -
granrning process. I w i l l j u s t give some of them here but t h i s is not e x h a u s t i v e . -Help d u r i n g the programming process—Proposing program schemes, data decomposition, programs which are " c l o s e " to the one the programmer is a c t u a l l y doing e t c . . . - I n t e l l i g e n t d i s p l a y of a l l the i n f o r m a t i o n needed d u r i n g the programming process (a screen with a multiple-window o r i e n t e d e d i t o r ) . - Organisation f o r work s c h e d u l i n g . II PROGRAM CONSTRUCTION We will.now describe one proposal f o r a program c o n s t r u c t i o n technique. It is not aimed to be e n t i r e l y general but shows many concepts which, in one form or another, are necessary in every f u t u r e auto matic programming system. It is now beginning to be admitted that a l i brary which is useful in the programming process must c o n t a i n both data and programs. A l l these ob j e c t s have to be encapsulated in modules. Some of these modules i n v o l v e d e s c r i p t i o n s of powerful data types w i t h basic operators ; some others i n v o l v e sets of programs w i t h one common f u n c t i o n a l i t y . A i l these modules contains two p a r t s . One which shows t h a t which is v i s i b l e outside of the module, which attempts to describe the s p e c i f i c a t i o n of the manner in which to use i t . The second p a r t des c r i b e s how e f f e c t i v e l y the elements of the modules are implemented. This is one of the most important aspects of ADA w i t h the PACKAGE and PACKAGE BODY p a r t s . Generally the d e s c r i p t i o n p a r t (which we w i l l c a l l the s p e c i f i c a t i o n p a r t ) only contains the p r o f i l e of the operations which are v i s i b l e outside the module and few other h e l p f u l things f o r type chee k i n g and documentation. However, even if t h i s aspect c o n s t i t u t e s a major improvement, it does not allows us to produce p r o o f s . The nature of the objects which have to be grasped in our system can be represented as :
G. Guiho
1.
Data Type S p e c i f i c a t i o n (DS)
We use Algebraic Abstract Data Types in an ex tended manner which w i l l be described in s e c t i o n l l l . According to the t h e o r y , an Algebraic Abstract Data Type s p e c i f i c a t i o n denotes a class of Algebra Alg ∑ and in our theory t h i s class has one i n i t i a l algebra T ∑ . ( i e f o r each algebra A in Alg ∑ there e x i s t s one unique morphism h : T∑+A. 2.
Procedure s p e c i f i c a t i o n (PS)
In a f i r s t approximation we w i l l consider spe c i f i c a t i o n s in an algebraic manner. This w i l l be easier f o r proofs but it may lead to s p e c i f i c a t i o n s which are not r e a l l y readable. I consider that there does not e x i s t f o r the moment an e f f e c t i v e , convenient s p e c i f i c a t i o n language. If one such language would e x i s t , i t s semantic would have to be expressed a l g e b r a i c a l l y , but for our purposes here I have chosen to express it d i r e c t l y in i t s a l g e b r a i c form. 4.
which is expressed in a n a t u r a l language manner : a. Knowing a f a m i l y of Data Types S p e c i f i c a t i o n , b u i l d a procedure s p e c i f i c a t i o n using any i n t u i t i v e method and then derive a program.
Data Implementation (DI)
Generally the Data Implementation is not v i ' . s i b l e to the user (and it must not be v i s i b l e ) . We w i l l consider t h a t the Data Implementation r e p r e sents one of the algebra in Alg ∑ denoted by the ab s t r a c t type s p e c i f i c a t i o n . The f a c t that there ex i s t s one morphism between T ∑ (which is a p a r t i c u l a r Algebra of Terms) and A helps us prove proper t i e s or theorems on the type using T∑.. These p r o p e r t i e s w i l l be p r o p e r t i e s of any implementation. Of course the correctness of the implementation has to be provenin the same ways t h a t many proper t i e s concerning abstract s p e c i f i c a t i o n . That is done once f o r a l l and could be considered as the r e s p o n s a b i l i t y of the data type designer. Note that our class of algebra is the class of f i n i t e l y ge nerated algebras so that we can use term r e w r i t i n g and s t r u c t u r a l i n d u c t i o n for producing p r o o f . 3.
3
The problem whith t h i s method is that even f o r short s p e c i f i c a t i o n s , the r i s k of e r r o r is high ( i t may be even higher than d i r e c t l y d e r i v i n g the program if the s p e c i f i c a t i o n language is obscure). Subsequently the program w i l l be wrong and if the procedure s p e c i f i c a t i o n represents in some sense a " c o n t r a c t " , t h i s could be dangerous. One other p r o blem is that only when the program is e f f e c t i v e l y tested that some e r r o r s w i l l occur. It might not be easy to see where they correspond to a mistake in the s p e c i f i c a t i o n . The r i s k is that the programmer w i l l d i r e c t l y change the program !! One could say that we have some executable s p e c i f i c a t i o n s but the other r i s k is t h a t the program might e a s i l y f o l l o w the s p e c i f i c a t i o n and could be h i g h l y u n e f f e c t i v e . b. Knowing a f a m i l y of Data Type S p e c i f i c a t i o n s , b u i l d a procedure s p e c i f i c a t i o n , then b u i l d a program separately and prove the correctness of the program versus the s p e c i f i c a t i o n s .
Procedure implementation (PI)
F i r s t we need a programming language w i t h a w e l l - d e f i n e d semantic in order to produce p r o o f s . Section IV w i l l describe such a toy language. Given a program P w r i t t e n in such a language and proving i t s correctness may not be s u f f i c i e n t . These p r o p e r t i e s are proven in f a c t , in an exten s i o n of T , the i n i t i a l term algebra : T ∑ + P and the program w i l l a c t u a l l y be used in an algebra A + P. The f a c t t h a t there e x i s t s an horaomorphism h : T∑-+A does not prove that it can be n a t u r a l l y extended to an homomorphism n : T∑ + P --> A + P. This has to be proven again and it can be done either : - By proving it on each program !! - By r e s t r i c t i n g the form of programs or by d i r e c t i n g the program c o n s t r u c t i o n such t h a t any morphism can be extended. - By using monomorphic a b s t r a c t types. 5.
Program c o n s t r u c t i o n
Two main methods can be used in b u i l d i n g p r o cedures concerning a problem we have in mind or
Here we have more chance to make e r r o r s in the two c o n s t r u c t i o n s but the e r r o r s w i l l not be neces s a r i l y the same. The proof mechanism w i l l help us to c o r r e c t the two p a r t s . In my experience I always made aproximately the same number of mistakes in w r i t i n g programs or s p e c i f i c a t i o n s . T r y i n g to prove the correctness always leads me to reconsider b o t h . The r i s k i s that i f the s p e c i f i c a t i o n i s too f a r from the implementation ( h i g h l y non executable spe c i f i c a t i o n f o r instance) the proof could be very difficult. One other way would be to e x t r a c t a u t o m a t i c a l ly the t e s t set from the s p e c i f i c a t i o n in order to t e s t the program. [ 1 1 ] , This is the type of program c o n s t r u c t i o n t e c h -
4 G. Guiho
nique we wil use in f u r t h e r sections w i t h a s y s t e matic methodology f o r b u i l d i n g programs. It could help us reduce the amount of e r r o r s when we t r y to express our i n t u i tion.Wewill use one toy example a l l along (the gcd problem) because it is s u f f i c i e n t l y complex, the concepts s i g n i f i c a n t and s u f f i c i e n t l y short to be shown in one paper. I l l ALGEBRAIC ABSTRACT DATA TYPeS We w i l l use the now c l a s s i c a l theory of abst r a c t types which is d i r e c t l y i n s p i r e d from ADJ [ 12] , Goguen [ 1 3l [14] , Broy & W i r s i n g [ 1 5] , complemented by work from B i d o i t [ 16] , Kaplan [ 17] , myself, Boisson and Pavot [ 18] . Our addenda concern p r i n c i p a l l y the p r e s e n t a t i o n of t y p e , the use of p o s i t i v e c o n d i t i o n a l axioms and the e r r o r mechanism. The schemes are d i r e c t extensions of the decomposition schemes of C. Gresse [ 19] (same proceedings). An a b s t r a c t type is given by : 1. A s i g n a t u r e represented by a set S of Sorts and a set ∑. of symbols w i t h an a r i t y in (S) . This d i f f e r s from the usual theory where the a r i t y belongs to S ). We use, as Goguen does, overloading and coercion e x t e n s i v e l y . The n o t a t i o n of operators is s i m i l a r to OBJ ( \2\ . 2.
A set of p o s i t i v e c o n d i t i o n a l axioms.
These axioms (as in Goguen [ 14])contains the s o r t in which the equation has to be considered. The operators are raultioperators and can have more than one o u t p u t . I n f a c t , t h e i r i n t e r p r e t a t i o n i s a f u n c t i o n from the domaines of t h e i r input to the union of domaines of t h e i r output (which have to be d i s j o i n t e d ) . The operators have to be t o t a l on the ground terms but can be p a r t i a l on terms w i t h v a r i a b l e s . Using some kinds of p r e s e n t a t i o n and w i t h some p r o p e r t i e s , it can be shown that there can e x i s t one i n i t i a l algebra of terms in the class of s p e c i f i e d a l g e b r a s . More d e t a i l s are a v a i l a b l e in Boisson & A l l [ 18] . 3.
Some i n d u c t i o n schemes
These i n d u c t i o n schemes w i l l be u s e f u l d u r i n g the c o n s t r u c t i o n and the proof process. They w i l l be described more p r e c i s e l y in the a p p r o p r i a t e sect i o n . They correspond in a sense to the i n d u c t i o n schemata in A f f i r m [ 20] . 4.
Some theorems
This p a r t contains p r o p e r t i e s or theorems which can be deduced from the axioms. These theorems may be u s e f u l in the p r o o f s . F i g . 1 describes the s p e c i f i c a t i o n of the pos i t i v e i n t e g e r s type. We assume t h a t the type Bool which represents the booleans is known somewhere else w i t h a l l i t ' s s u i t a b l e operations and axioms. We can make the f o l l o w i n g remarks on t h i s example : - We d e f i n e here three s o r t s . The zero s o r t is
very convenient f o r c o n s t r u c t i n g programs and f o r specifying t h i s type. - The n o t a t i o n i n t = i n t , + z e r o is j u s t syntact i c . I t i s t o avoid w r i t i n g i n t , zero everywhere in the type. - The underscore ( _) shows the places of the operands w i t h the d i s f i x n o t a t i o n of o p e r a t o r s . - There are p l e n t y of overloadings in t h i s spec i f i c a t i o n . For instance there are four + operators! - When there is more than one s o r t in the l e f t p a r t of the a r i t y of one o p e r a t o r , it means that it is a m u l t i o p e r a t o r . For instance P has two o u t p u t s : i n t and zero. - There e x i s t s also multiaxioms (a s y n t a c t i c l e v e l ) in the way that an axiom is repeated when there is some ambiguity in the type of operators or when there are more than one s o r t before the axiom. For instance : int : x + 0 = x means zero : x + 0 = x int : x + 0 = x or bool : x < 0 - False " bool : x : zero < 0 = False bool : x : i n t < 0 = False See f i g u r e 1 next page f o r p r e s e n t a t i o n of the type. - There are c o n d i t i o n a l axioms l i k e : x egal y =* x oiv y = True In f a c t a c o r r e c t d e f i n i t i o n would be : x egal y = True --> d i v y = True We accepted t h i s s y n t a c t i c s i m p l i f i c a t i o n , in order not to overload the axioms but they are a l l positive conditional. - We can see w i t h some examples how the i n i t i a l term algebra i s . . 0 is in s o r t zero . sO is in s o r t i n t and [ s n 0 | f o r n > 1) are in int because s is not a m u l t i o p e r a t o r . These terms can be considered as r e p r e s e n t a t i v e of classes of terms i n i n t . psO is in zero because of the f i r s t axiom . ppsO does not e x i s t because p does not apply to s o r t zero . sO - ssO = 0 - sO by axiom 3 = erint by axiom 4 Then i t i s i n i n t e r . The term sO + (sO - sssO) does not e x i s t ! It can be proven t h a t there is no ambiguity f o r any ground term and then t h i s term algebra is i n i tial. - The axiom i n t e r : x = e r i n t c o l l e c t s a l l the e r r o r terms i n t o one s i n g l e class w i t h o u t avoiding a l l the c l a s s i c a l problems w i t h the e r r o r s i n abst r a c t data t y p e . - It is necessary f o r the evaluator to do type cheeking d u r i n g the e v a l u a t i o n process in order to choose the c o r r e c t axioms or to detect terms which do not e x i s t . In f a c t these terms w i l l not be gener a t e d w i t h c o r r e c t programs. I t might b e p o s s i b l e here to add some operators which could be a p p l i e d to i n t e r to get e r r o r propagation and these terms would then e x i s t ( f o r instance : + : ( i n t , i n t e r ) ( i n t , i n t e r ) -> i n t , i n t e r in s p i t e of the e x i s t i n g one !) - An equation can be used i f f i t s two sides e x i s t and have the same t y p e . Then, f o r i n s t a n c e , the t h i r d theorem
G. Guiho 5
6 G. Guiho
G. Guiho 7
8 G. Guiho
G. Guiho 9
This example shows that the proof is not very easy, even f o r such a simple example because of the theorems or lemmas which have to be used. In our o p i n i o n , t h i s kind of proof cannot be done a u t o m a t i c a l l y by a present theorem prover ( w i t h the d i s c o very of lemmas).A nice proof checher would be p r e ferable. V CONCLUSION This method, t h i s toy example and the simple proof do not intend to describe a l l the t o o l s which have to be in such a system, l.'e claim here that when we t r y to be very precise (and we have to when we b u i l d c o r r e c t programs) a l l the concepts which belong to t h i s paper have to be contained in one way or anotlier in the system, which leads to many d i f f i c u l t t h e o r e t i c a l problems not completely solved at t h i s time. What we can hope f o r in the near f u t u r e is the e f f e c t i v e implementation of such p a r t i a l systems which w i l l become more and more p o w e r f u l , coupled w i t h meaningful research on abstract data type t h e o r y , S p e c i f i c a t i o n languages, Theorem provers or proof cheekers and r u l e r e w r i t i n g systems. 'ACKNOWLEDGMENTS .'' The authors wishes to thank M. B i d o i t , M.C. M. C. Gaudel, C. Gresse, S. Kaplan f o r many e x c i t i n g discussions on t h i s s u b j e c t . REFERENCES [ 1 J Manna,Z. & R. Waldinger, "Deductive synthesis of the u n i f i c a t i o n A l g o r i t h m " In Computer Program synthesis methodologies. A. Biermann & G. Guiho E d i t o r s . D. R e i d e l ' P u b l i s h i n g Co 1983. [2 ] B i d o i t , M.& C. Gresse & G. Guiho, "A system which synthesiezs array manipulating programs from s p e c i f i c a t i o n s . Proc 6th 1JCAI-79. Tokyo pp. 63-65. [3 ] K o d r a t o f f , Y, from a f i n i t e gram shceme". I n f . Sciences
"A class of functions synthesized number of examples and a LISP p r o I n t e r n a t i o n a l J. of Comp. and 8, 1979, pp. 489-521.
[4 ] Jouannaud,J. P. & G. Guiho, "SISP/l An i n t e r a n t i v e system able to synthesize f u n c t i o n s form examples". Proc 5th I J C A I . M . I . T . , August, 1977. [5] Biermann, A. W. & D. R. Smith, "The h i e r a r c h i c a l synthesis of LISP scanning programs". I n f o r m a t i o n processing 77, North H o l l a n d , 1977, pp. 41-45. [6 ] M o r i c o n i , M. "A d e s i g n e r / v e r i f i e r ' s A s s i s t a n t " IEEE Transactions on Software Engineering, Vol Se-5 N° 4, J u l y , 1979. [/ ]Barstow, D. R. "Automatic Construction of A l gorithm and Data S t r u c t u r e s using a Knowledge base of Programming Rules". PHD D i s s e r t a t i o n , Stanford Memo A1M-308, 1977.
[8 ]Good D. & A l l , "Report on the language Gypsy" Version 2. 0. I n s t i t u t e f o r computing Science and computer a p p l i c a t i o n s . The U n i v e r s i t y of Texas. A u s t i n Texas 1978. [9 ]Shostak, R. E. and R. Schwartz, Mel 1iard-Smith P.M. STP : ?A Mechanized Logic f o r s p e c i f i c a t i o n and v e r i f i c a t i o n " . 6th conference on Automated Deduction, NY 1982. [ l 0 ] H u e t , G. " P r o j e t Formel", INRIA, France 1983. [ l l ] B o u g e , L. " M o d e l i s a t i o n de la n o t i o n de t e s t et de programmes". These 3e cycle LITP Paris Novembre 1982 [ 12]Thatcher, J. W. and E. G. Wagner and J. B. W r i g h t , " S p e c i f i c a t i o n of Abstract Types using c o n d i t i o n a l axioms , IBM report 6214, September 1976. [13]Coguen, J. A. and J. W. Thatcher and E. G. Wagner, "An I n i t i a l Algebra approach to the s p e c i f i c a t i o n , correctness and Implementation of abstract data type. IBM r e p o r t KC 6487, October, 1976. [l4]Goguen, J. "Order Sorted Algebras : Exceptions and Error S o r t s , coercion and Overloaded operat o r s . Report IT 14, S . R . I . December, 1978. [ 15]Wirsing, M. and M. Broy, " A b s t r a c t data types as l a t t i c e s of f i n i t e l y generated Models". 9th MFCS ,Rydjyna, September, 1980. [ l 6 ] B i d o i t , M; "Algebraic Data Types. S t r u c t u r e d S p e c i f i c a t i o n s and F a i r P r e s e n t a t i o n s " . C o l l o que AFCET/MA , P a r i s , March, 1982. [ 1 7 ] K a p l a n , S. "Un langage de s p e c i f i c a t i o n de t y pes a b s t r a i t s a l g e b r i q u e s " . These 3e cycle L R I - Orsay, F e v r i e r , 1983. [ 18]Boisson, F. and G. Guiho and D. Pavot, " A l g e bres a Operateurs M u l t i t y p e s " . Rapport i n t e r n e LRI-Orsay, Mai, 1983. [19]Gresse, C. "Automatic programming from Data Type decomposition p a t e r n s " . 8th IJCAI-83, K a r l sruhe, August, 1983. [20]Loeckx, J . "Proving P r o p e r t i e s o f a l g o r i t h m i c S p e c i f i c a t i o n s of Abstract data Types in AFFIRM". Memo-29-JL U.S.C July 1980.
Gerard Guiho
U n i v e r s i t e Paris Sud LRI - B a t . 490 91405 ORSAY - FRANCE ABSTRACT In t h i s paper we f i r s t t r y to c h a r a c t e r i z e one meaning of automatic programming. We consider it to be one part of the Programming environment r e l a t e d t o A r t i f i c i a l I n t e l l i g e n c e techniques. We then i l l u s t r a t e an automatic programning process, on a simple example, using an A b s t r a c t Data Type theory to which we add the not ion of schemes which are p a r t i c u l a r l y useful in program d e r i v a t i o n from Abs t r a c t Type decomposition. We conclude that a l l the concepts treated in t h i s paper must be c o n t a i ned in one way or another in any automatic programming system. However t h i s necessitates f u r t h e r study in such t h e o r e t i c a l f i e l d s as Abstract Data Type Theory, S p e c i f i c a t i o n languages, Theorem p r o vers or proof cheekers and r u l e r e w r i t i n g systems. I GENERALITIES I . I . In my o p i n i o n the concepts implied in the words "Automatic Programning" are not very precise and may even seem completly u n r e a l i s t i c . However many people, l i k e myself may consider t h a t even if they seem vague and sometimes u n r e a l i s t i c they appear worthwhile f o r s t u d y i n g . In the f i r s t part of my paper, I w i l l t r y to s p e c i f y the d e f i n i t i o n of these concepts, created by the j u x t a p o s i t i o n of the two words "Automatic" and "Programming". In Webster's d i c t i o n a r y , we can see t h a t " a u t o m a t i c " can be the o b t e n t i o n of something which can be produced w i t h o u t t h i n k i n g , by h a b i t or r e f l e x . In t h i s case, Automatic Progranming could be considered as a kind of programming methodology, which is s u f f i c i e n t to f o l l o w to o b t a i n a good program. This can only be applied in areas where the programing process is r e p e t i t i v e enough t h a t a method can grasp the mechanical aspect. In t h i s w a y . i n the b u s i n e s s - o r i e n t e d programming f i e l d , some program generators or methodologies can be considered as automatic programming. A second meaning to the word automatic concerns one a c t i o n which is done by i t s e l f . We could then look f o r a programming technique which is ent i r e l y produced by any k i n d of mechanism. This is a more A r t i f i c i a l I n t e l l i g e n c e approach. In t h i s sense we could consider b u i l d i n g a system which would receive the s p e c i f i c a t i o n of a problem as i n p u t and which w i l l give a program as o u t p u t . This f i e l d is o f t e n c a l l e d Program Synthesis. The
input s p e c i f i c a t i o n can be formal s p e c i f i c a t i o n s (as l o g i c ) [ l l [ 2] , Examples [ 3] [ 4] f 5] or Natural Language. Taking i n t o account the research which has been done on t h i s subject d u r i n g the l a s t f i v e years and my own personal experience, I t h i n k that t h i s approach i s only possible f o r r e s t r i c t e d f i e l d s of a p p l i c a t i o n and toy problems. In other cases the s p e c i f i c a t i o n language is close to a programming language and it is more a compiling technique than automatic programming. I am t h e r e fore convinced t h a t t h i s approach can be u s e f u l l o c a l l y but t h a t programming, in the general sense, w i l l never be completly automatic. A t h i r d sense to the word automatic w i l l also help us. It c h a r a c t e r i z e s one a c t i o n which is done using automatic equipment. This d i c t i o n a r y d e f i n i t i o n is in f a c t r e c u r s i v e ! ! That leaves us now to consider that it is not the a c t i o n of programming which has to be automatic but the equipment which could help do t h i s a c t i o n . L a s t l y we can i n t e r p r e t "Automatic Programming" as the programming a c t i o n using a computer, which allows us to w r i t e p r o grams in the best way p o s s i b l e " . That does not imp l y t h a t the whole programming process has to be automatic. U n f o r t u n a t e l y , t h i s d e f i n i t i o n i s too g e n e r a l . If any system used d u r i n g the programming process is r e l e v a n t to automatic programming then most of the programmers are in f a c t using automatic p r o gramming techniques w i t h o u t knowing i t . Is a t e x t e d i t o r , a compiler, a l i n k e r , . . . r e l e v a n t to automatic programming ? And is there any d i f f e r e n c e between "Automatic Programming" and "Programming Environment" ? In f a c t I consider that automatic programming is a p a r t of what is c a l l e d programming environment. It consists of the t o o l s which are the most advanced in the programming environment and which are d i r e c t l y r e l a t e d to the programmer. We are very close here to an A r t i f i c i a l I n t e l l i g e n c e paradigm because the a c t i o n of programming can be considered as one of the most d i f f i c u l t and i n t e l l i g e n t a c t i o n a human can do. S o f i s t i c a t e d t o o l s which could help the programmer d u r i n g t h i s powerful act i o n may be r e l e v a n t to the A r t i f i c i a l I n t e l l i g e n ce f i e l d . However, even i f the l i n e between A r t i f i c i a l I n t e l l i g e n c e and c l a s s i c a l Computer Science is not r e a l l y precise in Automatic Programming, I c o n s i der t h a t it is a domain in which many d i f f e r e n t
2 G. Guiho
A r t i f i c i a l I n t e l l i g e n c e techniques can be extreme ly u s e f u l . This must be a challenge f o r A r t i f i c i a l I n t e l l i g e n c e people. I t i s not a coincidence i f the f i r s t and most powerful programming environments came from the A r t i f i c i a l I n t e l l i g e n c e community, (lnterlisp, Maclisp...) 1.2. I w i l l summarize some f i e l d s of A r t i f i c i a l I n t e l l i g e n c e and j u s t give some areas where they could be p r o f i t a b l e in automatic programming. - Natural Language Understanding—This subf i e l d could be very u s e f u l , not in the command to be given to a system but to help the programmer in the various commands and u t i l i t i e s of the program ming environment. For an experienced programmer, the the commands he knows have to be very s h o r t . They are g e n e r a l l y keys. The problem is that when we want to explore some new p o s s i b i l i t i e s , we do not know p r e c i s e l y the keys or the successions of keys to use f o r these new p o s s i b i l i t i e s . Looking through the documentation (even in l i n e ) is some times b o r i n g . The "a propos" command under emacs is u s e f u l but is only a key word search. The develop ment of a n a t u r a l language i n t e r f a c e would allow a s o p h i s t i c a t e d help system which would then be very effective. - Expert Systems—I do not t h i n k an expert system can be constructed at the present in the program-creating process because i t i s too d i f f i c u l t and may even be outside of c l a s s i c a l expert systems approach. However, in many parts of the programming process an expert system viewed as an a s s i s t a n t can be used. These systems have to be se parate t o o l s : . The o r g a n i s a t i o n of large programs. How to f i n d some i n f o r m a t i o n in a large base of programs or data types ? What has been done u n t i l now and what would be the most s u i t a b l e to do now e t c . . . ? I t i s a knowledge-based o r i e n t e d system [ 6 ] . . The process of transforming programs [7 ] . . R e s t r i c t e d areas. When the f i e l d is very small and the d e r i v a t i o n of the program from the s p e c i f i c a t i o n very easy, i t would b e f r u i t f u l t o design some small expert systems. . The v a l i d a t i o n of programs using t e s t s e t s . The generation of the t e s t set f o r programs is ne ver completly s a t i s f a c t o r y and is a d i f f i c u l t a r t . Testing a program can be r e l e v a n t to Expert System techniques. - Theorem Proving—Testing programs are not s u f f i c i e n t and in the f u t u r e most of the programs w i l l have to be proven, at l e a s t p a r t i a l l y . Many i n t e r a c t i v e systems w i l l have to be designed in or der to help the programmer prove the correctness of t h i s work. This domain is h i g h l y r e l a t e d to Theore t i c a l Computer Science because most of the concepts in languages or programs have not yet been s u f f i c i e n t l y s t u d i e d to be used in p r a c t i v e f o r r e a l programs. Some systems as GYPSY [ 8 ] , STP [ 9 ] , FORMEL [ 10] are milestones towards t h i s approach. The r e s t of t h i s paper w i l l t r y to show t h a t even f o r small examples, the proof can be long and the m a t e r i a l involved very s o p h i s t i c a t e d . - Other techniques—Many other aspects which only use h e u r i s t i c s can be very u s e f u l in the p r o -
granrning process. I w i l l j u s t give some of them here but t h i s is not e x h a u s t i v e . -Help d u r i n g the programming process—Proposing program schemes, data decomposition, programs which are " c l o s e " to the one the programmer is a c t u a l l y doing e t c . . . - I n t e l l i g e n t d i s p l a y of a l l the i n f o r m a t i o n needed d u r i n g the programming process (a screen with a multiple-window o r i e n t e d e d i t o r ) . - Organisation f o r work s c h e d u l i n g . II PROGRAM CONSTRUCTION We will.now describe one proposal f o r a program c o n s t r u c t i o n technique. It is not aimed to be e n t i r e l y general but shows many concepts which, in one form or another, are necessary in every f u t u r e auto matic programming system. It is now beginning to be admitted that a l i brary which is useful in the programming process must c o n t a i n both data and programs. A l l these ob j e c t s have to be encapsulated in modules. Some of these modules i n v o l v e d e s c r i p t i o n s of powerful data types w i t h basic operators ; some others i n v o l v e sets of programs w i t h one common f u n c t i o n a l i t y . A i l these modules contains two p a r t s . One which shows t h a t which is v i s i b l e outside of the module, which attempts to describe the s p e c i f i c a t i o n of the manner in which to use i t . The second p a r t des c r i b e s how e f f e c t i v e l y the elements of the modules are implemented. This is one of the most important aspects of ADA w i t h the PACKAGE and PACKAGE BODY p a r t s . Generally the d e s c r i p t i o n p a r t (which we w i l l c a l l the s p e c i f i c a t i o n p a r t ) only contains the p r o f i l e of the operations which are v i s i b l e outside the module and few other h e l p f u l things f o r type chee k i n g and documentation. However, even if t h i s aspect c o n s t i t u t e s a major improvement, it does not allows us to produce p r o o f s . The nature of the objects which have to be grasped in our system can be represented as :
G. Guiho
1.
Data Type S p e c i f i c a t i o n (DS)
We use Algebraic Abstract Data Types in an ex tended manner which w i l l be described in s e c t i o n l l l . According to the t h e o r y , an Algebraic Abstract Data Type s p e c i f i c a t i o n denotes a class of Algebra Alg ∑ and in our theory t h i s class has one i n i t i a l algebra T ∑ . ( i e f o r each algebra A in Alg ∑ there e x i s t s one unique morphism h : T∑+A. 2.
Procedure s p e c i f i c a t i o n (PS)
In a f i r s t approximation we w i l l consider spe c i f i c a t i o n s in an algebraic manner. This w i l l be easier f o r proofs but it may lead to s p e c i f i c a t i o n s which are not r e a l l y readable. I consider that there does not e x i s t f o r the moment an e f f e c t i v e , convenient s p e c i f i c a t i o n language. If one such language would e x i s t , i t s semantic would have to be expressed a l g e b r a i c a l l y , but for our purposes here I have chosen to express it d i r e c t l y in i t s a l g e b r a i c form. 4.
which is expressed in a n a t u r a l language manner : a. Knowing a f a m i l y of Data Types S p e c i f i c a t i o n , b u i l d a procedure s p e c i f i c a t i o n using any i n t u i t i v e method and then derive a program.
Data Implementation (DI)
Generally the Data Implementation is not v i ' . s i b l e to the user (and it must not be v i s i b l e ) . We w i l l consider t h a t the Data Implementation r e p r e sents one of the algebra in Alg ∑ denoted by the ab s t r a c t type s p e c i f i c a t i o n . The f a c t that there ex i s t s one morphism between T ∑ (which is a p a r t i c u l a r Algebra of Terms) and A helps us prove proper t i e s or theorems on the type using T∑.. These p r o p e r t i e s w i l l be p r o p e r t i e s of any implementation. Of course the correctness of the implementation has to be provenin the same ways t h a t many proper t i e s concerning abstract s p e c i f i c a t i o n . That is done once f o r a l l and could be considered as the r e s p o n s a b i l i t y of the data type designer. Note that our class of algebra is the class of f i n i t e l y ge nerated algebras so that we can use term r e w r i t i n g and s t r u c t u r a l i n d u c t i o n for producing p r o o f . 3.
3
The problem whith t h i s method is that even f o r short s p e c i f i c a t i o n s , the r i s k of e r r o r is high ( i t may be even higher than d i r e c t l y d e r i v i n g the program if the s p e c i f i c a t i o n language is obscure). Subsequently the program w i l l be wrong and if the procedure s p e c i f i c a t i o n represents in some sense a " c o n t r a c t " , t h i s could be dangerous. One other p r o blem is that only when the program is e f f e c t i v e l y tested that some e r r o r s w i l l occur. It might not be easy to see where they correspond to a mistake in the s p e c i f i c a t i o n . The r i s k is that the programmer w i l l d i r e c t l y change the program !! One could say that we have some executable s p e c i f i c a t i o n s but the other r i s k is t h a t the program might e a s i l y f o l l o w the s p e c i f i c a t i o n and could be h i g h l y u n e f f e c t i v e . b. Knowing a f a m i l y of Data Type S p e c i f i c a t i o n s , b u i l d a procedure s p e c i f i c a t i o n , then b u i l d a program separately and prove the correctness of the program versus the s p e c i f i c a t i o n s .
Procedure implementation (PI)
F i r s t we need a programming language w i t h a w e l l - d e f i n e d semantic in order to produce p r o o f s . Section IV w i l l describe such a toy language. Given a program P w r i t t e n in such a language and proving i t s correctness may not be s u f f i c i e n t . These p r o p e r t i e s are proven in f a c t , in an exten s i o n of T , the i n i t i a l term algebra : T ∑ + P and the program w i l l a c t u a l l y be used in an algebra A + P. The f a c t t h a t there e x i s t s an horaomorphism h : T∑-+A does not prove that it can be n a t u r a l l y extended to an homomorphism n : T∑ + P --> A + P. This has to be proven again and it can be done either : - By proving it on each program !! - By r e s t r i c t i n g the form of programs or by d i r e c t i n g the program c o n s t r u c t i o n such t h a t any morphism can be extended. - By using monomorphic a b s t r a c t types. 5.
Program c o n s t r u c t i o n
Two main methods can be used in b u i l d i n g p r o cedures concerning a problem we have in mind or
Here we have more chance to make e r r o r s in the two c o n s t r u c t i o n s but the e r r o r s w i l l not be neces s a r i l y the same. The proof mechanism w i l l help us to c o r r e c t the two p a r t s . In my experience I always made aproximately the same number of mistakes in w r i t i n g programs or s p e c i f i c a t i o n s . T r y i n g to prove the correctness always leads me to reconsider b o t h . The r i s k i s that i f the s p e c i f i c a t i o n i s too f a r from the implementation ( h i g h l y non executable spe c i f i c a t i o n f o r instance) the proof could be very difficult. One other way would be to e x t r a c t a u t o m a t i c a l ly the t e s t set from the s p e c i f i c a t i o n in order to t e s t the program. [ 1 1 ] , This is the type of program c o n s t r u c t i o n t e c h -
4 G. Guiho
nique we wil use in f u r t h e r sections w i t h a s y s t e matic methodology f o r b u i l d i n g programs. It could help us reduce the amount of e r r o r s when we t r y to express our i n t u i tion.Wewill use one toy example a l l along (the gcd problem) because it is s u f f i c i e n t l y complex, the concepts s i g n i f i c a n t and s u f f i c i e n t l y short to be shown in one paper. I l l ALGEBRAIC ABSTRACT DATA TYPeS We w i l l use the now c l a s s i c a l theory of abst r a c t types which is d i r e c t l y i n s p i r e d from ADJ [ 12] , Goguen [ 1 3l [14] , Broy & W i r s i n g [ 1 5] , complemented by work from B i d o i t [ 16] , Kaplan [ 17] , myself, Boisson and Pavot [ 18] . Our addenda concern p r i n c i p a l l y the p r e s e n t a t i o n of t y p e , the use of p o s i t i v e c o n d i t i o n a l axioms and the e r r o r mechanism. The schemes are d i r e c t extensions of the decomposition schemes of C. Gresse [ 19] (same proceedings). An a b s t r a c t type is given by : 1. A s i g n a t u r e represented by a set S of Sorts and a set ∑. of symbols w i t h an a r i t y in (S) . This d i f f e r s from the usual theory where the a r i t y belongs to S ). We use, as Goguen does, overloading and coercion e x t e n s i v e l y . The n o t a t i o n of operators is s i m i l a r to OBJ ( \2\ . 2.
A set of p o s i t i v e c o n d i t i o n a l axioms.
These axioms (as in Goguen [ 14])contains the s o r t in which the equation has to be considered. The operators are raultioperators and can have more than one o u t p u t . I n f a c t , t h e i r i n t e r p r e t a t i o n i s a f u n c t i o n from the domaines of t h e i r input to the union of domaines of t h e i r output (which have to be d i s j o i n t e d ) . The operators have to be t o t a l on the ground terms but can be p a r t i a l on terms w i t h v a r i a b l e s . Using some kinds of p r e s e n t a t i o n and w i t h some p r o p e r t i e s , it can be shown that there can e x i s t one i n i t i a l algebra of terms in the class of s p e c i f i e d a l g e b r a s . More d e t a i l s are a v a i l a b l e in Boisson & A l l [ 18] . 3.
Some i n d u c t i o n schemes
These i n d u c t i o n schemes w i l l be u s e f u l d u r i n g the c o n s t r u c t i o n and the proof process. They w i l l be described more p r e c i s e l y in the a p p r o p r i a t e sect i o n . They correspond in a sense to the i n d u c t i o n schemata in A f f i r m [ 20] . 4.
Some theorems
This p a r t contains p r o p e r t i e s or theorems which can be deduced from the axioms. These theorems may be u s e f u l in the p r o o f s . F i g . 1 describes the s p e c i f i c a t i o n of the pos i t i v e i n t e g e r s type. We assume t h a t the type Bool which represents the booleans is known somewhere else w i t h a l l i t ' s s u i t a b l e operations and axioms. We can make the f o l l o w i n g remarks on t h i s example : - We d e f i n e here three s o r t s . The zero s o r t is
very convenient f o r c o n s t r u c t i n g programs and f o r specifying t h i s type. - The n o t a t i o n i n t = i n t , + z e r o is j u s t syntact i c . I t i s t o avoid w r i t i n g i n t , zero everywhere in the type. - The underscore ( _) shows the places of the operands w i t h the d i s f i x n o t a t i o n of o p e r a t o r s . - There are p l e n t y of overloadings in t h i s spec i f i c a t i o n . For instance there are four + operators! - When there is more than one s o r t in the l e f t p a r t of the a r i t y of one o p e r a t o r , it means that it is a m u l t i o p e r a t o r . For instance P has two o u t p u t s : i n t and zero. - There e x i s t s also multiaxioms (a s y n t a c t i c l e v e l ) in the way that an axiom is repeated when there is some ambiguity in the type of operators or when there are more than one s o r t before the axiom. For instance : int : x + 0 = x means zero : x + 0 = x int : x + 0 = x or bool : x < 0 - False " bool : x : zero < 0 = False bool : x : i n t < 0 = False See f i g u r e 1 next page f o r p r e s e n t a t i o n of the type. - There are c o n d i t i o n a l axioms l i k e : x egal y =* x oiv y = True In f a c t a c o r r e c t d e f i n i t i o n would be : x egal y = True --> d i v y = True We accepted t h i s s y n t a c t i c s i m p l i f i c a t i o n , in order not to overload the axioms but they are a l l positive conditional. - We can see w i t h some examples how the i n i t i a l term algebra i s . . 0 is in s o r t zero . sO is in s o r t i n t and [ s n 0 | f o r n > 1) are in int because s is not a m u l t i o p e r a t o r . These terms can be considered as r e p r e s e n t a t i v e of classes of terms i n i n t . psO is in zero because of the f i r s t axiom . ppsO does not e x i s t because p does not apply to s o r t zero . sO - ssO = 0 - sO by axiom 3 = erint by axiom 4 Then i t i s i n i n t e r . The term sO + (sO - sssO) does not e x i s t ! It can be proven t h a t there is no ambiguity f o r any ground term and then t h i s term algebra is i n i tial. - The axiom i n t e r : x = e r i n t c o l l e c t s a l l the e r r o r terms i n t o one s i n g l e class w i t h o u t avoiding a l l the c l a s s i c a l problems w i t h the e r r o r s i n abst r a c t data t y p e . - It is necessary f o r the evaluator to do type cheeking d u r i n g the e v a l u a t i o n process in order to choose the c o r r e c t axioms or to detect terms which do not e x i s t . In f a c t these terms w i l l not be gener a t e d w i t h c o r r e c t programs. I t might b e p o s s i b l e here to add some operators which could be a p p l i e d to i n t e r to get e r r o r propagation and these terms would then e x i s t ( f o r instance : + : ( i n t , i n t e r ) ( i n t , i n t e r ) -> i n t , i n t e r in s p i t e of the e x i s t i n g one !) - An equation can be used i f f i t s two sides e x i s t and have the same t y p e . Then, f o r i n s t a n c e , the t h i r d theorem
G. Guiho 5
6 G. Guiho
G. Guiho 7
8 G. Guiho
G. Guiho 9
This example shows that the proof is not very easy, even f o r such a simple example because of the theorems or lemmas which have to be used. In our o p i n i o n , t h i s kind of proof cannot be done a u t o m a t i c a l l y by a present theorem prover ( w i t h the d i s c o very of lemmas).A nice proof checher would be p r e ferable. V CONCLUSION This method, t h i s toy example and the simple proof do not intend to describe a l l the t o o l s which have to be in such a system, l.'e claim here that when we t r y to be very precise (and we have to when we b u i l d c o r r e c t programs) a l l the concepts which belong to t h i s paper have to be contained in one way or anotlier in the system, which leads to many d i f f i c u l t t h e o r e t i c a l problems not completely solved at t h i s time. What we can hope f o r in the near f u t u r e is the e f f e c t i v e implementation of such p a r t i a l systems which w i l l become more and more p o w e r f u l , coupled w i t h meaningful research on abstract data type t h e o r y , S p e c i f i c a t i o n languages, Theorem provers or proof cheekers and r u l e r e w r i t i n g systems. 'ACKNOWLEDGMENTS .'' The authors wishes to thank M. B i d o i t , M.C. M. C. Gaudel, C. Gresse, S. Kaplan f o r many e x c i t i n g discussions on t h i s s u b j e c t . REFERENCES [ 1 J Manna,Z. & R. Waldinger, "Deductive synthesis of the u n i f i c a t i o n A l g o r i t h m " In Computer Program synthesis methodologies. A. Biermann & G. Guiho E d i t o r s . D. R e i d e l ' P u b l i s h i n g Co 1983. [2 ] B i d o i t , M.& C. Gresse & G. Guiho, "A system which synthesiezs array manipulating programs from s p e c i f i c a t i o n s . Proc 6th 1JCAI-79. Tokyo pp. 63-65. [3 ] K o d r a t o f f , Y, from a f i n i t e gram shceme". I n f . Sciences
"A class of functions synthesized number of examples and a LISP p r o I n t e r n a t i o n a l J. of Comp. and 8, 1979, pp. 489-521.
[4 ] Jouannaud,J. P. & G. Guiho, "SISP/l An i n t e r a n t i v e system able to synthesize f u n c t i o n s form examples". Proc 5th I J C A I . M . I . T . , August, 1977. [5] Biermann, A. W. & D. R. Smith, "The h i e r a r c h i c a l synthesis of LISP scanning programs". I n f o r m a t i o n processing 77, North H o l l a n d , 1977, pp. 41-45. [6 ] M o r i c o n i , M. "A d e s i g n e r / v e r i f i e r ' s A s s i s t a n t " IEEE Transactions on Software Engineering, Vol Se-5 N° 4, J u l y , 1979. [/ ]Barstow, D. R. "Automatic Construction of A l gorithm and Data S t r u c t u r e s using a Knowledge base of Programming Rules". PHD D i s s e r t a t i o n , Stanford Memo A1M-308, 1977.
[8 ]Good D. & A l l , "Report on the language Gypsy" Version 2. 0. I n s t i t u t e f o r computing Science and computer a p p l i c a t i o n s . The U n i v e r s i t y of Texas. A u s t i n Texas 1978. [9 ]Shostak, R. E. and R. Schwartz, Mel 1iard-Smith P.M. STP : ?A Mechanized Logic f o r s p e c i f i c a t i o n and v e r i f i c a t i o n " . 6th conference on Automated Deduction, NY 1982. [ l 0 ] H u e t , G. " P r o j e t Formel", INRIA, France 1983. [ l l ] B o u g e , L. " M o d e l i s a t i o n de la n o t i o n de t e s t et de programmes". These 3e cycle LITP Paris Novembre 1982 [ 12]Thatcher, J. W. and E. G. Wagner and J. B. W r i g h t , " S p e c i f i c a t i o n of Abstract Types using c o n d i t i o n a l axioms , IBM report 6214, September 1976. [13]Coguen, J. A. and J. W. Thatcher and E. G. Wagner, "An I n i t i a l Algebra approach to the s p e c i f i c a t i o n , correctness and Implementation of abstract data type. IBM r e p o r t KC 6487, October, 1976. [l4]Goguen, J. "Order Sorted Algebras : Exceptions and Error S o r t s , coercion and Overloaded operat o r s . Report IT 14, S . R . I . December, 1978. [ 15]Wirsing, M. and M. Broy, " A b s t r a c t data types as l a t t i c e s of f i n i t e l y generated Models". 9th MFCS ,Rydjyna, September, 1980. [ l 6 ] B i d o i t , M; "Algebraic Data Types. S t r u c t u r e d S p e c i f i c a t i o n s and F a i r P r e s e n t a t i o n s " . C o l l o que AFCET/MA , P a r i s , March, 1982. [ 1 7 ] K a p l a n , S. "Un langage de s p e c i f i c a t i o n de t y pes a b s t r a i t s a l g e b r i q u e s " . These 3e cycle L R I - Orsay, F e v r i e r , 1983. [ 18]Boisson, F. and G. Guiho and D. Pavot, " A l g e bres a Operateurs M u l t i t y p e s " . Rapport i n t e r n e LRI-Orsay, Mai, 1983. [19]Gresse, C. "Automatic programming from Data Type decomposition p a t e r n s " . 8th IJCAI-83, K a r l sruhe, August, 1983. [20]Loeckx, J . "Proving P r o p e r t i e s o f a l g o r i t h m i c S p e c i f i c a t i o n s of Abstract data Types in AFFIRM". Memo-29-JL U.S.C July 1980.
