2018.09.14

Paper

Learning to Represent Programs with Graphs

Authors

Microsoft Research Deep Program Understanding group

• Miltiadis Allamanis
• Marc Brockschmidt
• Mahmoud Khademi

Questions/Notes

1. Pros and cons comparing to code2vec approach?

   → GGNN model looks more interesting, even with only syntactical edges

2. Pros and cons compared to TreeLSTM or similar approaches?

   → GGNN 8 local neighborhoods VS full tree

3. Graph construction Partial type information, without full compiler?

   → should work, but perf degrades most probably. Types needed for senatic nodes

   → also types could be deduced

4. In the section called Program Graphs, they describe what kind of relationships they encode within the graph. What is the rationale behind adding these relationship. If I would start from scratch and would have to decide which relationships to encode, how would I know what would be useful and what not?

   → engineering question more than research. Semantic information

   → kind of feature-engineering

5. Finally, for all types of edges we introduce their respective backwards edges (transposing the adjacency matrix), doubling the number of edges and edge types. Backwards edges help with propagating information faster across the GGNN and make the model more expressive.

   What is the reason for backward edges leading to faster propagation? What could possibly be the intuition behind it?

6. Ultimate “program representation” result

   → general encoder, task-specific decoderer. As stacked LSTMs or Transformers are in NLP

   → representation, suitable for transfer learning between problems

7. Idea: train universal representation to jointly solve multiple problems \w graphs

8. This approach does not solve code generation.

9. Other papers (Egor)