Automatic Construction of Java Programs from Functional Program Specifications

—This paper presents a novel approach to construct Java programs automatically from the input functional program specifications on natural numbers from the constructive proofs of the input specifications using an inductive theorem prover called Poiti′n. The construction of a Java program from the input functional program specification involves two phases. The theorem prover is used to construct a higher order functional (HOF) program from the input specification expressed as an existential theorem. A set of mapping rules for a Programming Language Translation System (PLTS) is defined for translating functional expressions to their semantic equivalent Java code. The generated functional program is translated into intermediate Java code in the form of a Java function using the PLTS module. The generated Java function requires a small refinement to obtain a syntactically correct Java function. This Java function is encapsulated within a user defined Java class as a member operation, which is invoked within a Java application class consisting of a main function by creating objects resulting in an executable Java program. The constructed functional program and the generated Java program both are correct with respect to the input specification as they produce the same output.


INTRODUCTION
Automatic construction of executable programs from the input program specifications is really a difficult task.A number of theorem provers are available, for example, Poiti′n, Nuprl1, and Coq, which can be used to construct functional programs from the proofs of their specifications [1,2,3,4,5,6].Several code generation tools e.g., Rational Rose, Microgold and Umbrello have been developed for automatic generation of Java or C++ program code from UML design specification expressed in terms of class diagrams for a particular computing problem solution [1].These tools can be used to generate architectural code when class details in UML notation, i.e., class name, attributes, operations and class relationships are provided within the class diagram.The details code for each class operation has to be provided by the programmer.The generated code can only be verified by executing the code to 1 Nuprl System:http://www.nuprl.org/html/NuprlSystem.htmlsee whether it provides the desired output and functionality.The correctness, reliability and completeness of the generated programs fully depend on UML class design expertness and programming skill of the designer to encode the problem.The verification is done manually [1] by the designer to check its correctness.
Formal software development using mathematical rules aids automatic or semi-automatic program development from their specifications using their correctness proofs.Automatic construction of higher order functional programs from the proofs of their specifications using metasystem transition proofs has been developed [2,3,1].In the synthesis of functional programs from specifications, various approaches exist in which either a program is extracted from the proof of the specification [4,6], or transformation rules are applied to the specification to obtain a program [7].
Poiti′n [2,3,8] is an inductive theorem prover, which can be used to perform constructive proof of an existential theorem expressed in a simple higher order functional language (HOFL) to extract functional program from the proof of a nonexecutable input specification [2].The constructed program is an executable functional program in the source language (SL).The language of Poiti′n is untyped and non-strict with firstorder quantifiers.In this paper, input specifications on natural numbers are considered for program construction.The universal variables are intended to be used as input variables are not quantified, and therefore must remain within the constructed HOFL program.The existential variables are ANY quantified with explicitly defining their data types (e.g.nat for natural number).These are the witness variables which construct the output value.All of these variables are natural number variables.The existential theorem with the required function definitions, which is used as the input program specification, describes the properties of the desired program to be constructed [1].The theorem prover applies distillation program transformation algorithm [9,8,10,2,3] to the input specification to obtain a distilled program, and applies the proof rules to this program to verify the correctness of the input specification.A set of program construction rules is applied to the distilled program [2,3] to construct a functional program if the specification is proved correct.www.ijacsa.thesai.org the available theorem provers can only be used to construct functional programs [1,2,3,4,5].This paper presents a new approach for the construction of Java programs from the input functional program specifications expressed in the functional language of the theorem prover Poiti′n.A PLTS module applies a set of mapping rules to translate the constructed HOFL program into an equivalent Java function which is further refined to obtain a correct Java function.An executable Java program is developed to invoke this Java function which computes values similar to that of the HOFL program.
The rest of the paper is organized as follows.Section II presents the language of the theorem prover Poiti′n.Section III provides an overview about the programming language translation system (PLTS), and the related work.Section IV presents the system architecture for the automatic construction of Java programs from input functional program specification.Section V describes the relevance of the proposed system architecture for Java program construction from input functional program specification.Section VI gives an overview of higher order functional program construction from input functional program specification.Section VII defines a set of rules for translating the higher order functional program expressed in the language of Poiti′n to Java code with the refinement steps.Section VIII describes the process of constructing executable Java program using the generated Java code by defining Java classes with the required refinement.Section IX describes the implementation and results, and finally, section X concludes with a guideline to the future work.

