Informatics 42 • Winter 2008 • David G. Kay • UC Irvine

Lab Assignment C

This assignment is due at the end of lab on Wednesday, February 20.

The problem: Complete Alex Thornton's version of the ICS 22 lab assignment, "Signal to Noise," available at http://www.ics.uci.edu/~thornton/ics22/LabManual/SignalToNoise/. You'll write a program that reads a grammar and generates a specified number of sentences using this grammar. Before you work on your own program, you can get a broader idea of what's possible by trying out the applet at http://www-cs-faculty.stanford.edu/~zelenski/rsg. The "Extension Request" grammar (the default) is pretty funny; also try out "CS assignment," "Programming bug," and "Math expression," along with any others that strike your fancy. Then follow the "Directory of the collected grammar files" link at the bottom of the page. For an idea of your program's possible input, pick some of those grammars to look at; "Math expression" is the easiest to follow. (There may be slight differences in grammar format between what's shown here and Alex's assignment; follow the assignment in that case.)

Entertainment isn't the only application of this program. Sometimes we need to test our software with a lot of data, more than we can conveniently generate by hand. With a program like this, we only need to create a grammar describing our test data an we can produce as much as we want.

Take note of these three additions/enhancements/clarifications to Alex's writeup:

• Alex's second "additional challenge," creating the symbol table using a TreeMap or a HashMap, is required for this assignment.


• Test your program with Alex's example grammar and make up at least two grammars of your own. If you get some really entertaining results, send them along to i42@uci.edu and we'll share them with the class.


• Along the lines of Alex's Facile grammar, make up a grammar for (a tiny subset of) Scheme or Java and see what kind of programs it generates. You could copy your random program output into DrScheme or Eclipse (or some other Java environment), not to run it but to get it automatically formatted to make it readable. (You can see a full grammar for Scheme and a full grammar for Java on line, but of course they're way too long to play with in this instance.)
  

When you face a program like this one (or the one you wrote in the last lab assignment), it's important to take it in stages. It's a bad idea to try to work on everything at once, nor is it a good practice to wait until you think you've got everything working before you start running and testing your program. One of the skills that you will begin to develop as you work on ever-larger programs is the ability to carve up a large program into smaller pieces that can be tested individually.

As you work on this lab assignment, consider working on it in the following stages.

• First, write the code that reads the input file. Rather than building up a set of objects like Grammars, Rules, RightHandSides, etc., just print some output to System.out that convinces you that your program is recognizing the tokens in the input file correctly. For example, your output might look something like this:

  
  Rule
    variable: program
    RightHandSide
      variable: statement
      terminal: NL
      terminal: .
      terminal: NL
    RightHandSide
      variable: statement
      terminal: NL
      variable: program
    ...
    RightHandSide
      variable: statement
      terminal: NL
      variable: program
  Rule
    variable: statement
    RightHandSide
      terminal: LET
      variable: variableName
      variable: number
    ...
  

  Don't feel that you have to get the output looking exactly like what you see above; in particular, don't worry about spacing it the way I did, unless you're inclined. Ultimately, you'll take out the code that writes this test output. It might feel downright wrong to write code that you intend to throw away, but this is a valuable technique, because it is one way to ensure that one part of your program works without depending on the others. When your program can write output like the example above for any input file, you know that you're done dealing with reading from the input file, and you can move on safely to the next stage.


• Write the classes that make up the object-oriented representation of the grammar: Grammar, Rule, RightHandSide, Symbol (an interface), Variable, Terminal. Don't worry about having them implement the Generable interface yet, and don't worry about teaching them to generate sentences; just worry about storing information within them. Then teach them how to turn themselves into Strings (by writing a toString() method in each class). You should then be able to print your entire Grammar to System.out by writing one line of code (assuming that your Grammar is stored in a variable called grammar):

  
  System.out.println(grammar);
  

  Your output can look much like the output that you wrote previously, but instead of testing the parsing of the input file, you'll be testing whether you've built up the objects representing the grammar correctly.


• Finally, include the Generable interface in the program, have the various grammar-related classes implement Generable, and write the generate() method in each. With a little bit more work to tie everything together, your program will be done!

Submit your own grammar files along with your code. Aside from that, the usual warnings, advice, policies, and practices apply to this assignment:

• Get started early.


• Read and re-read the specifications.


• Do this with a partner you haven't worked with yet this quarter (or let Kristina know that you're doing this one alone as your single "pair programming holiday").


• Submit all your Java source code (.java files) and your grammar files via Checkmate. Each pair should submit just one solution.


• The usual grading criteria for lab assignments apply.


• Fill out a partner evaluation at EEE.

Written by David G. Kay, Winter 2005; modified by Alex Thornton, Winter 2007, and by David G. Kay, Winter 2008.