Milestone 2: Front-End Complete

Project
October 24, 2021

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 24 2021, 23:59.

Grading

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

Your parser and static semantics should be defined in the same Spoofax project. The grader will search for your language definition in the chocopy.types, chocopy, and chocopy.syntax folders (in-order), using the first valid project it finds.

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-feedback 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.

Use the latest Spoofax

Please make sure that your project works on the latest Spoofax version (Spoofax 3 releases). The grader will be using the most recent version to grade your project.

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.