MC97 Lab 4: Semantic analysis (Spring 1999)

Due: March 22, 1999

For this lab, you are to do the type-checking assignment from page 127 of the textbook. Appel suggests doing the work in two phases, which he lists as Part a and Part b. This is a wise idea, although you may want to introduce even more steps than just those two. In any case, you need not turn in a separate solution for each part, just an end result.

First, copy the chap5 directory of files that Appel provides into the directory you are going to work in and look at them. You can access the chap5 directory off of this web page or copy it from ~max/www-docs/courses/S1999/MC97/tiger/chap5. The simplest way to do this would be using the command

cp -pr ~max/www-docs/courses/S1999/MC97/tiger/chap5 .

which will give you your very own chap5 directory tree, just like mine. Note that this time Appel hasn't provided much code on-line. You will need to type in quite a bit of code from the chapter (correcting it and fleshing it out as you go), and add some original code of your own. For those who are still having problems with the prior labs, I have included in the chap5 directory tree the compiled files Parse/Yylex.class, Parse/Grm.class, Parse/CUP$Grm$actions.class, and Parse/sym.java. If you replace these with your own versions from the prior lab, you will of course get more of the experience of building a large system up piece by piece.

Your lab report should include documentation of design and testing as well as your code.

Miscellaneous tips

You should enforce Tiger's rule that for-loop variables may not be assigned to in the loop body.
Checking type equality is something of a pain, given Appel's representation. The simplest approach is probably to use the coerceTo operation that he defines. For example, the code on page 121 would use
```
if(! left.ty.coerceTo(INT))
```
and so forth, where INT is declared as at the top of page 122.
Note that type checking a comparison (i.e., = or <>) of a RECORD with NIL has to work when written in either order, although only one is coercible to the other. Worse yet, comparing NIL with itself is illegal, and hence should be caught by your type checker.
ExpTy needs to use Types.Type, not Type, contrary to page 120.
Translate.Exp needs to be public, contrary to page 121.
Be sure to test early and often. For example, you can do some significant testing with only OperExp, IntExp, StringExp, and NilExp handled and no predefined names in the environment yet.
Note that you can temporarily add predefined names to the environment for testing purposes. For example, this would allow you to test variables before you have implemented declarations.
When using beginScope and endScope, it is preferable to use Java's try/finally construct to ensure that the scope is ended even if the code throws and exception.
To avoid cascading errors, you can use an UNKNOWN type, rather than arbitrarily picking on INT, and suppress type-mismatch messages concerning UNKNOWN. (This is a relatively low-priority improvement, so you might want to defer it until everything else works.)
Speaking of cascading errors, if you haven't yet improved ErrorMsg to keep a count and abort after (say) 10 messages, now would be a good time to do that.
From the Tiger specification, it appears that the expression () has type VOID, but that it is not legal for a variable to have type VOID. Thus it seems that your type-checker should flag the following code as illegal
```
 let var foo := () in 666  end
```
Be warned that if you leave out a method, your code can easily go into an infinite loop (assuming you type in Appel's code from the chapter more or less verbatim), because Appel has used the style in which the general dispatching methods share the same name (via overloading) as the more specific methods they dispatch to. Leaving out one of the more specific methods will make the dispatch method loop, dispatching to itself.

Instructor: Max Hailperin