Interpreter 6: quote

This is a "pair" assignment, which means that if you are working on a team with someone else, you and your partner should engage in the pair programming model. You should be physically together, sharing a computer and both looking at the same screen. Each partner has an active role to play during pair programming - please review the instructions on Moodle about pair programming, and make sure you understand what you should be doing when you are the navigator and when you are the driver.

You should make sure that over the course of an assignment that you spend roughly the same amount of time each "driving." My recommendation is to take turns approximately every 15 minutes or so. Set a timer to help you remember. I will also ask you to fill out a survey about your partnership at the end of the term.

For the interpreter project, you are permitted to do a limited amount of debugging separate from your partner. If you do this, you should be sure that you're each contributing similar amounts: it's not fair, either in terms of time or in terms of learning, if one person does all the debugging. Before debuggging on your own, make sure that your partner is onboard with that. Also, make sure to share what you found with your partner afterwards.

If pair programming in real-time just doesn't work for you and your partner, then you will need to amicably split up and work individually. If you choose this option, you must communicate that to me [Anna] and send me an email with a zip file containing the code checkpoint of any work you did together (if applicable).

If things are not going well with working with your partner or you find yourselves tempted to split up the work, please talk to me. While doing a limited amount of debugging separately is fine, you should be doing the initial design and coding together - if you or your partner cannot explain how part of your interpreter works, then you have not followed the pair programming policies for this class.

You'll download the folder with the starter code from the link below. Like for previous homeworks, unzip the folder and move it to where you'd like: most likely the folder for the Docker container. Then, copy over CollaborationsAndSources.txt from the previous milestone. Also copy over interpreter.c and all other .c files unless you are using the binaries I provide (if so, update justfile to look for those binaries). Then get started in VS Code.

If when running tests you run into a permissions error, you can fix this by running the following code in the terminal:

chmod a+x test-e test-m

This tells the computer that all users should be permitted to execute (run) the files test-e and test-m.

Click here to download the starter files.

For this phase of the project, you must support the correct evaluation of the following Scheme expression:

(quote expr)

You'll also need to be able to support the abbreviated form

'expr

That said, the parser should already be converting the second form into the first.

Do not implement quote by trying to somehow wrap up the quoted expression in some sort of enclosure indicating that it is quoted.

Some of you will feel tempted to do otherwise! Some of you may find that you are convinced that storing quote or a single quote somehow explicitly after evaluation will help you in some way. Some of you might even find that by doing so, you can succeed at this task. Don't do it. It's a trap. It might help you get this part of the assignment to work, but you'll get into hot water later - and it will be much more frustrating to go back through your old code and fix it later. This reflects a common and interesting point of confusion: quote does not tell the interpreter to do something to its arguments; rather, it tells the interpreter to not do something.

If you are feeling a strong urge to annotate something indicating that something is quoted, don't do it. If you are experiencing such compulsions because your tree is not printing properly, past experience has sometimes been that the problem is the code for printing the parse tree, not structuring it in the first place.

Exams may ask you to write paper C code to solve problems similar to the above. You may be asked to write the code from scratch, to fill in the blanks in partially written code, or to use some other technique to demonstrate that you can write code. To prepare, you should practice writing C code on paper that can accomplish tasks similar to the ones you worked on in this assignment.

This assignment is fairly short, so an exam might also ask conceptual questions. Why did we implement the quote form like this? Is quote a proper Scheme function, or not? Etc.

Submission and grading works the same as in previous assignments.

A special note on grading for thsi assignment: it's important you follow the instructions above about not wrapping up the quoted expression in some kind of enclosure. The code for quote is notable in what it doesn't do, rather than in what it does do. If you implement quote incorrectly, your code may pass all the tests at this stage, but things will not go smoothly in future project milestones. The graders will look at your source code to check whether quote was implemented correctly, without using enclosures.

Good luck, ask questions, and have fun!