AST Diagram & Thinking about Scope

AST Diagram

My first order of business this week was to finish diagramming what the AST Package hierarchy looked like, specifically the hierarchy of the "Node" class. In the end, the diagram extends onto six sheets of paper full of arrows and boxes (I'll hopefully be able to include a picture once the photo-uploading for blogs is working again).

The visual depicition of the package has many clear advantages, at least for me. Firstly, because the return types of most of the methods for Nodes are other Node types, it allows for a quick examination of the relationships between the classes. In addition, seeing all the subtypes of a supertype, any how they behave, are often a better descriptor of what the abstract class is than the class itself.

Also, seeing the dizzying diagram in whole makes it very visually obvious just how necessary a solid API will need to be for the mentoring system, as expecting mentors to understand how the AST classes are functioning as a whole is probably an unreasonably high overhead. With any luck, this diagram will not only be helpful to me, but hopefully others currently working with the AST like Michelle and Kevin (if they can understand my shorthands and symbols), but will also lead to direction on how the API should encapsulate this same information in a more accessible manner.

Scope in Code Tests

My other task this week was beginning to think about how to resolve issues of scope for code tests. After a meeting early in the week, it was determined that this was the most immediately pressing issue with the code tests issue. To summarize: currently, the code test system is only examining individual nodes in the AST. However, there are many tests that are looking for a pattern among a set of nodes (for example, a test that is trying to find multiple identical methods in a row, to suggest replacing it with a count loop). Simply having a test say: "Yes, there is repeated code in this program" is not useful at all, whereas: "Yes, there is repeated code in this program, and it is these statements right here" provides meaningful information, and allows for the mentorship to actually fulfill its role.

By investigating this, it turns out there are really two issues at play:

1. There's no easy way to encapsulate information about several related nodes
2. The current code test system is currently incapable of even designing tests where this scope problem is an issue.

I'm going to talk to the group today about my initial ideas for solving both of these problems. Currently, to solve the first, I envision that, when a test determines that several consecutive nodes comprise a section of interest, it stores the first relevant node and last relevant node as the "bookends" of the section. Then, when we need to get the specific information about what the code block actually is, a crawler inserts a new node at the position of the first relevant node in the AST, called for instance a CodeBlockSection, and moves all the nodes into the body of the CodeBlockSection, until reaching the node indicating the end of the section. In this way, we would know that all the relevant code is now contained within the body of the CodeBlockSection.

Modifying the Code Test system itself is a little more challenging. My hope is to be able to use the current system as the base for the future system, as this would mean we can start writing tests for badges using the current system that would not be deprecated once a new system is in place. I believe that it is possible to keep the current Jython system, simply giving the user more control over customization, and make these tests possible. Again, hopefully the rest of the group will have feedback on this and we can come up with ideas to start investigating, designing, or coding next week.