Programming Languages: Theory and Practice

(CIS 352 at Syracuse U)

Note: parts of this syllabus are subject to change with adequate notice to students.

An introduction to the design and implementation of programming languages, including lab experience using different kinds of languages and experience implementing programming language features.


  • 3 lecture hours per week
  • 8 projects (each worth 7%)
  • 2 in-class coding exams (each worth 5%)
  • 1 midterm exam (worth 12%)
  • 1 final exam (worth 20%)
  • This will be a project intensive class. Approximately 6-10 hours per week outside of class will be expected from students. I recommend against taking this course concurrent with other project-heavy courses.

Course Overview

This course will introduce many of the principles of programming language design and implementation. We will discuss numerous features of several programming languages and the algorithms and data structures that are needed to provide these features. Projects will cover both the use of various features and high-level understanding the algorithms and data structures involved in their implementation.

Lectures and labs will include examples (and exercises) in Racket. No prior knowledge of Racket is needed for this course, but students should be familiar with the programming techniques from their lower-level courses and possess fluency in basic functional programming.


  • Projects: 56%
  • Exams: 44%
    • Midterm: 14%
    • Final: 20%
    • Coding Exam 0: 5%
    • Coding Exam 1: 5%

Grade cutoffs

These are rough grade cutoffs. I never fit grade distributions to a normal curve (e.g., specifying that only 10% of students may earn an A), however I may choose to lower the bar for some letter grades. I will not curve assignments or projects.

  • 93% – A
  • 89% – A-
  • 84% – B+
  • 80% – B
  • 77% – B-
  • 74% – C+
  • 70% – C
  • 65% – C-
  • 55% – D
  • 0% – F


Projects in this course will be graded by an automatic grader. We may adjust projects so that portions of the projects include style-based grading, though we will not employ subjective grading. More pointedly: we will not award partial credit for solutions that have the right ideas but do not pass our tests.

Late Projects and Extensions

I used to extend project deadlines, but I have found that this is often unfair to the students who start on time (and more students than I would have thought have raised this point to me privately). Therefore, project extensions will be rare–and only in the event of things such as university closures. Project extensions for students will not be granted except for religious observances and extenuating circumstances (family illness, etc..). The late policy is as follows:

  • Projects turned in on time will earn a maximum of 100%

  • Projects turned in up to 72 hours late will have a 15% penalty applied.

  • Projects turned in after 72 hours late (until the end of the term) will have a 30% penalty applied.

  • Your project grade always be the maximum possible. For example, let’s say you make an on-time project submission for 60%, but the next day you turn in a project which earns an 75%. This submission would earn a 63.75%. Five days after the deadline you turn in a project earning 100%. Your final score is 70%, as the 70% (100% with a 30% penalty) still got the maximum grade of any submission.

You should be able to earn at least a 70% on all of the projects with enough work.


We will plan to cover all of the following, though some may be dropped for time:

  • Programming in Racket
  • Higher-order functions
  • Execution models and their impact on the stack
  • Pattern matching
  • Immutable data structures
  • Okasaki-style immutable queues
  • Immutable binary trees
  • Quad-trees
  • Static scope
  • Dynamic scope
  • Lambda calculus
  • Textual-reduction semantics
  • Big-step semantics (CE-style evaluators)
  • Metacircular interpreters
  • Church encoding
  • Control and continuations
  • Abstract machines
  • The CEK machine
  • A-Normal Form
  • Continuation-passing style
  • Top-down parsing
  • State-passing style
  • Simply-typed lambda calculus
  • Type inference
  • Hygienic macros
  • Logic programming
  • MiniKanren

Projects and Labs

This course will have eight individual projects. Each of these will be completed using the course’s autograder. Lab attendance is encouraged, but not required. Labs will introduce projects, provide extra help, give exercises, etc…

Collaboration and the Honor Code

  • Assignments and exams must be done alone

  • Specifically, you must never send your code to anyone or allow anyone to watch you code.

  • The autograder employs elaborate cheat-detection techniques. These techniques will compare your code to other students’ submissions. The TAs will be using these features to periodically scan for students who are cheating.

  • All apparent cases of academic dishonesty will be reported, even if the student believes they made an honest mistake.

  • You should feel free to discuss “ideas” about the solution with peers, but you should basically never be getting help from peers about your code. If you do, it should only be in the abstract (e.g., “can you use operator overloading to implement that?” or “do you think it would be sensible to implement this with map?”) and not particularized to your codebase.

  • Cite all help other than the professor, T.A., and required/recommended text (you are allowed to cite those if you wish, but it is not required unless you are specifically told otherwise); note that proper citation is sufficient to avoid any charge of academic dishonesty, and we will not be particularly focused on copyright law during lab work.

  • It is fine to get help away from the computer, as long as you erase all notes and return to your computer with only the new understanding in your head.

Again: You should never share code with another student. This includes both sending a file to another student and “over the shoulder” copying (even when, e.g., variable names are changed, etc..). In the eyes of the instructor, these are both equally bad. You should never be sitting and helping another along by writing their code. By doing so you are both violating the honor policy and disadvanting the student you are helping (as they may not then properly learn the material).

Student Support

Syracuse University values diversity and inclusion; we are committed to a climate of mutual respect and full participation. There may be aspects of the instruction or design of this course that result in barriers to your inclusion and full participation in this course. I invite any student to meet with me to discuss strategies and/or accommodations (academic adjustments) that may be essential to your success and to collaborate with the Office of Disability Services (ODS) in this process.

If you would like to discuss disability-accommodations or register with ODS, please visit their website at Please call (315) 443-4498 or email for more detailed information.

ODS is responsible for coordinating disability-related academic accommodations and will work with the student to develop an access plan. Since academic accommodations may require early planning and generally are not provided retroactively, please contact ODS as soon as possible to begin this process.


As part of the regular ABET accreditation process for the undergraduate program in computer science, we may be collecting samples of students’ work in each of our undergraduate classes. As a result, some of your labs/homeworks/exams may be photocopied/scanned to be presented for accreditation at some later point.

Discrimination and Harassment

The University does not discriminate and prohibits harassment or discrimination related to any protected category including creed, ethnicity, citizenship, sexual orientation, national origin, sex, gender, pregnancy, disability, marital status, age, race, color, veteran status, military status, religion, sexual orientation, domestic violence status, genetic information, gender identity, gender expression or perceived gender.

Any complaint of discrimination or harassment related to any of these protected bases should be reported to Sheila Johnson-Willis, the Universitys Chief Equal Opportunity & Title IX Officer. She is responsible for coordinating compliance efforts under various laws including Titles VI, VII, IX and Section 504 of the Rehabilitation Act. She can be contacted at Equal Opportunity, Inclusion, and Resolution Services, 005 Steele Hall, Syracuse University, Syracuse, NY 13244-1120; by email:; or by telephone: 315-443-0211.

If you notice any incidents of harassment or discrimination, however minor, please email me. You may wish to use an anonymous email service such as Please feel free to tell me as much as you feel comfortable. I am a mandatory Title IX reporter and must report incidents such as sexual harassment, relationship violence, stalking, etc…


Slack is an instant messaging app for teams. We’ll be using it, hopefully a lot. This is the best place to get in touch with me for one-off questions, ask for an appointment for office hours, etc..

Email me if you have not been invited to the course Slack.