Exercise 6: Featherweight Java

Hand in:Tuesday, January 30.

The provided framework is self-contained and can be downloaded as zip or tar.gz archive.

The API documentation for this exercise is available online.

Assignment

In this assignment you will implement Featherweight Java as presented in the document Featherweight Java A Minimal Core Calculus for Java and GJ" by Atsushi Igarashi, Benjamin Pierce and Philip Wadler in 1999.

Framework description

To get you up to speed, we included a full building parser for the language. You are free (encouraged) to modify it if it doesn't suit your needs (or find some bugs). You can even write your own parser from scratch. This framework is entirely optional (a word of advice, though: using the old combinator parsing library might make it much more difficult than it needs to be). A few remarks about the framework:

• The combinator parsing library is different. The most important difference is that there is no `build` method anymore, and semantic actions are interleaved with parsing rules (a la yacc). Sequential composition is now denoted by `++` instead of `&&`. Keywords now look nicer, since they can be listed as string literals. For instance:

```  def SimpleExpr: Parser[Expr] = positioned(
ident                                        ^^ &Var
| "new" ++ ident ++ "(" ++ Expressions ++ ")"  ^^ pair2fun2(&New)```

creates a parser which builds `Expr` trees. Expressions can be a simple identifier (and to build the tree, the function `Var` is called on the parsed tokens -- you notice the weird `^^` operator, which applies the tokens to the building function). The second rule parses a `new` expression, and creates a `New` tree, which takes as arguments the identifier and the list of expressions parsed by the `Expressions` nonterminal. Here is the definition of `New` and `Expressions`:

``` case class New(cls: String, args: List[Expr]) extends Expr
def Expressions: Parser[List[Expr]] = (...)
```

Since `ident` passes a string, and `Expressions` returns a `List[Expr]]`, the code is well typed.

• The `FieldDef` tree is used to represent both fields and parameter lists in methods and constructors. All three are really just lists of type and name pairs.
• All names are plain strings. In a production compiler one would use `Symbols` to keep track of names and associated information (like types). We don't do that.
• The paper talks about a global class table, and it might be useful to implement such a thing.