II. LANGUAGE
The language of the theorem prover Poiti′n is defined as a simple higher order functional language.A finite set of free variables {u, v, x, y, z, u', v', …} with any number of renaming of these variables, a finite set of list variables {us, vs, xs, ys, zs, us', vs', …} with any number of renaming of these variables, and a finite set of function symbols {f, f0, f1, g, h} are considered.The notation e i (for i = 1 to n) is used to represent any expression in the language.A simple expression in the language can be a variable x, a constructor c, a constructor application c e 1 ... e n , a lambda expression λx.e, a function variable f, or an application e 0 e 1 [2,3,8,9].The language also contains complex case and letrec expressions.A case expression is defined as case e 0 of p 1 : e 1 | ... | p k : e k consisting of k alternate branches.The pattern p i appearing in the i th case branch is defined by the expression c x 1 … x n where c is a constructor and x i are bound variables.A letrec expression is defined as letrec f = e 0 in e 1 , where e 0 may contain a recursive call to the function f [2,3,8,9].The language has two first order quantifiers ALL and EX for quantifying universal and existential variables along with an ANY quantifier in order to specify the existential witness contained in the input program specification [2,3].The input specification can be expressed in any of the following forms [2]: ANY y:datatype.e (i) ANY y:datatype.pre→ post (ii where y is the existential variable representing existential witness to be computed, datatype is the type of the witnessing variable.In expression (i), e is the expression representing the properties of the program to be constructed consisting of functions and relations about natural numbers.Specification (ii) contains a pre-condition (pre), which is a constraint to restrict the program to be constructed from the proof of the specification to generate only the desired witness values.The input specification contains quantifier-free universal input variables, which must remain within the functional program constructed from the input specification [2,3].The subexpressions pre and post are valid expressions in the language.
A program, conjecture or program specification is expressed in the language in the following form [2,3,8,9]: Conjectures to be proved are defined in the form ALL x 1 …x n .EX y 1 …y n .ewhere x i and y i are universally and existentially quantified variables respectively.

III. PROGRAMMING LANGUAGE TRANSLATION SYSTEM (PLTS)
A programming language translation system (PLTS) can translate expressions in a source programming language into expressions in the target language (TL).For example, a C++ expression can be translated to a Java expression using a C++ to Java translator.The complexity of programming language translation depends on the syntactic and semantic gap between the source and target languages.Significant research works have been done for developing PLTSs for generating Java code from various source programming languages [1,11,12,13,14].An approach to compile Standard ML program to Java bytecode has been presented in [11].Some translation approaches have been proposed to obtain Java code from Haskell code [12], C code from ATLAS code [13], and Java code from COBOL code [14].
The author presents an approach to obtain Java program from a functional program specification in this paper.The proposed method translates the constructed functional program in the higher order functional language of Poiti′n to Java code using a set of mapping rules of the PLTS module.Poiti′n uses a non-strict and untyped higher order functional language, whereas Java is a strict and typed language.Because of a small number of instructions in the source language, we can obtain a few of the Java expressions for the input functional language to construct equivalent Java code.A prototype system has been developed which can be used to obtain Java code in the form of a Java function from a functional program [1] by translating the HOFL program constructed from the input functional program specification.

IV. SYSTEM ARCHITECTURE
The architecture of the proposed system for automatic Java program construction from functional program specification is represented in Fig. 1.In the proposed system, the inductive theorem prover Poiti'n constructs a functional program from the input specification.The parsing module extracts the source www.ijacsa.thesai.orglanguage constructs from the constructed functional program.The mapping module applies a set of translation rules to translate the functional program to Java code.The process of Java program construction from a functional program specification involves several phases.At first, a higher order functional program is constructed from the input specification.In the next phase, the constructed functional program is translated to obtain equivalent Java code in the form of a Java function [1].This Java function is further refined in the refinement phase to obtain a correct Java function computationally equivalent to that of the higher order functional program.In the construction phase, the Java function is encapsulated within a Java class as a member operation.This operation can be invoked by creating objects within a Java application class consisting of a main function to obtain an executable Java program.

V. RELEVANCE
Automatic construction of Java programs from input program specifications to solve a computational problem using program construction system is of great research interest to the software development research community.As far we know from the online literature, there is no work done so far to construct Java program automatically from input program specification expressed in Java language.The theorem prover Poiti'n can be used to construct functional programs from the input specifications expressed in its functional language.
A programming language translation system (PLTS) is proposed which can be used to translate simple higher order functional programs to Java functions.The research presented in this paper focuses on the construction of Java program from a functional program specification to solve a particular computational problem.Our intention is to automatically construct Java programs which can perform the same computations as that of the constructed functional programs.As there exists a functional program for the input functional program specification, which can be proved true by construction of that program from the constructive proof of the input specification using the theorem prover Poiti'n, there should exist a corresponding Java program to compute the same output as that of the constructed functional program.This paper presents an architecture shown in Fig. 1 for such Java program construction from input functional program specification about natural numbers only.The generated Java function can be used to develop an executable Java program.The proposed program construction system will lessen the burden of a programmer of writing details Java program code for those computational problems specified in HOFL of Poiti'n, which have their constructive proofs in Poiti'n to construct HOFL programs.

VI. FUNCTIONAL PROGRAM CONSTRUCTION
In the proposed system, the user has to define an input specification about natural numbers in the language of Poiti′n to automatically construct a functional program to solve a particular computational problem.The input specification describes the properties of the program to be constructed in terms of constraints and input/output relationship [2,3].The input specification is expressed in the form of an existential theorem in terms of quantifiers, variables, type of the witnessing variable, predicates and functions.An equivalent higher order functional program is obtained from this specification using a set of program transformation rules called distillation [2,3,8,9].The theorem prover applies a set of constructive proof rules [2,3,9] to this distilled program to construct a functional program for witness construction.The constructed functional program satisfies the properties described in the specification, and can be used to compute the value(s) of the existential witness which satisfies the program specification [1,2,3].This is the actual purpose of the computational problem to be solved for which the input program specification was defined.
Consider the program specification defined by expression (1) as shown below.Intermediate Java Code www.ijacsa.thesai.orgfunctional program given by the following expression (2) is obtained from the above input functional program specification (1).
The functions and relations used in specification (1) have their usual meaning and definitions using case expression [1,2].In the definitions, the value Bottom represents an undefined value of a three-valued logic, i.e.True, False, Bottom.Poiti'n constructs a functional program defined by expression (2) from the input specification (1) [1,2].Expression (2) can be redefined by expression (3) in the form of a HOFL program both computing the same output value for the same input.However, in this paper, expression (2) is used for the translation purpose.f0 x (3) where f0 = x.casex of Zero Zero | Succ(x')case x' of Zero Zero | Succ(x'')Succ(f0 x''); Within the expressions, the symbol  is used for variable binding and x' represents the predecessor of x, i.e., x-1.The variable f0 is a recursive function which is defined by using a letrec expression.Within expression (1), the functions and relations used are on natural numbers, and the universal input variable x and the existential variable y under construction both are of type nat.As we have to input a natural number x to construct the witness y for it using the constructed HOFL program, x must remain within the HOFL program, i.e., x is quantifier-free universal variable.In evaluating the constructed HOFL program given by expression (2) using a natural number input for x, the argument x decreases by 2 in each recursive call to the recursive function f0 till x reduces to 0 using the successive steps [1,2].Verifying the program given by expression (2), we see that the program constructs a value of y for each input value of x satisfying the input specification (1).

