Grades and deadlines

• Initial deadline: 23:59 on Tuesday 02 September

• How to submit: Turn in a completed lab1.2.yaml file, your Interp.java file with a main method, and any other .java files I need to run your code, to the CS department submit system under SI413 / lab1.2

  If you used an AI tool to help with this lab (you should use Gemini), turn in a file aichat.md as well. Remember the course guidelines for the use of generative AI on labs.

• Grading:

  In this lab you will complete the following tasks:

  1. Choose one of the winning languages by your classmates from last week’s lab
  2. Write an example program in this language
  3. Write a complete interpreter for this programming language in Java
  4. Thoroughly test your interpreter yourself, and particpate in peer review to test your and your classmates’ interpreters for your language

  If your submission meets the requirements for each task, you will receive 10 points towards your total lab grade.

• Resubmissions:

  We will follow the same resubmission policy for all labs this semester:

  def points_earned(deadline, max_points, previous_submission=None):
      while current_time() < deadline:
          wait()
      submission = get_from_submit_system()
      if meets_all_requirements(submission):
          return max_points
      elif significant_progress(previous_submission, submission):
          return points_earned(deadline + one_week, max_points, submission)
      else:
          return 0
  

Getting started: files

Make a new directory for this lab.

Download the file lab1.2.yml into that directory.

As you complete your work for this part, you will fill in and eventually submit this file.

You will be programming in java and submitting java source code. Start by making an empty java file Interp.java with a main method.

Task 1: Choose a language

Here are specs for the winning languages invented by your classmates in last week’s lab. During lab, your section leader will run a “draft” to decide who works on what language.

• rds
• streamLine
• DRAMAQUEEN

Take note of who is working on the same language as you! This applies across all sections of SI413:

• If someone is working on the same language as you, they are eligible to act as a “final reviewer” for this lab. That should involve only testing your complete, working interpreter, not sharing any source code or helping with debugging.

• If someone is working on a different language than you, then it is OK for you to help each other with debugging your code for the lab, as long as this collaboration is clearly documented in the code and in your YAML file.

Task 2: Example program

Read the specs for your chosen language carefully! You will start by writing an example program in this language.

The requirements are the same as last week, except that (most likely) you didn’t design this language yourself! Ultimately you should be able to use this program to test your complete interpreter, but more importantly, writing this example program will help you actually understand how the language is supposed to work.

If you did a great job last week and the language you are working on is the one you designed, your reward is that you can re-use the same example program that you already wrote from last week’s lab!

REQUIREMENTS

Fill in the complete source code (along with comments) under the example_program field in spec.yml

Come up with at least two input/output test cases, representing sample input that could be entered at the console when your program is run, and the expected output that would be printed by your program as a result.

Fill these in under example_input_1, example_output_1, etc.

Your example program must:

• Be original, not the same as the example program given or anything your classmates turn in

• Demonstrate all of the capabilities that your language has in simple form, clearly demonstrating how your language is supposed to look and work.

• Demonstrate more complex parts to show how your language’s capabilities can be nested and combined.

• Make good use of code comments to explain clearly what your code means and what would happen if it were executed.

Task 3: Writing your interpreter

Write a complete, working interpreter for your programming language, in Java. Your main method in Interp.java should take one command-line argument, which is a filename of a program in your language, and then execute the code in that program.

REQUIREMENTS

Submit all the java source code required to compile and run your interpreter.

I will run your code like this:

javac *.java
java Interp some_file.txt

where some_file.txt is source code for your chosen language.

Your interpreter should only run the program specified and not print out anything else to standard out. If you want to have a nice “welcome” message or prompt strings, etc., be sure to print those to System.err only.

For credit on this lab, your interpreter must work on any valid program in your chosen language.

If your interpreter identifies an error in the input program, call System.exit(7); to indicate that your interpreter correctly identified the error and didn’t just crash. In this case, it doesn’t matter what your program prints; the only requirement is that it exists with that exit code.

Tips

This is a tough assignment, but you can do it! Here’s how I would proceed:

• Review what we did in last class to write a scanner for Java-style strings in a few different ways. Of course the string literals in your language won’t be like that, and you also need to read the rest of the code, but this should help get you started with either character-based or regex-based input.

• Start with the simplest possible program you can think of in your target language, and try to get your interpreter just to work for that. Like maybe a program that just prints out a single string literal.

  To start with, don’t worry about comments or anything else. Just try to get this simplest possible program working correctly. It should feel great!

• Add features carefully and deliberately, one at a time. Test thoroughly as you go, and don’t move on to the next feature until you are sure your interpreter is working 100% for what you have so far.

  Here is one order of features that might work well:

  1. Print statements and string literals, without escape sequences or anything fancy/strange inside the strings
  2. Allow for comments (which should be read in by your interpreter and then immediately discarded!)
  3. Add string concatenation
  4. Add string input
  5. Add string reversal
  6. If there are any escape sequences or unusual aspects to the string literals in your language, go back and get that working
  7. Test, test, test!

• Keep your interpreter code organized and well-documented. If you don’t keep good organization, it will be hard to add all the features and keep your code manageable and maintainable.

• You will end up having a bunch of small files for your test cases. Think about how you want to keep these organized. When you add a new feature to the interpreter, make sure to go back and check that you didn’t accidentally break something that used to work before!

Task 4: Peer testing

Peer testing is very straightforward this week: When you are testing someone’s interpreter, you mostly just need to run it on your big, complete example. If everything works, give your classmate a high five.

As with last week, everyone needs to act as the final reviewer for a classmate who is writing an interpreter for the same language. Ask your section leader for help if you don’t remember who is working on the same language as you.

REQUIREMENTS

Fill in the following fields in your spec.yml:

• reviewer_for: For which classmate are you serving as the final reviewer? (Just put their name.)

• reviewed_by: Which classmate is performing the final review on your submission? (Can be the same as the previous answer.)

• review_passed: Change this to Y when your reviewer agrees that your submission meets all of the requirements.

• reviewer_comments: Get your reviewer to write a sentence or two summarizing what they thought of your language design and spec.