We introduce the notion of property signatures, a representation for programs and program specifications meant for consumption by machine learning algorithms. Given a function with input type τ in and output type τ out , a property is a function of type: (τ in , τ out ) → Bool that (informally) describes some simple property of the function under consideration. For instance, if τ in and τ out are both lists of the same type, one property might ask 'is the input list the same length as the output list?'. If we have a list of such properties, we can evaluate them all for our function to get a list of outputs that we will call the property signature. Crucially, we can 'guess' the property signature for a function given only a set of input/output pairs meant to specify that function. We discuss several potential applications of property signatures and show experimentally that they can be used to improve over a baseline synthesizer so that it emits twice as many programs in less than one-tenth of the time.
This paper proposed the concept of "property signatures" , which are learned to represent programs. The property signatures are essentially some key attributes that one may summarize from a given set of input-output pairs, which the target function has. Then a program can be generated by evaluating these property signatures vectors (which is simply a bag-of-word representation with only 0 or 1 as each element). Much discussions have been given to discuss why and how these properties may be useful and very little real experiments are conducted quantitatively compared with existing works. Although this paper is quite interesting, I think this paper is in its very early stage and there are a lot of serious concerns I have for using this approach to synthesize the real complex programs. 
1) First of all, the notion of property signatures are easy to understand and is very natural. Just like human beings, when we write a program, we first think about the possible attributes of this program may have given a set of input-output pairs for both correctness and completeness. However, this is also the hard part of this idea. Potentially it could have an exponential number of possible properties as the program goes more complex and complex. It will quickly become computationally intractable problem. 
2) When I read the middle of paper, I would eager to know how authors can effectively find a good set of properties of a target program from a given input-output pairs. However, when I eventually reached the Section 4, I was kindly disappointed since I did not see any effective and principle way to get them. All I saw are "randomly sample and generate". This may be Ok for a very simple program given a set of simple input-output pairs. But it is definitely not feasible for any complex function, not to mention project. I think this is the key for the proposed idea since how to construct a good set of property signatures is crucial to treat them as the inputs for any program synthesis task later. 
3) There are very little baselines to compare against even though authors listed "substantial prior work on program synthesis". I understand the existing works may have their limitation in both what they can do and how well they can do. But it is still important to compare with directly on the same set of benchmarks. Otherwise, it is hard to be convincing that this approach is indeed superior compared to existing ones.