VII. TRANSLATION OF FUNCTIONAL PROGRAM TO JAVA CODE
The higher order functional program constructed by the theorem prover is usually expressed by using a letrec expression defining a recursive function, which is translated to a Java function by the PLTS module.A set of the mapping rules T is defined for the PLTS module as shown below [1] for translating the HOFL expressions to intermediate Java code.

.,xn);>
The constructed functional program is tokenized to produce a token list which is input to the parsing module along with lexicon and the context free grammar (CFG) of the source language as shown in Fig. 1.The parsing process generates several component sub-expressions in the form of a tree by processing this token list.The mapping rules T are applied to the component sub-expressions to obtain their corresponding Java code.The generated Java code is not executable in its current form.
A HOFL expression can be defined by the following rule: where "|" represents switching between different functional language constructs [1].
The general form of a mapping rule is defined as HOFLexprType  T<HOFLexpr> <JavaCode> where the variable HOFLexprType represents the type of the HOFL expression under translation, HOFLexpr is the HOFL expression to be translated, and JavaCode is the equivalent Java code of this HOFL expression.
Each of the primitive HOFL expressions has its corresponding equivalent Java code in its basic form where the source and target language constructs have same variable name.In these rules, f and f0 denote the function variable, x, x', x 1 , x 1 ', y, y' and vs are data variables, and e, e1, e2 are expressions.The environment variable  is used to store the universal input variables appearing within the input specification.The expression type, keywords, identifiers and sub-expressions of a HOFL expression are determined during www.ijacsa.thesai.orgparsing of the constructed functional program, which are input to the translation/mapping module for further processing of the functional expression [1].
Rule T1 encounters a variable v in HOFL syntax, and since the HOFL program contains only natural number variables as specified in the input program specification, it is translated to an integer type variable in Java.Rule T2 encounters a renaming v′ of a natural number variable v. Since the renaming occurs only at the recursive steps and as v′ is a sub-component of v, hence v is decremented to its predecessor by decrementing v by 1.If v is a renaming of v, then v is further translated using T. Rule T3 encounters list type variable vs of natural numbers in HOFL syntax, and it is translated to an integer array variable in Java syntax.Rule T4 and Rule T5 deal with constructors.Rule T4 encounters the constructor Zero, which is translated to an equivalent Java integer number 0. Rule T5 encounters the constructor application Succ(e).In this rule, 1 is added with the result of translating the argument e. Rule T6 translates a HOFL function variable f with no arguments to a Java function f().Rule T7 encounters a function application of the function f with n number of arguments e 1 ... e n .The PLTS translates this function application to a Java function call to the function f with the results of separately translating the arguments e 1 ,..., e n as the function arguments.Rule T8 encounters a HOFL case expression which is translated to a switch statement in Java syntax, and the HOFL sub-expressions in the case branches are recursively translated to their equivalent Java code.Before translating the case branches, any renamed variable occurring within the case branches is searched within the environment variable , and it is checked to see whether it is a renaming of any of the variable found within .The renamed variable is initialized with decrementing the original case selector variable by 1 for each renaming.Rule T9 translates a HOFL function definition of f with n bound variables.The lambda () bound variables x 1 ... x n used in the body of the function f are local to the function f, which become the formal parameters int x 1 , ... , int x n of the corresponding Java function f.The body of the Java function f is obtained by translating the HOFL expression e of the function f.Rule T10 translates a HOFL letrec expression which defines a function f with n parameters including a function call to f.The  bound variables x 1 ... x n used in this expression are local to the function f, which become the formal parameters int x 1 , ... , int x n of the corresponding Java function f.The body of the Java function f is obtained by translating the case expression of the letrec expression.The function call f(x 1 ... x n ) used in the tail of the letrec expression is translated to a Java function call f(x 1, ..., x n ), and the variables x 1, ..., x n are inserted into .
In the application of the rules T to an HOFL expression, the matching of any component expression contained in the constructed functional program with the appropriate mapping rule skeleton is performed on the skeleton of the HOFL component contained in the appropriate mapping rule [2,3,8,9].

