CS 421: Programming Languages and Compilers

Note: All assignments, MPs and WAs, are done in PrairieLearn . MPs additionally require you to click on Open workspace to open a new browser tab running VSCode. There are instructions on each question telling you how to do this. Quizzes on the MPs are done in PrairieLearn, but entered through PrairieTest . For some events in PrairieTest, students will be required to self-register. Please watch for this requirement.

Note: MPs 1, 3, 5, 7, and 10 are assessed by an in-class quiz on the due date, and receive no value for the submissions in PrarieLearn outside of those quizzes. The quizzes will be selections of portions of the assignments. Practice quizzes will be provided, but they too will be selections of portions of the assignments.

Note: The late penalty is the PrairieLearn Late Submission policy, which caps your total score at 80%. It is not 80% of the number of points you earn. Doing extra credit can only lift your score to 80%, and will count for nothing after you have got to 80%.

Machine Problems for Spring 2024
MP No.:
Link:
Topic: Issued: Due at 23:59 CT
(11:59pm CT) on:
Automatic extension
(with 20% penalty)
until 23:59pm CT (11:59pm CT) on:
MP1 OCaml: Basic OCaml Jan 16, 2024 Quiz, Jan 23, 2024 None
MP2 Pattern Matching and Recursion Jan 23, 2024 Jan 30, 2024 Feb 1, 2024
MP3 Patterns of Recursion, Higher-order Functions Jan 30, 2024 Quiz on Feb 6, 2024 None
MP4 Continuations and Continuation-Passing Style Feb 6, 2024 Feb 20, 2024 Feb 22, 2024
MP5 Working with ADTs: Implementing CPS Transformation Feb 13, 2024 Quiz on Feb 27, 2024 None
MP6 A Unification-Based Type Inferencer Feb 27, 2024 Mar 19, 2024 Mar 21, 2024
MP7 Unification Algorithm Mar 5, 2024 Quiz on Mar 26, 2024 None
MP8 A Lexer for PicoML Mar 21, 2024 Apr 2, 2024 Apr 4, 2024
MP9 A Parser for PicoML Apr 2, 2024 Apr 9, 2024 Apr 11, 2024
MP10 An Evaluator for PicoML Apr 9, 2024 Quiz on Apr 23, 2024 None
MP11 A Transition Semantics Evaluator for CPS Apr 16, 2024 Apr 30, 2024 May 1, 2024 (%10 penalty)

Web Assignment (WA) Problems for Spring 2024
WA No." Topic: Issued: Due at 23:59 CT (11:59pm CT) on: Automatic extension
(with 20% penalty)
until 23:59 CT (11:59pm CT) on:
WA1 Evaluation and Evironments Jan 18, 2024 Jan 25, 2024 Jan 27, 2024
WA2 Order of Evaluation Jan 25, 2024 Feb 1, 2024 Feb 3, 2024
WA3XC Extra Credit: Evaluating the Application of a Function Feb 1, 2024 Feb 15, 2024/td> May 1, 2024
WA4 CSP Transformation; Working with Mathematical Specifications Feb 8, 2024 Feb 22, 2024 Feb 24, 2024
WA5 Polymorphic Type Derivation Feb 22, 2024 Feb 29, 2024 Mar 2
WA6 Incremental Unification Algorithm Feb 29, 2024 Mar 21, 2024 Mar 23, 2024
WA7 Regular Expressions Mar 19, 2024 Mar 28, 2024 Mar 30, 2024
WA8 Parse Trees Mar 28, 2024 Apr 4, 2024 Apr 6, 2024
WA9 Natural and Transition Semantics Apr 4, 2024 Apr 18, 2024 Apr 20, 2024
WA10 Lambda Calculus Apr 18, 2024 Apr 25, 2024 Apr 27, 2024
WA11 Hoare Logic Apr 25, 2024 May 1, 2024 None

