Milestone 2: Front-End Complete

In this milestone you re-submit your syntax definition and submit your static semantic definition.

Submission

You need to submit your ChocoPy project with a merge request on GitLab. The Git and Submissions documentation explains how to file such a request.

The deadline for submission is October 25 2020, 23:59.

Grading

We grade your submission based on compliance with the ChocoPy syntax and static semantics as defined in the reference manual. We grade both your chocopy.syntax and your chocopy.types projects separately. During the course of the project, you therefore get another chance to improve your score for your syntax definition.

Early Feedback

We provide early feedback for the correctness of your syntax definition. This feedback gives you an indication which parts of your syntax definition might still be wrong. It includes a summary of how many tests you pass and how many points you earn by passing them. You have 15 early feedback attempts. Please make your submissions to the milestone-2-submission branch.

We also provide you with the opportunity to improve your Syntax Definition once again, by providing Early Feedback for the milestone-1-submission branch again. You can choose to improve your Syntax Definition before the deadline of milestone 2, as we will include it in the grading for milestone 2. If you choose to not make a new submission, the current state of the branch will be used for the grading process. You also have 15 Early Feedback attempts for this part of the assignment.

Details on when the Early Feedback is available will be provided soon!

Use the latest Spoofax

Use the latest release of the CC release of the Spoofax language workbench.

Use the new parser

We highly recommend you use the new layout-sensitive parser. Details on how to start using this parser can be found here: http://www.metaborg.org/en/latest/source/langdev/meta/lang/sdf3/configuration.html#jsglr-version. Make sure to use the layout-sensitive variant and to update Spoofax (either download the newest version here or follow the update instructions) to actually get the latest version of the parser.

If your project does not use it, there is a chance that you will fail certain tests for the early feedback/grading pipeline.

This new parser fixes a couple of bugs dealing with layout constraints not being properly recognized, and non-associative productions not producing an error. If you have written any tests for these yourself, you might need to update them.

General development procedures

Here are some general tips you can apply when creating your static semantics definition:

• Do the homework exercises in WebLab and go through the slides and relevant literature, as they serve as an introduction to Statix.
• Read the ChocoPy reference thoroughly. It helps to revisit it later to discover some edge cases.
• Make use of the compiler on the ChocoPy website. If it compiles, it is valid semantics even if the program itself can crash (for example: print(None) is valid according to the type checker, but trying to execute this program will still result in an error).
• Write tests! We expect you to write tests for valid and invalid static semantics, as well as name resolution and type checking. A more detailed tutorial on how to write tests for your static semantics can be found in Lab 3B.
• Start with small examples, and work your way up.
• Make sure to assign proper ref and type properties to your AST nodes (See homework/slides).

Debugging Statix

Here are some things you can try when you are witnessing unexpected behavior in your editor:

• Temporarily comment out irrelevant rules/lines in Statix in order to narrow down the problem.
• Write test cases to reproduce the problem you are facing
• You can force the failure of a rule by using false as a constraint. For example: programOk(_) :- false.
• You can (temporarily) log some information or variables by using the try { <constraint> } | <error> <message> <location> constraint. For example: programOk(program) :- try { false } | note $[Error message for [program]]@program. . Here <error> takes the form of note, warning or error (which will cause the analysis to fail), and <location> is optional.
• Draw out scope graphs on paper. Are there differences between the scope graph that is defined by your rules, and the one you expect?

Static Semantics

We expect your static semantic definition to perform valid name resolution and type checking. Some things to pay extra attention to are:

• Inheritance
• Nested functions
• Global/nonlocal declarations
• Shadowing variables, fields and function names
• Built-in/native functions and constructors
• List types (least upper bound)
• Return Statements
• Method overriding
• Return type of void functions
• Usage/resolution before the definition

A small note on types

It is highly recommended you directly use the following types in your Statix rules:

• Integer: Int()
• Boolean: Bool()
• String: String()
• List of Type T: List(T)
• Empty list type: EmptyList()
• None type: NoneType()
• Class with name Foo and scope s: ClassType(s, "Foo")
• Function with return Type RT and a list of parameter types PTs: FunType(RT, PTs)
• Object: Object()

These are the types we test for in our early feedback/grading pipeline.

If you use different types in your Statix rules, you need to transform (i.e. map) your types to our types. For this purpose, transformation rules in the Stratego language are given in Lab 3B, which you have to extend/implement/test yourself to make them suitable for your type checker.

Write your own tests for type checking to confirm that your transformation rules work. Please include these rules in your submission, as we need them in our tests. Make sure to define a sort and the different constructors of your custom types in this file as well, so Stratego can recognize them, and match on them.

When all else fails…

Should you run into any issues regarding Statix or the assignment, please contact us during the labs (Tuesday Lab or Wednesday Shared Study Lab) or on Mattermost.