Example
Consider the translation of a HOFL letrec expression which defines the function f as given by expression (4) into Java code using the rules T of the PLTS module.In this expression, x is a natural number variable which is decremented by 1 in each recursive call to the function f until x reduces to 0.
The PLTS module generates the intermediate Java code as shown below which defines the Java function f using the mapping rules T. The Java function f needs to be refined to obtain a syntactically correct Java function.

A. Refinement of the Java Code
The refinement phase makes few changes to the generated Java code of the function f as shown above resulting in the refined correct Java code as shown below.public int f(int x) { switch (x) { case 0: res = 0; break; default: x = x -1; res = f(x); } return res; } During refinement, at first, the void type of the function f is converted to int type.This change is mandatory as the constructed HOFL program defined in the form of a letrec function returns a natural number value as the output of the function, so the generated Java function obtained from the HOFL function must have the same return type declared in the function header or function prototype declaration, i.e., int type in Java.As it is difficult to handle the return type of the generated Java function within the rules T, the return type of the function is added during the refinement phase of the program construction system as shown in Fig. 1.Second, the statements, expressions or values which contribute to final result are identified, and an output variable, e.g.res, is initialized with these components.The output variable is declared as an attribute of a Java class in which this function will be www.ijacsa.thesai.orgobject of the class F0 within the main function of the Java application class F0app.The argument x of the HOFL letrec function call f0 x is declared as an integer variable within the main function.The operation f0 of the class F0 is invoked by passing x by initializing an integer number 11 as an argument to the Java function f0 by creating an object.The Java function f0 computes the same value as the witness value computed by the HOFL program defined by expression (2) for any input value of x.The output of executing the constructed Java program with invoking the operation f0 with an input 11 is shown below, which computes an existential witness value 5.
Input (x): 11 Existential Witness (y): 5 The above output computed by the automatically developed Java function f0 satisfies the properties defined by the input functional program specification (1).

