Basic Info
Instructor: Stephen Freund
Office: TPL 302
Office Hours: TBD
Email: freund@cs.williams.edu
Phone: 413-597-4260
Texts
The primary text book for this course is Compilers: Principles, Techniques, and Tools by Aho, Lam, Sethi, and Ullman. Additional reading material and resources will be made available to you.
Course Objectives
This tutorial covers the principles and practices for the design and implementation of compilers and interpreters. Topics include all stages of the compilation and execution process: lexical analysis; parsing; symbol tables; type systems; scope; semantic analysis; intermediate representations; run-time environments and interpreters; code generation; program analysis and optimization; and garbage collection. The course covers both the theoretical and practical implications of these topics. As a project course, students will construct a full compiler for a simple object-oriented language.
Tutorial Meetings
This course will be taught as a tutorial. Each of you will be assigned to a group of two students. Your group will normally meet with me each week to discuss the readings and exercises I assigned for the week. These exercises will focus on “problem set” questions, small programming exercises, primary literature, design of your projects, and possibly even code reviews.
In the “canonical” tutorial format, one student in each group is primarily responsible for the presentation each week. Because of the cumulative nature of the material we will be considering, I will expect each of you to come to each meeting fully prepared to present summaries of the readings and solutions to the exercises. To compensate for the higher workload such an approach entails compared to the “canonical” tutorial, you are encouraged to work on the assignments with others taking the course. To make our meetings more interesting, however, I ask that you not work as one large class group. (And I may also ask you not to work with your tutorial partner on some weeks.)
The tutorial format naturally emphasizes learning more than the specific material covered by the course. In particular, this format can have the very positive effect of encouraging you to develop your ability to learn new material independently and to improve your ability to present your thoughts orally. Therefore, in completing the assignments, you should do more than prepare written solutions. You should take some time to think about how you will present your solutions. I do not mean that you should prepare a lecture. Rather, take the time to look over each reading and decide what the major points are. Do the same with the exercises. I will ask you to submit polished, written solutions to some of the problems the day after your meeting.
Lab Meetings
Lab meetings on Friday are a required part of this class. Not attending lab is grounds for failure in the class.
Programming Project
As a project course, there will also be a substantial semester-long programming project. The overall goal of the project is to build a fully functional compiler for a small but fairly complete subset of Java. The project will be done in groups of three. You may choose your own project groups, although I may choose to reorganize them as the semester progresses.
Programs should be turned in electronically by the due date, as described under “How Work Is Submitted” below. Each group may use a maximum of three free late days during the course of the semester. A late day permits you to hand in an assignment up to 24 hours late, without penalty. In order to use a late day, you must send to me before the deadline a status update that includes a description of what has been completed, what functionality still needs to be implemented, and an outline of what steps remain.
Late days are designed to give you some flexibility, but be warned that the programming projects are substantial and cumulative — falling behind or failing to complete one project will substantially impact the follow-on assignments. Use late days if you need to, but plan ahead and start early. You will not finish these assignments if you wait until the last minute.
Once those late days are exhausted, late assignments will be penalized severely.
All programs will be graded on design, documentation, style, correctness, and efficiency. We will use the Unix lab computers for the programming assignments.
How Work Is Submitted
Written homework: submit a PDF via Gradescope by the day after your tutorial meeting.
Labs and warm-up coding exercises (Lab 1’s NFA simulator, Lab 2’s calculator, and the RECompiler): submit a zip of the sbt project via Gradescope.
Programming assignments: develop in your GitHub repository — commit early and often — and submit a zip of the sbt project via Gradescope for each checkpoint and each final deadline.
Grading
Grades will be determined roughly as follows: Homework/Meetings: 50%, Projects: 50%.
Honor Code
Discussing written problems with other students in the class is permitted. However, copying of solutions is not. The work you hand in should be your own. A good rule to follow is to work through the problems with others, taking only rough notes. You should then write your solutions independently, referring to your notes as little as possible. The idea is to understand each solution well enough that you can reconstruct it by yourself. In addition, you should write on each assignment the list of people with whom you collaborated.
The same applies to programming — feel free to discuss general ideas with others, but the design and code you submit should have been written entirely by you (or your group if it is a group assignment).
I will occasionally give more detailed collaboration guidelines on some assignments. Uncredited collaborations will be considered a violation of the honor code and will be handled appropriately.
Outside references
You may refer to any course materials and the web sites listed under the Resources heading. You may use other sources as references to look for specific information — API usage, git or scala commands, etc. You may not use other sources to look for solutions to your homework or lab questions, and you may never copy prose or code directly from another source.
Examples of information you may look for in outside sources:
“What are the parameters for List.append?”
“What does the scala compiler error ‘…’ mean?”
“How do I use case classes in Scala?”
“How do I use sbt to run a single test suite?”
Examples of information you may not look for:
“How do I solve problem 4.3 from the book?”
“How do I write a regular expression for floating point numbers?”
“Why is the following code not working?”
“How do I prove theorem ...?”
Any sources of information used to complete your assignments should be cited.
Generative AI
Using ChatGPT, code auto-completion, programming agents, and the likes to do your work within this class setting weakens your ability to learn, retain, and apply the material. We will discuss effective and appropriate use of AI tools later in the semester, but when learning new material and skills it is vitally important to practice and gain comfort with them on your own. Do not short-circuit your learning and refrain from using generative AI to produce, refine, or check answers for the assigned coursework for this class.
We also recognize that there are effective ways to use AI to enhance you learning and understanding. You may use AI assistants to gain a better understanding of the course material and related topics as long as you do not compromise the process of producing academic work on your own. Follow the rules above for outside references: seek out specific information but do not replace the work, design, and thinking you must do individually or as a group. A couple guiding principles:
- Never write prompts including specifics of the problem you are
solving or the code you’re writing.
- Turn off all AI assistants and extensions in your programming environment when working on the labs.
- Ask if in doubt.
The boundary between appropriate and inappropriate use may seem fuzzy. I’m happy to help you find effective ways to use AI in the context of our requirements and pedagogic objectives.
After the semester
Please do not post your solutions to the CS 434 problem sets or labs in any public forum, including public GitHub repositories.
The bottom line
If in doubt as to what is appropriate, do not hesitate to ask me.
Tentative Schedule
The course is structured roughly as follows. This will undoubtedly change.
| Lexical and Syntax Analysis | 3 weeks |
| Abstract Syntax Trees and Semantic Analysis | 2 weeks |
| Intermediate Representations and Code Generation | 3 weeks |
| Optimization | 3 weeks |
| Advanced Topics | 1 week |
Be sure to check the web site for an up-to-date schedule.
Intellectual Property
As per College policy, no part of this course may be reproduced and/or distributed. In particular, no videos recorded as part of this class may be shared with anyone external to the CS104 course.
Academic Resources on Campus
There are many academic resources available to you on campus. Here are a few that may be useful throughout the semester.
- Peer Academic Support Network: Individual peer tutoring. See here. Contact: Nick Hanford.
- Qauntative Skills Programs: Drop in tutoring through the Math and Science Resource Center (MRSC), as well as individualized academic coaching. Contact: Nick Hanford.
- Schow Library: Assistance on data-related research or class projects. Contact: Regan Schwartz.
Accommodations
If formal accommodations need to be made to meet your specific learning or physical abilities, you should contact your instructors as possible to discuss appropriate accommodations. You should also contact the Director of Accessible Education (x4672) or the Dean’s office (x4171). We will work together to ensure this class is accessible and inclusive.
Mental Health
If you are experiencing mental or physical health challenges that are significantly affecting your academic work, you are encouraged to contact your instructor and/or speak with Dean’s Office staff (x4171).