We study the problem of generating source code in a strongly typed,
 Java-like programming language, given a label (for example a set of
 API calls or types) carrying a small amount of information about the
 code that is desired. The generated programs are expected to respect a
 `"realistic" relationship between programs and labels, as exemplified
 by a corpus of labeled programs available during training.

 Two challenges in such *conditional program generation* are that
 the generated programs must satisfy a rich set of syntactic and
 semantic constraints, and that source code contains many low-level
 features that impede learning.  We address these problems by training
 a neural generator not on code but on *program sketches*, or
 models of program syntax that abstract out names and operations that
 do not generalize across programs. During generation, we infer a
 posterior distribution over sketches, then concretize samples from
 this distribution into type-safe programs using combinatorial
 techniques.  We implement our ideas in a system for generating
 API-heavy Java code, and show that it can often predict the entire
 body of a method given just a few API calls or data types that appear
 in the method. Neural networks have been successfully applied to many generative modeling tasks in the recent past BID22 BID11 BID33 . However, the use of these models in generating highly structured text remains relatively understudied. In this paper, we present a method, combining neural and combinatorial techniques, for the condition generation of an important category of such text: the source code of programs in Java-like programming languages.The specific problem we consider is one of supervised learning. During training, we are given a set of programs, each program annotated with a label, which may contain information such as the set of API calls or the types used in the code. Our goal is to learn a function g such that for a test case of the form (X, Prog) (where Prog is a program and X is a label), g(X) is a compilable, type-safe program that is equivalent to Prog.This problem has immediate applications in helping humans solve programming tasks BID12 BID26 . In the usage scenario that we envision, a human programmer uses a label to specify a small amount of information about a program that they have in mind. Based on this information, our generator seeks to produce a program equivalent to the "target" program, thus performing a particularly powerful form of code completion.Conditional program generation is a special case of program synthesis BID19 BID32 , the classic problem of generating a program given a constraint on its behavior. This problem has received significant interest in recent years BID2 BID10 . In particular, several neural approaches to program synthesis driven by input-output examples have emerged BID3 BID23 BID5 . Fundamentally, these approaches are tasked with associating a program's syntax with its semantics. As doing so in general is extremely hard, these methods choose to only generate programs in highly controlled domainspecific languages. For example, BID3 consider a functional language in which the only data types permitted are integers and integer arrays, control flow is linear, and there is a sum total of 15 library functions. Given a set of input-output examples, their method predicts a vector of binary attributes indicating the presence or absence of various tokens (library functions) in the target program, and uses this prediction to guide a combinatorial search for programs.In contrast, in conditional program generation, we are already given a set of tokens (for example library functions or types) that appear in a program or its metadata. Thus, we sidestep the problem of learning the semantics of the programming language from data. We ask: does this simpler setting permit the generation of programs from a much richer, Java-like language, with one has thousands of data types and API methods, rich control flow and exception handling, and a strong type system? While simpler than general program synthesis, this problem is still highly nontrivial. Perhaps the central issue is that to be acceptable to a compiler, a generated program must satisfy a rich set of structural and semantic constraints such as "do not use undeclared variables as arguments to a procedure call" or "only use API calls and variables in a type-safe way". Learning such constraints automatically from data is hard. Moreover, as this is also a supervised learning problem, the generated programs also have to follow the patterns in the data while satisfying these constraints.We approach this problem with a combination of neural learning and type-guided combinatorial search BID6 . Our central idea is to learn not over source code, but over tree-structured syntactic models, or sketches, of programs. A sketch abstracts out low-level names and operations from a program, but retains information about the program's control structure, the orders in which it invokes API methods, and the types of arguments and return values of these methods. We propose a particular kind of probabilistic encoder-decoder, called a Gaussian Encoder-Decoder or GED, to learn a distribution over sketches conditioned on labels. During synthesis, we sample sketches from this distribution, then flesh out these samples into type-safe programs using a combinatorial method for program synthesis. Doing so effectively is possible because our sketches are designed to contain rich information about control flow and types.We have implemented our approach in a system called BAYOU. 1 We evaluate BAYOU in the generation of API-manipulating Android methods, using a corpus of about 150,000 methods drawn from an online repository. Our experiments show that BAYOU can often generate complex method bodies, including methods implementing tasks not encountered during training, given a few tokens as input. We have given a method for generating type-safe programs in a Java-like language, given a label containing a small amount of information about a program's code or metadata. Our main idea is to learn a model that can predict sketches of programs relevant to a label. The predicted sketches are concretized into code using combinatorial techniques. We have implemented our ideas in BAYOU, a system for the generation of API-heavy code. Our experiments indicate that the system can often generate complex method bodies from just a few tokens, and that learning at the level of sketches is key to performing such generation effectively.An important distinction between our work and classical program synthesis is that our generator is conditioned on uncertain, syntactic information about the target program, as opposed to hard constraints on the program's semantics. Of course, the programs that we generate are type-safe, and therefore guaranteed to satisfy certain semantic constraints. However, these constraints are invariant across generation tasks; in contrast, traditional program synthesis permits instance-specific semantic constraints. Future work will seek to condition program generation on syntactic labels as well as semantic constraints. As mentioned earlier, learning correlations between the syntax and semantics of programs written in complex languages is difficult. However, the approach of first generating and then concretizing a sketch could reduce this difficulty: sketches could be generated using a limited amount of semantic information, and the concretizer could use logic-based techniques BID2 BID10 to ensure that the programs synthesized from these sketches match the semantic constraints exactly. A key challenge here would be to calibrate the amount of semantic information on which sketch generation is conditioned. A THE AML LANGUAGE AML is a core language that is designed to capture the essence of API usage in Java-like languages. Now we present this language. DISPLAYFORM0 AML uses a finite set of API data types. A type is identified with a finite set of API method names (including constructors); the type for which this set is empty is said to be void. Each method name a is associated with a type signature (τ 1 , . . . , τ k ) → τ 0 , where τ 1 , . . . , τ k are the method's input types and τ 0 is its return type. A method for which τ 0 is void is interpreted to not return a value. Finally, we assume predefined universes of constants and variable names.The grammar for AML is as in FIG4 . Here, x, x 1 , . . . are variable names, c is a constant, and a is a method name. The syntax for programs Prog includes method calls, loops, branches, statement sequencing, and exception handling. We use variables to feed the output of one method into another, and the keyword let to store the return value of a call in a fresh variable. Exp stands for (objectvalued) expressions, which include constants, variables, method calls, and let-expressions such as "let x = Call : Exp", which stores the return value of a call in a fresh variable x, then uses this binding to evaluate the expression Exp. (Arithmetic and relational operators are assumed to be encompassed by API methods.)The operational semantics and type system for AML are standard, and consequently, we do not describe these in detail.
We give a method for generating type-safe programs in a Java-like language, given a small amount of syntactic information about the desired code.
{"src": "scitldr-AIC_train", "paper_id": "HkfXMz-Ab"}