Homework answers / question archive / CSC 8310 Project Part 2: AST and Interpreter Objective The objective of this project is to gain a better understanding of some of the concepts and techniques we have discussed in class by implementing an interpreter for the language from part 1

CSC 8310 Project Part 2: AST and Interpreter Objective The objective of this project is to gain a better understanding of some of the concepts and techniques we have discussed in class by implementing an interpreter for the language from part 1

Computer Science

Share With

CSC 8310 Project Part 2: AST and Interpreter

Objective
The objective of this project is to gain a better understanding of some of the concepts and techniques we
have discussed in class by implementing an interpreter for the language from part 1.
Implementation
The focus is on writing an evaluator for the expressions comprising the project language. Operational
rules governing such an evaluator are the usual rules we have discussed in class in the context of
existing languages.
You will be able to integrate this code with the supplied code as well as your JavaCC grammar to
give you a full interpreter for the language.
You will implement the evaluator in Java. The evaluator is nothing but a function that, given an
environment, accepts an expression (in the form of an AST) as input and returns its value.
It is possible to have a run-time error situations. In such situations you must throw appropriate
exception(s).
Your approach will be object-oriented in that each expression (as an AST) will be an object that
comes equipped with its own evaluator function.
Following discussion about recursive types in class, we can represent the collection of expressions
as an abstract class. Each expression is then implemented as a (concrete) subclass of this class.
Furthermore, as discussed in class, each expression is evaluated in a given environment. Here are
some details.
public class EvalError extends Exception {// for run-time errors
EvalError() { super(); }
EvalError(String s) { super(s); }
}
public class UnboundVar extends EvalError {// a special case of run-time error
UnboundVar() { super(); }
UnboundVar(String s) { super(s); }
}
public abstract class Expr {// base class for ASTs
abstract public Value eval(Env e) throws EvalError;
abstract public String toString();
}

public abstract class Value {// base class for return values
abstract public String toString();
}
public interface Env {// Environment as an interface. Sample implementation supplied.
/* Looks up the (first) occurrence of identifier id in the environment.
If found, it returns the corresponding value, else it throws the exception.*/
public Value lookup(String id) throws UnboundVar;
/* Adds the binding of identifier id to value v in the environment and
returns the (new) environment. */
public Env addBinding(String id, Value v);
/* Changes the (first) binding of identifier id in the environment to
value v and returns the (new) environment. Exception if no binding exists */
public Env updateBinding(String id, Value v) throws UnboundVar;
public String toString();
}
Specics
For expressions, dene the following subclasses of Expr: IntConst, BoolConst, VarExp, BinExp,
NotExp, AssnExp, IfExp, WhileExp, LetValExp, LetFunExp, AppExp, SeqExp.1
The enum type BinOp denes constants for binary operations.
For values, dene the following subclasses of Value: IntVal, BoolVal, FunVal.
We recommend to test your interpreter/evaluator without parser and then integrate it into your
JavaCC grammar by including appropriate actions so as to return an object of type Expr upon
successful parse of a given expression.
A pre-compiled implementation EnvImp of Env is supplied for use with this project. In addition some
.java les (including the ones described in this handout) are also available. All these les can be
downloaded from the course webpage as a .zip le.
Details not covered here will be discussed in class.
Do not impose an explicit package declaration on the generated parser and associated classes.
Your JavaCC grammar must be contained in le named ProjLang.jj and must generate a parser
named ProjLangParser.
The start symbol of the grammar must be named input. It must return an object of type Expr.
1The only assumed dependency on our side is that the base class for expressions be named Expr and contain the abstract
methods with the specied signatures. You may change the names of other expression classes. You should not change the
names of any of the value classes since, in our testing, we assume objects of those classes to be the result of evaluation.

Submission Instructions
Upload project as a single zip le (see naming convention below) to the course page on Blackboard.
This le would contain your grammar le ProjLang.jj and JavaCC generated output folder con-
taining all .java les (auto-generated, pre-supplied as well as your own) plus all the pre-supplied
.class les implementing the environment.
Among these les, there must be the pre-supplied InterpretMain.java that invokes the generated
parser, reads input from stdin, evaluates the resulting expression, and prints the result onto stdout.
The name of the zip le must be of the form proj2-<your VU login name> (e.g.,
proj2-vgehlot.zip). When unzipped, the zip le must expand to a folder named
proj2-<your VU login name> (e.g., proj2-vgehlot) with all relevant les/folders inside it.
Make sure all the .java les are compilable. In particular, the pre-supplied le InterpretMain.java
must compile without any errors.
Separately (i.e. not as part of .zip le above), ll out the project submission checklist
(check-list-fillable.pdf) available from course webpage and submit online on Blackboard under
project 2 submission.2
Finally, submit separately under project 2 submission on Blackboard a written report containing
details of your tests and results.