Syllabus¶
Note
This is a tentative syllabus and subject to change.
Many of the computations computers process are done via executing programs. But how are these programs (e.g., Google Chrome, Adobe Photoshop etc.) actually created? As programmers write and create new programs, we use these “magical” programs known as compilers that convert the code we write into executable programs. In this course, we will explore the major ideas used today in the implementation of compilers, including lexical analysis, parsing, syntax-directed translation, abstract syntax trees, types and type checking, intermediate languages, dataflow analysis, program optimization, code generation, and runtime systems. By the end of this course, you will know how a program written in a high-level language designed for humans is systematically translated into a program written in a language that a computer can execute. Additionally, we will explore how programming languages are designed, their semantics, and how knowing how a compiler works also makes you into a better programmer and increases your ability to learn new programming languages even faster.
Prerequisite: Core Programming, Familiarity with C, Java, and/or Python
Course Staff¶
Instructor
Lamont Samuels
Teaching Assistants
Skye Soss
Graders
TBD
Lecture Structure¶
You will meet with the instructor once a week. We will use this time to cover additional material, review material covered in the pre-recorded lectures, work through exercises, or have a discussion. This class will be structured in a hybrid manner, which means you can attend class in two ways:
In-Person - Come to campus at the designated time and location provided below.
Remotely - You can join and watch the lecture remotely via a Zoom link. You will have access to the Zoom links inside Canvas. Please reach out the instructor if you do not have access to the Zoom links.
Most weeks, there will be a series of pre-recorded lectures that you must watch before attending lecture. More details are provided in the syllabus.
Section |
Time |
Location |
Instructor |
---|---|---|---|
Section #1 |
|
JCL 011 & Zoom |
Samuels |
Course Structure¶
MPCS 51300 will follow a flipped classroom model, where the lecture material and course content will be delivered in two ways:
Asynchronous content (i.e., pre-recorded videos): Each week before our normal class time, you will be required to watch pre-recorded videos and do readings. The videos will include lecture content that would be normally covered in a traditional lecture setting (i.e., non-remote setting). These videos and readings will typically range between 1 hour to 1.5 hours and be posted a few days before our scheduled time. Feel free to watch them at your convenience. However, you are required to watch and do the readings before we meet live.
Synchronous content (i.e., in-person/ zoom meetings) : Each week during our normal class time, we will meet either in-person at the time/location designated above or via Zoom, where you will join via a Zoom invite. These invites are accessible via Canvas. The synchronous lectures will include the following:
Followup on the material covered in the videos. This may include going into further details about the content.
Provide additional course content not covered in the videos/readings.
Allow you to ask questions about the content provided in those videos.
Have live coding sessions/activities with everyone.
Please see the calendar for more details on what happens on a week to week basis.
Coursework¶
The course will include weekly homework and attendance, one midterm exam, and a project (with milestones):
Homework - The weekly homework assignments will contain practice problems to help enforce the concepts learned during a lecture.
- Attendance - In order to receive you full attendance weight, you must do the following
Attend every lecture (either in-person or remotely). If you cannot attend a lecture then you must reach out to the instructor letting them know you won’t be able to attend.
2. You must watch any specified pre-recorded lectures. We will look at the statistics on Panopto to ensure you watch the videos. As long as you continuously do those two main points you will receive full credit for attendance.
Compiler project - There will be a single quarter-long project where you will develop the components that make up a compiler: front-end (scanner, parser, type checker), back-end (code-generation), and optimizer. You need to submit the fully working project by the end of the quarter as specified via the assignment description.
Milestone - There will be milestones that will you need complete by certain due dates. These milestones check to ensure that you are making progress on the various components of the compiler. The grading of these milestones will be somewhat subjective in nature but each milestone description will provide a grading outline to help understand what needs to be completed by the milestone due date.
All homework and projects will be due on Wednesdays @ 11:59pm. The new assignments will be out by Thursday morning. I will post when they are available. Please note that I am normally busy on Friday afternoons and weekends so I may not be available for additional help. Please make sure to take this into consideration as you manage the coursework in this class.
Please see the Assignments Rubric page for more details on how the assignments will be graded.
Exams¶
There will be one midterm exam in this course. The midterm will be a mixture of coding exercises and short-answer questions. You will be given 4 days to complete the online exam.
Exam |
Time Limit |
Out Date |
Due Date |
---|---|---|---|
Midterm |
90 minutes |
October 28th @ 12:00pm |
November 1st @ 12:00pm |
The exact details about how this exam will be administered will come as we approach the exam date. There are no make-up exams in this class. There also will not be any earlier exams taken unless due to extraordinary circumstances such as an medical emergency.
Course Software¶
Go will be the required language to code all programming assignment. You do not need to know the language in order to take this course. If you haven’t already learned it then you will learn it as the course progresses. It’s a very small and simple language that prior students all had no difficulty learning. I will provide a rationale for the language during the first lecture.
Please make sure you have following software installed for this course:
Golang 1.17 You may also use any version of go from 1.15 and on.
Text editor (suggestion, not required): Visual Studio Code
IDE (suggestion, not required): GoLand
The course software is also accessible via logging in remotely to a CS Linux Machine. We will explain how to do this during the first week of the quarter. There might be additional software to install as the quarter progresses but the course staff will let you know how to install it.
Grading¶
Your final grade will be based on the following:
Final Compiler Submission |
45% |
Milestones (5% each) |
15% |
Homework (each 5%) |
25% |
Attendance |
5% |
Midterm |
10% |
Grades are not curved in this class or, at least, not in the traditional sense. We use a standard set of grade boundaries:
95-100: A
90-95: A-
85-90: B+
80-85: B
75-80: B-
70-75: C+
<70: Dealt on a case-by-case basis
We curve only to the extent we might lower the boundaries for one or more letter grades, depending on the distribution of the raw scores. We will not raise the boundaries in response to the distribution.
So, for example, if you have a total score of 82 in the course, you are guaranteed to get, at least, a B (but may potentially get a higher grade if the boundary for a B+ is lowered).
Late submissions¶
You are allowed to make at most two late submissions on the programming assignments. Late submissions will be accepted up to 24 hours after the deadline. You are allowed to double up on your late submissions (i.e., if you have not used your two late submissions, then you can use them back to back).
No credit will be given for late submissions after you have used up your two allowed late submissions.
No credit will be given for any submission made 24 hours after the deadline.
Please note that, while Gradescope does enforce the 24-hour limit on late submissions and will clearly flag late submissions with a red “LATE” label, it does not enforce our specific limit of two late submissions. It is your responsibility to keep track of how many late submissions you have made so far, and to ensure you don’t make more than two late submissions.
If extraordinary circumstances (medical and family emergency etc.) prevent a student from meeting a deadline, we may grant additional extensions on a case-by-case basis. Whenever possible, the student must inform their instructor of these extraordinary circumstances before the deadline.
Please note that having a heavy workload in a given week does not qualify as an extraordinary circumstance. The purpose of the two extensions is precisely to give you some flexibility in weeks when you are busier than usual. Additionally mild COVID or common cold illness is also does not qualify as an extraordinary circumstance.
You are not allowed to use a late extension on the final compiler submission.
Regrades¶
We sometimes make mistakes, and are happy to review any incorrect grading decision.
However, please note that we will only consider regrade requests where a grader made an actual mistake (e.g., they took points off claiming you didn’t do something, when you actually did do it and the grader maybe missed that when reading over your submission). We will not consider regrade requests that ask for point penalties to be reduced, or try to argue that we should not be taking points off for a given issue in your code.
For example, suppose you receive a penalty that says “-2 points: Function X did not check that parameter Y is greater than zero”. If function X in your code did perform this check, and the grader missed this fact (and erroneously applied that penalty), you can submit a regrade request asking us to review this decision. We ask that you keep these requests brief and to the point: no more than 1-2 paragraphs identifying the exact penalty and the reasons you believe it was applied erroneously, including references to specific parts of your code (e.g., “I did check the value of the parameter in line 107”). Focus on laying out the facts, and nothing else.
On the other hand, let’s say you received the “Function X did not check that parameter Y is greater than zero” penalty, and function X in your code did not perform this check. In this case, you cannot submit a regrade request arguing that this is not something for which we should deduct points, or that the point deduction should be lower. Please note that all penalties are explicitly approved by an instructor (graders have no discretion to come up with penalties on their own and, if they took points off for something, it is because they were directed to do so by the instructors).
Please note that, while you may request a regrade for a specific issue, an instructor may do a full regrade of your submission if they feel there are other issues with the grading of your submission. This can result in you ending up with a lower score on the assignment.
Steps to Submit a Regrade Request
Read over the above section to make sure your request will not be denied.
All regrades must be submitted on Gradescope. Do not write on Ed asking for a regrade request. However, you can on Ed notify the instructor(s) that you submitted a regrade request on Gradescope.
Finally, it is also your responsibility to make these requests in a timely manner. Requests for regrades must be submitted no later than one week after a graded piece of work is returned to you. After that time, we will not consider any requests for regrades, regardless of whether the regrade request is reasonable and justified.
Please allow time for the course staff to review your regrade request. We cannot provide a specific timeframe when your request will be handled. We are on a tight schedule grading other assignments but your request will be reviewed before the end of the quarter.
Books¶
This course will not have a required textbook; although, for those students who may find it helpful to know the topics we will discuss each week, readings will come from the text:
Engineering a Compiler (Second Edition) by Keith Cooper and Linda Torczon
and will be shown on the course schedule. Along with these readings and the lecture notes, students may find the following references helpful in understanding the course material:
Compilers: Principles, Techniques, and Tools (Second Edition) by Alfred Aho, Monica Lam, Ravi Sethi, and Jeffrey Ullman
The Go Programming Language by Alan A. A. Donovan and Brian W. Kernighan
Policies¶
Policy on academic honesty¶
We take academic honesty very seriously in this class. Please make sure to read our Academic Honesty page.
Zoom guidelines¶
We will be using Zoom for some parts of this class. We expect your interactions via Zoom to be consistent with an in-person class experience. Respect the people you’re working with. Enter the Zoom meetings muted if possible (unfortunately, it will not be possible if you’re calling in), and unmute to speak. Raise your hand if you’d like to speak. [There’s a “Raise Hand” button on the participant page.] If your background is unusually noisy, use the chat channel instead of unmuting. We strongly encourage you to have your camera on during our Zoom sessions, but we’ll understand if some of you prefer to keep your video off.
Note that you can set your name in your Zoom profile, so you don’t have to go with whatever was assigned. Feel free to include your pronouns in your name (if you do, please include them after your last name).
Some of our Zoom class meetings will be recorded and saved to the cloud to allow students in this class to review the discussion, and especially to allow students who can’t participate the opportunity to benefit from class. We will not make these recordings available to anyone but class participants, we will not make them available after the quarter, and students will not be allowed to save copies. However, we have no way to guarantee that students will follow this policy. If you have FERPA concerns, please mask yourself accordingly, e.g., by turning off video and using an alias.
Diversity statement¶
The University of Chicago is committed to diversity and rigorous inquiry that arises from multiple perspectives. We concur with that commitment and also believe that we have the highest quality interactions and can creatively solve more problems when we recognize and celebrate our diversity. We thus expect to maintain a productive learning environment based upon open communication, mutual respect, and non-discrimination. We view the diversity that students bring to this class as a resource, strength and benefit. It is our intent to present materials and activities that are respectful of diversity: gender, sexuality, disability, socioeconomic status, ethnicity, race, religious background, and immigration status. Any suggestions as to how to further such a positive and open environment in the class will be appreciated and given serious consideration.
If you have a preferred name different from what appears on the class roster, or preferred gender pronouns you would like us to use, please let us know.
Disability statement¶
If there are circumstances that make our learning environment and activities difficult, please let us know. We will maintain the confidentiality of any such discussions.
MS-CAPP students who need to request formal accommodations due to a disability should follow the Harris Accommodations Process. PhD students should contact their program administrator for information about how to request formal accommodations.
COVID-19 Policies¶
UChicago Health Pact¶
All students on campus are required to adhere to the guidelines in the UChicago Health Pact in order to promote a safe environment in the classroom.
Secure face coverings must be worn appropriately at all times while in University buildings
Maintain a distance of 6 feet from others
Do not attend an in-person class if you feel unwell or are experiencing COVID-19 related symptoms
The complete text of the UChicago Health Pact along with additional information about COVID-19 protocols can be found here.
Reporting COVID-19 Exposure or a Confirmed Case¶
If you were potentially exposed to COVID-19 or your COVID-19 test results come back positive, reach out immediately to C19HealthReport@uchicago.edu.
Recording and Deletion Policies for Academic Year 2020-1¶
The Recording and Deletion Policies for the current academic year can be found in the Student Manual under Petitions, Audio & Video Recording on Campus.
Do not record, share, or disseminate any course sessions, videos, transcripts, audio, or chats.
Do not share links for the course to those not currently enrolled.
Any Zoom cloud recordings will be automatically deleted 90 days after the completion of the recording.
Attendance¶
Absent any extraordinary circumstances, we expect students to attend all lectures and discussions. That said, we do not keep track of attendance in this class and no part of your final grade is computed based on your attendance to lectures or discussions.
Students who have been exposed to or who are experiencing symptoms of COVID-19 should contact UChicago Student Wellness immediately to be tested, and reach out to their area Dean of Students to request accommodations for classes until:
At least 10 days have passed since symptoms first appeared and;
At least 3 days (72 hours) have passed since recovery- defined as resolution of fever without the use of fever-reducing medications and improvement in respiratory symptoms (e.g., cough, shortness of breath).