CS 423 HW#5

Perform type and mutability checking for k0. This consists of the following items. Please turnin via Canvas an electronic copy of your whole project in a .zip. Please create your .zip file in such a way that it unpacks into the current directory, rather than a subdirectory.

Note: if you haven't already, add -Wall to your makefile compile rules, and for maximum credit, turn in a solution that compiles with no warnings when -Wall warnings have been turned on.

Types

Support the k0 base types. Support Int, Double, Boolean, Char, String, Arrays and functions.

Type Checking

Require and check types everywhere at compile-time.

• Check that method call signatures match method declarations
• Check that operators' operands are compatible

Operators

The semantic rules for operators are all nearly the same as discussed previously. k0 supports the operators =, +, -, *, /, subscript ([ ]) and dot ( . ), etc. Support the boolean/relational operators <, > and, or, not, etc.

Built-ins

You should insert into appropriate symbol tables the names of built-in k0 functions.

Nesting

Expressions will generally get combined to form larger expressions. This includes nested calls as parameters to other calls, chains of dot operators for structs, etc.

Mutability Checking

Each symbol should have a boolean semantic attribute for mutability. You may need to synthesize and/or inherit mutability properties for those symbols in the subtrees where they are declared, e.g. via a tree traversal. Assignments (other than initializers when the variable is declared) should be refused for variables not marked as mutable.

Nullibility Checking

Each symbol should have a boolean semantic attribute for nullibility. You may need to synthesize and/or inherit nullibility properties for those symbols in the subtrees where they are declared, e.g. via a tree traversal. Semantics are as per Kotlin. Assignments of nullible values to non-nullible variables should be errors, etc.

Notes:

• your executable should be named "k0", not k0compiler, etc.
• write out the name of the source file to standard out when you open it
• do NOT write out the tree, or other debugging information, by default; you may add command line options to print that info if you want.
• error messages should be written to standard error not stdout
• if ANY file has a lexical error, your process exit status should return 1, for a syntax error 2, for a semantic error 3, and for no errors, return 0.