CS152: Assignments

Note: All assignments should be submitted via the turnin system. The turnin program always keeps the most recent version of the program submitted.

Assignment 1

Assigned: Wednesday, June 28, 2006, in class
Due: Wednesday, July 5, 2006, 23:59
Late submission accepted until: Friday, July 7, 2006, 23:59.


[picture taken from slides by Peter H. Froelich]
Goal: Write the lexical-analysis specification for

• Read the "Lexical Issues" section of the MiniJava specification.
• Read the on-line JFlex manual. Chapter entitled "A simple Example: How to work with JFlex" might be particularily useful.
• Write the JFlex file for MiniJava. You can use the MiniJava.jflex skeleton file as the starting point.
• Study the MiniJava specification of your textbook and collect a complete list of tokens in the MiniJava language. Consider also the following additions to the MiniJava grammar:
  

  	Type -> String
  	Exp -> STRING_LITERAL
  

  String Literal: A string constant is a sequence, between quotas("), of zero or more printable characters, spaces or escape sequences. Allowed escape sequences are as follows:

  	\n	end-of-line
  	\t 	tab
  	\"	the double-quote
  	\\ 	backslash
  

  All other uses of the \ character inside a string literal causes an error.
• Download jflex script which contains paths to the Java compiler and JFlex classes. chmod +x it to make it executable. Run jflex script on the file you have written. If everything goes OK, you will have a file Lexer.java as the result.
• Compile and build the lexer. Note that JFlex was built (among other things) to be integrated with CUP parser generator (which is to be used in Assignment 2). However, for this assignment, we're omitting all directives that would allow one to incorporate the CUP parser generator. Instead, we're generating a standalone lexer using the %standalone directive inside the MiniJava.jflex skeleton file. The action code is also not returning any token, rather it should print the matched token onto the screen using the System.out.println() call.
• Test the Lexer class on several sample MiniJava programs:

  /usr/csshare/pkgs/jdk1.5.0_05/bin/java -classpath /usr/csshare/pkgs/jdk1.5.0_05/jre/lib/ext/java-cup-v11a.jar:. Lexer <MINIJAVA FILE> 
  

	1. SOME_TOKEN
	2. ANOTHER_TOKEN
	3. TOKEN_WITH_SEMANTIC_VALUE(5)
	...
	...
	Total number of lines: <the line count of the input file goes here>
	Total number of chars: <the char count of the input file goes here>

• Factorial.java
• BinarySearch.java
• BubbleSort.java
• TreeVisitor.java
• QuickSort.java
• LinearSearch.java
• LinkedList.java
• BinaryTree.java

Assignment 2

To Be Assigned: Wednesday, July 5, 2006, in class
Due: Tuesday, July 11, 2006, 23:59
Late submission accepted until: Wednesday, July 12, 2006, 23:59.


[picture taken from slides by Peter H. Froelich]
Goal: Generate a parser for the modified (check Assignment #1)

• Study the CUP manual.
• Study the grammar section of the MiniJava specification. You have to be able to distinguish between the terminals and non-terminals in your grammar. Terminals are the tokens the parser receives from the lexer. Non-terminals are the symbols appearing on the left hand side of the production rules in the grammar and are used to name syntactically equivalent groupings.
• Modify your MiniJava.jflex file from Assignment 1 as directed in Lab 3's "In Lab Exercise" section. However, just make sure you removed the %cupdebug directive before starting on this assignment.
  
• Write the CUP parser generator file for MiniJava. You can use the MiniJava.cup skeleton file as your starting point. Consider also the following additions to the MiniJava grammar:

  	Type -> String
  	Exp -> STRING_LITERAL
  	Exp -> Exp.length()
  

• Download compile and run-parser scripts which contain paths to the Java compiler, JFlex and CUP classes. chmod +x it to make them executable.
• Run the compile script on the files you have written as follows:

  ./compile <your jflex file> MiniJava.cup
  

• If no error messages are displayed, following files are generated: Lexer.java, Parser.java, Sym.java, after running the script.
• Test your parser on the sample MiniJava programs using the run-parser script as follows:

  ./run-parser <minijava input file>
  

• You should also overwrite the method syntax_error(String message, Object info) to report the line and column number of a caught syntax error. Your output for syntax errors should be displayed as follows:

  Error in line <line # of the error>, column <column # of the error> : Syntax error
  

• For MiniJava source files that contain syntax errors, the generated parser prints one more line of error message which briefly says that the parser couldn't continue to parse. Look in the CUP manual and find the method that displays the latter error message and ovewrite it so that the second error message is not printed.
• Please refer to the skeleton file to see where you should place your error message formatting code.

	exp -> num
	exp -> 1
	exp -> exp < exp
	exp -> 1
	statement -> num_aux = exp ;
	exp -> num
	exp -> this
	exp -> num
	exp -> 1
	exp -> exp - exp

• Download syntaxtree.jar and visitor.jar jar files.
• syntaxtree.jar file contains compiled Java Syntax Tree classes which are to become the nodes of the built AST. Respectively, visitor.jar contains the compiled Java Visitor and TypeVisitor interfaces which should help you traverse and process the formed AST.
• Alternatively, you can also download syntaxtree.tar.gz and visitor.tar.gz tarballs, in case you want to have the files locally.
• Read Section 4.3 entitled Visitors from the text so you get comfortable with the idea of visitor patterns. The concept of visitors are also to be covered during lecture and in lab. Understanding how accept and visit methods interact is crucial for this and future assignments.
• To use the Syntax Tree and/or visitor classes,(because they are in a different package) you have to explicitly import them with:

  import syntaxtree.*;
  import visitor.*;
  

  at the beginning of your MiniJava.cup file, among other places.
• To compile your Java code with the classes contained in the two jars, you need to type:

  javac -classpath syntaxtree.jar:visitor.jar:. YourFile.java
  

  but ultimately, you would like to avoid typing this altogether by automating your builds with an appropriately written Makefile (modify it as you please and from now on please make sure you include a Makefile with every assignment submission).
• Once you have coded the semantic actions of your parser, you should test your program with the following:
  • PrettyPrintVisitor: PrettyPrintVisitor is a visitor implementation that traverses the AST nodes and prints the source program back in a certain format.
  • Main: Main is the driver class which calls the PrettyPrintVisitor on the formed AST.
• Prior to testing, make sure you updated the PrettyPrintVisitor.java file to pretty print the added AST classes for the following productions:

          Type -> String
          Exp -> STRING_LITERAL
          Exp -> Exp.length()
  

• To test your program, type:

  java -classpath ./syntaxtree.jar:./visitor.jar:. Main <MiniJava Input File>
  

  You may as well place the above line in a script file to avoid the typing. Test your program with the input files MiniJava samples used in previous assignments.

• MiniJava.jflex
• MiniJava.cup
• PrettyPrintVisitor.java
• Makefile

• Download SymbolTable.java, BuildSymbolTableVisitor.java and, TypeCheckVisitor.java files.
• Files:
  • SymbolTable.java file is complete and contains the class definitions for the SymbolTable, Class, Method and Variable classes.
    • SymbolTable class holds the type information of all the declared classes in your program, where each class name is mapped to a Class object, which holds all the type information about a given class's variable and method declarations. 'class to Class object' mappings are stored in a Hashtable inside the SymbolTable class.
    • Each method is mapped to an instance of the Method class, which holds all the type information about a method's parameters, result-type and local variables. A 'method to Method object' mapping is stored inside the methods Hashtable member of the SymbolTable entry of the class in which the method is declared.
    • Similarly, each variable is mapped to an instance of the Variable class, which stores the variable's type information. This 'variable to Variable object' mapping is stored either inside the locals Hashtable of a Method object or inside the globals Hashtable of a Class object, depending on whether the variable is declared as a local variable inside a method or as an attribute of a class.
  • BuildSymbolTableVisitor.java and TypeCheckVisitor.java files are incomplete and simply contain the skeleton code that visits the AST of a given MiniJava program in a depth first order. For this assignment you're expected to place your code inside these two files.
• Type checking of a MiniJava program proceeds in two phases. In the first phase, you need to build the SymbolTable with all declared type information. Your implementation of this phase should go inside the BuildSymbolTableVisitor.java file.
• First Phase:
  • Study the SymbolTable.java and BuildSymbolTableVisitor.java files
  • For the first phase, you need to add code to the BuildSymbolTableVisitor.java file to process all the declaration nodes such as ClassDeclSimple, ClassDeclExtends, MethodDecl, VarDecl, etc.
  • When visiting the nodes derived from ClassDecl, you need to first form an entry for the ClassDecl node inside the SymbolTable using the addClass(...) method of the SymbolTable class. Next, you should set the BuildSymbolTableVisitor's currClass variable to that new entry (i.e. the Class object) for the current ClassDecl node in the SymbolTable. This way, refering to the currClass variable from within the visit methods for the VarDecl and MethodDecl nodes will allow you to add any member variables and methods of a ClassDecl into the right SymbolTable entry object.
  • Similary, when visiting a MethodDecl, you should set the BuildSymbolTableVisitor's currMethod class variable to the Method (SymbolTable entry) object of the current MethodDecl node. This way you can refer to the currMethod variable from within other visit methods and add any local variables and formals of a MethodDecl into the right Method object.
• Once all the declarations are processed and stored in the SymbolTable, you should type-check the statements and expressions. Your implementation of this phase should go inside the TypeCheckVisitor.java file.
• Second Phase:
  • Every statement and expression has its own type-checking rules. Following is an incomplete list of such rules. Others can be derived from MiniJava's semantics or by refering to the JAVA Language Specification:
    • Operands of arithmetic operations must have the same type
    • Operands of logical operations must have the same type and it's Boolean
    • Condition expressions of while and if statements must be of type Boolean
    • Right hand side of an assignment statement must either be of the same type as the left hand side or be a sub type of it
• Last but not least, please note the updates to the Main driver class.
• Update your Makefile from the previous assignment. Once everything compiles fine, you can test your program by typing:

  java -classpath ./syntaxtree.jar:./visitor.jar:. Main <MiniJava Input File> 
  

  You may as well place the above line in a script file to avoid the typing. Possible input files are MiniJava samples used in previous assignments.

	MiniJava.jflex
	MiniJava.cup 
 	BuildSymbolTableVisitor.java
 	TypeCheckVisitor.java

• Download Environment.java and InterpreterVisitor.java files.
• Files:
  • Environment.java file is complete and contains the class definitions for the Environment, ClassEnv, and MethodEnv classes.
    • Environment class keeps a stack of MethodEnv objects as well as the methods for getting/setting variable values within the active scope.
    • Each method call should create an instance of the MethodEnv class for the called method. MethodEnv class keeps hashtables to store the run-time values of the called method's parameters and locals. In addition, since each method has to be within some specific class's scope, the enclosingClass data member of MethodEnv class helps point to the ClassEnv of its class scope.
    • Similarly, each time a new instance of a MiniJava class is created, an instance of the ClassEnv class has to be formed for that MiniJava class. ClassEnv class keeps a hashtable to store the values of its data members at runtime. Whenever a method of a class instance is called, the ClassEnv for that class instance should be passed to the called method's MethodEnv constructor.
  • InterpreterVisitor.java contains the actual skeleton code for this assignment. You should mainly place your code inside this file.
  • Interpretation:
    • Interpretation means that you start executing from the public static void main(String[] args) method of the MainClass in your program. You need not to build a MethodEnv for the main method. This is because, neither the main method nor the MainClass contains any locals or data members whose values need to be accessed later in the program.
    • For all other methods, at the point of the method's call you should create a new MethodEnv instance for the called method and push it into the environment so that you may be able to access its contents from other visit methods. For any method, the variables visible in the scope are:
      • locals - Variables locally declared in the body of the method.
      • formals - Formal arguments (parameters) of the method.
      • data members - Variables declared when the class was instantiated.
      • (optional, read the Extra Credit part) data members of the ancestor classes
      Declaring a local shadows a formal with the same name, and a formal or a local shadows a data member with the same name.
  • Note the updates to the Main driver class Main.java.
  • Update your Makefile from the previous assignment. Once everything compiles fine, you can test your program by typing:

    java -classpath ./syntaxtree.jar:./visitor.jar:. Main <MiniJava Input File> 
    

    You may as well place the above line in a script file to avoid the typing. Possible input files are MiniJava samples used in previous assignments.
  
  Extra credit tasks: If you finished the mandatory part of the assignment, you might want to try the following:
  • Implement inhertiance (+10% extra)
    In this part you have to take care of the polymorphism issues: if class FlipFlop is a child of the class GenericShoe, then every time you create a FlipFlop object, you have to create data members of class FlipFlop (naturally), but also, you have to create data members of class GenericShoe because it may happen that inside a FlipFlop method you will need the data member from its parent.
    Since in Assignment 4 you had to take care of similar issues for the purposes of type checking, we believe the concept should not be too difficult to grasp. Hint: You need to add code to the Environment.java file.
  • Implement error handling (+5% extra)
    Runtime errors such as array index out of bounds as in new int[-56] should be reported. All errors should be reported as meaningfully as possible and with as much information as possible.
  If you solve any of the above extra credit tasks, please let us know explicitly, as follows: state it explicitly in the header comment of your InterpreterVisitor.java file, and e-mail both your instructor and TA to let us know what you did.
  
  Submission guidelines: You should only submit the following files:

      MiniJava.jflex
      MiniJava.cup
      BuildSymbolTableVisitor.java
      TypeCheckVisitor.java
      InterpreterVisitor.java
      Environment.java 
      Makefile
  

  No compressed files, nor any test or other script files should be turned in. Points are to be taken off if your submission fails to follow this guideline.