IX. IMPLEMENTATION AND RESULTS
A prototype version of the Java program construction system based on the system architecture shown in Fig. 1 has been tested.The theorem prover Poiti′n [2,3,8] implemented using SML/NJ functional programming language is at the heart of the program construction system.Poiti′n uses a simple higher order functional language (HOFL) with first order quantifiers.The functional program constructed from the input specification is a HOFL letrec function, which is output to a disk file for further processing using the PLTS module to generate Java code from this HOFL function.A simple application program has been written using NetBeans IDE Java programming language to implement the rules T of the PLTS module to translate the constructed HOFL program into semantic equivalent Java code in the form of a Java function, is still under improvement.The generated Java code of the function requires refinement tasks to be performed through using four steps of the refinement phase to build a syntactically correct Java function.The construction of the Java class to encapsulate the generated Java function as a member operation, and the construction of the Java application class for object creation and invoking the member operation are done manually in the current version of the prototype, which is still under improvement.The Java program construction system can be used to generate Java code in all of the cases where the theorem prover Poiti′n is able to construct HOFL program from the constructive proofs of the input program specifications.

A. Validation and Correctness
A number of theorem provers are available besides Poiti′n, e.g., Nuprl, Coq and automatic recursive program synthesis system [4,5,6], which can be used to verify programs, and can be used to construct programs from the proofs of the specifications.Most of the theorem provers and program synthesis systems use axioms or intermediate lemmas and generalizations in order to complete the proof successfully.Poiti′n does not make use of any lemmas, only need generalization to complete the proofs [2].Hence the number of theorems that can be proved by Poiti′n is also small.
To show that the program construction system shown in Fig. 1 can construct correct Java programs with respect to the input program specification, the following two properties need to be ensured:  The functional program constructed from the input functional program specification by Poiti′n is correct and satisfies the input specification.
 The mapping rules T defined for the PLTS module for translating the constructed functional program to equivalent Java code are sound.
The proof of the above two properties is beyond the scope of this paper.The details of the proof of the first property can be found in [2,3,8,9].To prove the second property, it is sufficient to show that each HOFL construct that is dealt with the rule of T is translated to equivalent Java code.It is beyond the scope of this paper to give the details of this proof.

B. Examples of Some Program Specifications
Some examples of functional program specifications which can be used to construct functional programs from their constructive proof using Poiti′n are shown below [2].

X. CONCLUSION AND FUTURE WORK
The approach for Java program construction presented in this paper to solve a particular computational problem uses an inductive theorem prover called Poiti′n [2,3,8].A HOFL program is automatically constructed from the proof of a functional program specification using Poiti′n, which is translated to a Java function using a PLTS module in order to generate a Java program to get the essence of constructing Java programs from input program specifications.The constructed HOFL program satisfies the input specification.The generated Java function requires refinement to obtain a syntactically correct Java function which can compute the same output as that of the HOFL program [1].To execute this function, it is encapsulated within a user defined Java class as a member operation, and invoked within a java application class by creating object of the user defined class.The language of Poiti′n is untyped, and hence the input specifications are considered about natural numbers only in the current scope.As far we know from the online literature, for the first time, the approach for the automatic construction of a Java program from the input program specification, i.e. a functional program specification using the constructive proof of the specification is presented in this paper based on the work presented in [1].The programs are constructed only from the specifications which are proved correct.So, this system constructs correct programs with respect to the specifications.Automatic construction of programs is an interesting area of research in the field of formal software development.
There are a number of directions for continuing further research.First, the Java code generation phase can be improved www.ijacsa.thesai.orgso that more efficient Java code can be generated, which will require less refinement tasks.Second, the language of the theorem prover Poiti′n can be extended to include type systems [1], and try to handle more difficult specifications for program construction.Finally, the Java class construction phase can be automated to develop an executable Java program.