Guiding Program Synthesis by Learning to Generate Examples
A key challenge of existing program synthesizers is ensuring that the synthesized program generalizes well. This can be difficult to achieve as the specification provided by the end user is often limited, containing as few as one or two input-output examples. In this paper we address this challenge via an iterative approach that finds ambiguities in the provided specification and learns to resolve these by generating additional input-output examples. The main insight is to reduce the problem of selecting which program generalizes well to the simpler task of deciding which output is correct. As a result, to train our probabilistic models, we can take advantage of the large amounts of data in the form of program outputs, which are often much easier to obtain than the corresponding ground-truth programs.
= Summary A method for a refinement loop for program synthesizers operating on input/ouput specifications is presented. The core idea is to generate several candidate solutions, execute them on several inputs, and then use a learned component to judge which of the resulting input/output pairs are most likely to be correct. This avoids having to judge the correctness of the generated programs and instead focuses on the easier task of judging the correctness of outputs. An implementation of the idea in a tool for synthesizing programs generating UIs is evaluated, showing impressive improvements over the baseline. = Strong/Weak Points + The idea is surprisingly simple and applies to an important problem in program synthesis. + The experiments show that the method works very well in UI-generation domain - The paper repeatedly claims general applicability to program synthesizers, but is only evaluated in the specific domain of UI-generating programs. I have substantial doubts that the approach would work as well in the domains of, e.g., string manipulation, Karel, or data structure transformations. My doubts are based on the fact that there are easily generalizable rules for UIs (no overlaps, symmetry, ...), whereas other domains are less easily described. This creates a substantial gap between paper claims and empirical results. - The writting is somewhat sloppy (see below), which makes it sometimes hard to understand. Names such as *views* are used without explanation, and it*s not explained how a device is an input to a program (yes, I get what this means, but it makes in unnecessarily hard to follow the paper) = Recommendation I would ask the authors to rewrite their paper to make less general claims, but believe that the general idea of judging the correctness of a program (or policy) by evaluating it on different inputs is a powerful concept that would be of substantial value to the wider ICLR audience. Improving the readability of the paper would make me improve my rating to a full accept. = Minor Comments * page 1, par *Generalization challenge*: The second sentence here is 4 lines long and very hard to follow. Please rephrase. * page 2, par 2: *no large real-word datasets exists* -> exist * page 2, par 3: *even when both optimizations of InferUI are disabled*: at this point, the reader doesn*t know about any optimizations of InferUI. * page 4, par 1: *i.e., * - is undefined here (will be defined later on the page) * page 4, par 2: *Generate a candidate program * - in step 2, there are suddenly also , which are never explicitly generated. Either adapt this step, or explicitly generate them in step 2 based on the distinguishing input * page 7 par 2: *We use one screen dimension as the input specification , the second as the distinguishing input* - this confused me, as the paper discussed discovering the distinguishing input (page 4, paragraph *Finding a distinguishing input*), whereas it sounds here like that input is manually selected.
You are a member of the scientific community tasked with peer review. Review the following paper title and abstract.
### Title + Abstract
Guiding Program Synthesis by Learning to Generate Examples
A key challenge of existing program synthesizers is ensuring that the synthesized program generalizes well. This can be difficult to achieve as the specification provided by the end user is often limited, containing as few as one or two input-output examples. In this paper we address this challenge via an iterative approach that finds ambiguities in the provided specification and learns to resolve these by generating additional input-output examples. The main insight is to reduce the problem of selecting which program generalizes well to the simpler task of deciding which output is correct. As a result, to train our probabilistic models, we can take advantage of the large amounts of data in the form of program outputs, which are often much easier to obtain than the corresponding ground-truth programs.
user
<think>Okay, to do a decent peer review, I should start with summarizing what the work is about. This includes novelty, contributions, clarity, and impact. I might include suggestions to issues that I find critical to the usefulness of the work. Starting with novelty, there are different types of novelty. The first aspect of novelty is scope and scale. Is the work covering a broader perspective than previous works? The second aspect is methodology. Is the proposed methodology novel compared to previous methods? Do they provide any significant advantage over previous methodologies? The third aspect is results. Are the results different compared previous work? Does this lead to any novel theories or an extension of current theories? Next is clarity, I will be reading the work in depth and analyze if any sentences can be potentially ambiguous or misleading. If any sentences are ambiguous, I will state them and give a suggestion on how to rephrase such sentence or how to make more clear to the audience. Lastly, impact is important. I will attempt to predict how such work will impact the scientific community. This might include the applications of such work and how the work might transform the way we study a certain topic. Finally, I will might only mention issues that are critical. This is to keep the review as concise and helpful as possible.</think>



