Creating an Interpreted Language: Part 3

1 What to do

This project will explore the topics learned in class, and give you some simple hands on experience. After completing all three parts, you should have a working interpreted language that is unique to you. You are encouraged to have fun and go above and beyond if you have the time.In Part 3 , you will then need to make another small, but substantial change, and create the interpreter for the modified language. Part 3 assumes you have your lexer form part 1and parser from part The changes you make may affect your lexer and will affect your parser. So, you may need to go back and update the lexer and parser. If for whatever reason, you do not want to use your lexer from part 1, a lexer was provided in part 2.All code should be written in either C,C++,Java, or Python.

1 What to do
• Once again modify your language. Use the knowledge in class to decided what change to make. Think about when things should be bound, and the design issues the bookpresents for the language feature you are considering. For instance, In chapter 6,the book gives the method for implementing arrays. You can use this information todecide the exact kind of arrays you want (assuming that is the change you wish tmake).
• If the changes to your language causes the grammar to no longer be an LL grammar, then modify the grammar to make it LL.
• Implement the interpreter in your chosen language. There are several ways to doing this, but the most straight forward is use the parser to convert the program into someintermediate form such as a parse tree or a list of commands, and then execute the
code based on the intermediate form. You may also execute the code directly in the parser, but some care will be needed when dealing with loops and if statements.

• When modifying the parser, be sure to check the static semantics (not variable is used before it is defined).

2 What to turn in
Upload your submission as a zip archive containing the following:
• Source code (c, c++, python, or java files)
–Source code should not require a particular IDE to compile and run.
–Should work on the cs1 and cs2 machines
• Readme (Plain text document)
–List the files included in the archive and their purpose
–Explain how to compile and run your project Organization of Programming Languages Page 1

–Include any other notes that the TA may need
• Write-up (Microsoft Word or pdf format)
–An description of your changes. This can be formal (modifying the grammar and semantics) or informal (A text description)
–In addition, if you did not complete some feature of the project, why not?
? What unsolvable problems did you encounter?
? How did you try to solve the problems?
? Where do you think the solution might lay?
· What would you do to try and solve the problem if you had more time?

If you were not able to complete some part of the program discussing the problem and potential solutions in the write-up will reduce the points deducted for it. For example,suppose there is a bug in your code that sometimes allows two customers to approach the same worker, and could not figure out the problem before the due date. You can write 2-3 paragraphs in the write-up to discuss this issue. Identify the error and discuss what youhave done to try to fix it/find the problem point, and discuss how you would proceed if you had more time. Overall, inform me and the TA that you know the problem exists and you seriously spend time trying to fix the problem. Normally you may lose 5 points (since it is a rare error) but with the write-up you only lose 2. These points can make a large difference if the problem is affecting a larger portion of the program.