Notes:

1. This is the second part of the Core interpreter project. In this part, you have to implement the parser, printer, and executor. You should use the same language, Java or Python, that you used for writing your Tokenizer.

2. If there are any special considerations for compiling and running your code, make sure you specify, in your README file, how your code is supposed to be compiled and run.

3. Your interpreter should take two command-line arguments. The first will be the name of the file that contains the Core program to be interpretd. The second will be the name of the file that contains the data for the Core program. Note that this is a change from the Tokenizer project. In that project, your Tokenizer read the input Core program from the standard input stream. But now, since there are two input files, the names of these files will be given as command-line arguments.

4. The Core program in the first file will not contain any illegal tokens but may contain other kinds of errors, i.e., not meeting the requirements of the BNF grammar of Core; undeclared variables; uninitialized variables; and another kind of error described in the next item.  If the Core program violates the BNF grammar or if undeclared variables are used in the <stmt  seq> portion of the Core program, your interpreter, before execution begins, should print an appropriate error message and stop.

5. The data in the second file will consist of a sequence of integers (positive or negative), one per line. This data will be read when your interpreter executes the “read” statements in the Core program. If this file is empty when the interpreter tries to execute a “read” statement, your interpreter should terminate with a suitable error message.

6. If during execution, the interpreter tries to access the current value of an identifier which has not yet been initialized, your interpreter should terminate with a suitable error message.

7. The output from your interpreter should go to the standard output stream.

8. If there are no such errors, the print-procedures of your interpreter should pretty-print the Core pro- gram and then execute the program.

9. Pretty-printing requirements: There are no specific requirements about what precisely “pretty-printing” means. Follow your own instincts on what would make the structure of any given program easy to un-  derstand and try to implement that. The goal is to make the structure of the code clear by just looking  at the pretty-printed version. Python’s indenting style is a good model to follow. Our eyes/brain seem  naturally wired to group together lines that are aligned (vertically) with each other.  So, the Python  model is a good one to follow; or come up with your own variation – as long as it makes the code  clear by looking at it. (This site seems to do a reasonably good job of describing best pravctices in  Python regarding formatting: Python best practices