Instructions for Submitting Assignments
  • All assignments, both MPs and WAs, will be available through PrairieLearn and will be collected there.
  • When you do an MP in PrairieLearn, you will do your work for each problem in a VSCode Workspace. The introductory webpage for the problem gives you instructions for how to do the problem, including the problem statement. To actually do the problem, you will need to click the button "Open workspace", which will open a new tab in your browser running the VSCode editor/programming environment. It will present you with a directory, the ability to open and edit files in that directory, and an ability to start a terminal window, running linux, in which you can run ocaml, to build and test your code. The directory provided will contain a file with a name (typically problem.ml (or problem.mll or problem.mly)) and infrastructure to help you test your code. The file problem.ml is just a stub. To build your answer, you need to delete or comment out the stub code and add your own. The next section Guide for Doing MPs contains further information about how to test your code.
    Before submitting an MP assignment, you MUST make sure that your MP compiles with the student grading script supplied with the assignment. If your MP fails to compile with the student grading script, your assignment will get NO CREDIT. There will be no partial credit for assignments that fail to compile.
  • You may do multiple commits of either the MPs or the WAs. Your score will be the best of all your submissions, but the score of late submissions will have a late penalty applied, meaning it will only help your assignment score if the best score you received was less than 80% before the on-time due date. Work submitted before the late deadline will not be subject to the late penalty, but work submitted after will.
Guide for Doing MPs
A guide for how to attack an MP:
  1. For each problem in the assignment, go into the VSCode Workstation for the problem, and start a terminal window. To make sure you have all the necessary pieces, in that terminal window, start by executing make. This will create the grader executable. Still in the terminal window, run the executable (./grader). Examine the failing test cases for places where errors were produced by your code. At this point, everything should compile, but the score will be 0.
  2. Read and understand the problem from the assignment on which you wish to begin working. (Usually, working from top to bottom makes most sense.) There is a tests file in this directory. This is an important file containing a partial set of test cases; you'll want to add more cases to test your code more thoroughly. Reread the problem from the main webpage for the problem, examining any sample output given. Open the tests file in the WORKSPACE directory. Review the test cases given for that problem. Add your own test cases by following the same pattern as of the existing test cases. Try to get a good coverage of your function's behavior. You should even try to have enough cases to guarantee that you will catch any errors. (This is not always possible, but a desirable goal.) And yes, test cases should be written even before starting the implementation of your function. This is a good software development practice.
  3. If necessary, reread the statement of the problem once more. Place your code for the solution in problem.ml (or problem.mll or problem.mly as specified by the assignment instructions) replacing the stub found there for it. Implement your function. Try to do this in a step-wise fashion. When you think you have a solution (or enough of a part of one to compile and be worth testing), save you work and execute make and the ./grader again. Examine the passing and failing test cases again. Each failure is an instance where your code failed to give the right output for the given input, and you will need to examine your code to figure out why. When you are finished making a round of corrections, run make, followed by ./grader again. Continue until you find no more errors. Consider submitting your partial result so that you will at least get credit for what you have accomplished so far, in case something happens to interfere with your completing the rest of the assignment. You can submit one problem at a time in earlier assignments. In later assignments, problems tend to be pieces of functions. It is still worth your while to do incremental submissions.
  4. When your code no longer generates any errors for the problem on which you were working, return to steps 3) and 4) to proceed with the next problem you wish to solve, until there are no more problems to be solved. Each problem is submitted in PrairieLearn indepentantly of the others, but some later assignments have only one problem.
  5. When you have finished all problems (or given up and left the problem with the stub version originally provided), you will need to submit your code to PrairieLearn.

Interactive Debugging
In addition to running "make" and "grader", you probably want to test and debug your code interactively at the top level:
  1. Enter the directory with your source file.
  2. Type ocaml at the command line.
  3. Type #load "common.cmo";; at the OCaml prompt, if there is such a file inthe WORKSPACE directory. (This loads in the common stuff that we give you in compiled form by default).
  4. Type #use "problem.ml";; at the OCaml prompt, where problem is the name of the problem, which is typically the name function being implemented. This loads in your code, and adds the functions you have defined to the identifiers recognized at top level.
  5. Type in commands followed by ';;' at the OCaml prompt to test your code interactively. Anything that you can do in a code file, you can do interactively. For example, you can define identifiers using 'let x = ...', etc...
  6. With each MP, you will be given a solution in compiled form. You may interactively test the solution to a problem, after having loaded "common.cmo" if there is one, by loading the solution file by typing #load "solution.cmo";;. After that, if you are supposed to write a function called, say splat, and wish to find out what it does on an input, say 39.2, you may execute the solution's version of splat by typing Solution.splat 39.2;;. Notice the capitalization.