A small request: README files

I get many assignments turned in as archives that expand to "Cool" or "Compilers".  I look in the README.txt file to remind me of which assignment was turned in by whom ... and usually what I see is the original README.txt from the scanner assignment.  Please replace the contents of the README file with some identifying information (e.g., "This is the type checker assignment, turned in by I.M. Smart and U.B.A. Mazed").   Thanks.

(I can deal with what I've got so far ... but please start doing this for the type checker and code generator assignments.)

AST assignment due Monday

As we decided in class, the AST-building assignment will be due Monday.

The requirement is very simple:  Parse Cool programs, and print the tree in any way you like.   Dot (GraphViz) is one very nice way to look at trees, but if you use it I suggest you find a way to look at just parts of the overall AST, because graphic depictions of large trees get unreadable fast.  While a nice indented listing is also good, I wouldn't invest a huge amount of time building a tree pretty-printer unless you think you will have other uses for it later.

Parser starter kit

Next assignment is to build a parser for Cool.   A starter kit (parts of the parser, plus a driver to call it) is at http://www.cs.uoregon.edu/classes/10W/cis461/handouts/parserKit.zip

A few notes on this:
- While in theory we got all the keywords and punctuation in the scanner, as I was finishing up my version of this I discovered I had missed a few ... so that's something to check when parsing fails.
- The driver accepts -d to mean "parse in debug mode", which is quite noisy but helps you see what tokens the parser is receiving and what it is doing with them. Unfortunately it prints them as numbers, so you need to look in sym.java to make sense of it.  (This is pretty stupid ... CUP could easily have translated those integer codes into their symbolic names, but it doesn't.) 
- I've filled in a lot, but left you a few things to figure out ... including how to make the comparison operations <, =, <= non-associative.   Note that you could use precedence declarations in CUP and not factor the grammar down as far as I have to get precedence ... feel free to do it that way if you prefer.
- In the test files, watch out for things that are in Aiken's version of Cool and not our version ---- e.g., one of the tests has loop ... pool instead of do ... od. 
- While my version of this (before I chopped stuff out for  you to fill back in) worked on one example, I do not guarantee it is correct.  You should write several small programs to test it.
- Small is beautiful, especially when you are debugging.  If your parser fails on a program of 30 lines, the first thing you should do is cut it down to a program of 5-10 lines with the same failure.

When you start getting "shift/reduce conflict" and "reduce/reduce conflict" error messages from CUP, you will need to understand the LR parsing theory that we will start talking about tomorrow (Friday the 15th).

The ID (identifier) token and what it represents

I was asked whether the scanner needs to recognize bad identifiers like foo.bar.baz .  The short answer is "no, that's a job for the parser", but the question indicates a need to be a little clearer about exactly what the identifier (ID) token represents.

foo.bar.baz is 5 tokens:  ID foo, DOT, ID bar, DOT, ID baz.  A scanner should in general not try to match anything with internal structure, like foo.bar(); it is returning the atoms of a program, to be assembled into molecules by the parser.    (I know the STRINGLIT token may seem like an exception, but from the parser's point of view it has no internal structure, even if the scanner has to do some work to interpret things like \n and \" inside the quoted string literal.)

Scanner assignment up

Grab http://www.cs.uoregon.edu/classes/10W/cis461/handouts/Cool.tgz to get started on the scanner (lexical analyzer) assignment.

I have filled in a lot of trivial grungy stuff and the stuff that doesn't really have anything to do with lexical analysis ... I think what's left for you to fill in should be pretty quick.   Keyword and punctuation patterns are certainly trivial ... you'll see the pattern in Cup.jflex Cool.jflex  and just fill in the few I removed.  Two patterns might take a bit more work: comments and strings.  There is a pattern for comments there already, and it *might* be right, but I don't promise.  There is a pattern for string literals, and I'd be really surprised if it is correct.   It's really ugly, too ... like a lot of complex regular expressions.  Consider using the lexical state facility of JFlex to break it down into simpler patterns that you can read, understand, and fix.

Java will complain that the generated scanner uses unsafe operations.  That's because the scanner skeleton file is written in the old, pre-generics style.   I'm using one of the optional skeletons because I threw in the ability to #include just for fun and to demo how that works ... it's not part of Cool, but it's something you'll want to do in another scanner some day. 

Due: Monday of next week.  The parser assignment will come out Monday or Wednesday.

The README.txt file says a bit more about what you'll find and how to get going.  Although the amount of work here should not be large, it's a good idea to tackle it soon, so that you have a chance to ask questions when things break.