= Summary A method for a refinement loop for program synthesizers operating on input/ouput specifications is presented. The core idea is to generate several candidate solutions, execute them on several inputs, and then use a learned component to judge which of the resulting input/output pairs are most likely to be correct. This avoids having to judge the correctness of the generated programs and instead focuses on the easier task of judging the correctness of outputs. An implementation of the idea in a tool for synthesizing programs generating UIs is evaluated, showing impressive improvements over the baseline. = Strong/Weak Points + The idea is surprisingly simple and applies to an important problem in program synthesis. + The experiments show that the method works very well in UI-generation domain - The paper repeatedly claims general applicability to program synthesizers, but is only evaluated in the specific domain of UI-generating programs. I have substantial doubts that the approach would work as well in the domains of, e.g., string manipulation, Karel, or data structure transformations. My doubts are based on the fact that there are easily generalizable rules for UIs (no overlaps, symmetry, ...), whereas other domains are less easily described. This creates a substantial gap between paper claims and empirical results. - The writting is somewhat sloppy (see below), which makes it sometimes hard to understand. Names such as *views* are used without explanation, and it*s not explained how a device is an input to a program (yes, I get what this means, but it makes in unnecessarily hard to follow the paper) = Recommendation I would ask the authors to rewrite their paper to make less general claims, but believe that the general idea of judging the correctness of a program (or policy) by evaluating it on different inputs is a powerful concept that would be of substantial value to the wider ICLR audience. Improving the readability of the paper would make me improve my rating to a full accept. = Minor Comments * page 1, par *Generalization challenge*: The second sentence here is 4 lines long and very hard to follow. Please rephrase. * page 2, par 2: *no large real-word datasets exists* -> exist * page 2, par 3: *even when both optimizations of InferUI are disabled*: at this point, the reader doesn*t know about any optimizations of InferUI. * page 4, par 1: *i.e., * - is undefined here (will be defined later on the page) * page 4, par 2: *Generate a candidate program * - in step 2, there are suddenly also , which are never explicitly generated. Either adapt this step, or explicitly generate them in step 2 based on the distinguishing input * page 7 par 2: *We use one screen dimension as the input specification , the second as the distinguishing input* - this confused me, as the paper discussed discovering the distinguishing input (page 4, paragraph *Finding a distinguishing input*), whereas it sounds here like that input is manually selected.
assistant
= Summary A method for a refinement loop for program synthesizers operating on input/ouput specifications is presented. The core idea is to generate several candidate solutions, execute them on several inputs, and then use a learned component to judge which of the resulting input/output pairs are most likely to be correct. This avoids having to judge the correctness of the generated programs and instead focuses on the easier task of judging the correctness of outputs. An implementation of the idea in a tool for synthesizing programs generating UIs is evaluated, showing impressive improvements over the baseline. = Strong/Weak Points + The idea is surprisingly simple and applies to an important problem in program synthesis. + The experiments show that the method works very well in UI-generation domain - The paper repeatedly claims general applicability to program synthesizers, but is only evaluated in the specific domain of UI-generating programs. I have substantial doubts that the approach would work as well in the domains of, e.g., string manipulation, Karel, or data structure transformations. My doubts are based on the fact that there are easily generalizable rules for UIs (no overlaps, symmetry, ...), whereas other domains are less easily described. This creates a substantial gap between paper claims and empirical results. - The writting is somewhat sloppy (see below), which makes it sometimes hard to understand. Names such as *views* are used without explanation, and it*s not explained how a device is an input to a program (yes, I get what this means, but it makes in unnecessarily hard to follow the paper) = Recommendation I would ask the authors to rewrite their paper to make less general claims, but believe that the general idea of judging the correctness of a program (or policy) by evaluating it on different inputs is a powerful concept that would be of substantial value to the wider ICLR audience. Improving the readability of the paper would make me improve my rating to a full accept. = Minor Comments * page 1, par *Generalization challenge*: The second sentence here is 4 lines long and very hard to follow. Please rephrase. * page 2, par 2: *no large real-word datasets exists* -> exist * page 2, par 3: *even when both optimizations of InferUI are disabled*: at this point, the reader doesn*t know about any optimizations of InferUI. * page 4, par 1: *i.e., * - is undefined here (will be defined later on the page) * page 4, par 2: *Generate a candidate program * - in step 2, there are suddenly also , which are never explicitly generated. Either adapt this step, or explicitly generate them in step 2 based on the distinguishing input * page 7 par 2: *We use one screen dimension as the input specification , the second as the distinguishing input* - this confused me, as the paper discussed discovering the distinguishing input (page 4, paragraph *Finding a distinguishing input*), whereas it sounds here like that input is manually selected.