About Comp105

Comp105 is a course about the principles of programming languages and their application. The emphasis is on ideas and techniques relevant to practitioners, but includes theoretical foundations crucial for deeper understanding: abstract syntax, formal semantics, type systems, and lambda calculus. Work in the course involves exploring programming languages and features both as a user (by writing programs in those languages), as a language designer (by implementing interpreters for those languages), and as a scholar (by proving mathematical properties of them).

Course information:



Date Topics Reading SOH Homework due
Jan 16 Introduction, course logistics
Jan 21 Concrete and abstract syntax Ch. 2 -- 2.2
Jan 23 Abstract syntax trees, semantics Ch. 2.3
Jan 28 Operational semantics: environments and inference rules Ch. 2.4 (a1) ImpCore programming
Jan 30 Operational semantics for ImpCore Ch. 2.4
Feb 4 Semantics of loops Ch. 3 -- 3.3 (a2) Operational semantics
Feb 6 Introduction to Scheme Ch. 3 -- 3.3
Feb 11 Recursion on lists Ch. 3.7
Feb 13 First-class functions Ch. 3.8 -- 3.10 (a3) ImpCore interpreter
Feb 18 Working with higher-order functions Ch. 3.12
Feb 20 No class
Feb 25 Scheme semantics Ch. 3.11 (a4) Scheme programming
Feb 27 More Scheme semantics Ch. 3.12
Mar 4 Midterm exam
Mar 6 No class
Mar 11 ML and type-directed programming Outside reading
Mar 13 More ML programming Outside reading (a5) ML programming
Mar 15-23 Spring Break
Mar 25 Types and type systems Ch. 6 (intro)
Mar 27 Type rules for Typed ImpCore; monomorphism Ch. 6.1 -- 6.4
Apr 1 Type rules for Typed uScheme; polymorphism Ch. 6.6
Apr 3 More polymorphism; kinds Ch. 6.6
Apr 8 Type inference and uML Ch. 7 (just overview, 7.1 -- 7.3)
Apr 10 Object-oriented programming; Smalltalk Ch. 10 -- 10.1
Apr 15 Memory management and garbage collection Ch. 4 (a6) Type checkers
Apr 17 More object-oriented programming Ch. 10.2
Apr 22 Logic programming with Prolog Ch. 11 -- 11.1
Apr 24 Lambda calculus Outside reading
May 5 Final exam -- 7pm-9pm in Nelson (a7) GC or Prolog



Your grade in this course will be based on the programming assignments, midterm and final exams, and class participation, which is a crucial part of the course. Grades will be computed as follows:

60% Assignments
10% Midterm
20% Final
10% Class participation


You may discuss any of the homework problems with fellow students (in fact, I encourage you to discuss the homework!), but you must acknowledge those discussions in your submission (e.g., "I discussed the design with ... "). All written material (including code), however, must be your own work -- do not share your code with anyone else.

For the larger programs you will work in pairs (many of you are already familiar with pair programming from Comp40). Be very careful to separate your pair work from your individual work (a mistake could a violation of the academic integrity policies, with unpleasant consequences).

Late policy

Late homework creates a significant problem for the flow of the class because it delays when we can start grading assignments, and therefore delays when you get the feedback, limiting its usefulness. Therefore, the late policy for the class will be very simple and based on automatic deductions for lateness:

  • 1 day late: automatic deduction of 10%
  • 2 days late: automatic deduction of 50%
  • 3 or more days late: no credit, and we will only assess work if we have time.

Exceptions: there are, of course, exceptional circumstances that do not fall under the lateness policy. These include family emergencies and medical conditions that require hospitalization or other serious treatment.

Non-exceptions include mild, short-run illnesses like colds, voluntary travel (including vacations, meetings, or outside work), competing work in other classes, job interviews, sports events, relationship problems, hangovers, etc. Yes, I've heard it all!

My advice is start early and get help early. We have a boatload of TAs who can help you with any topic or assignment. If you start early you'll be able to enlist their help before you get into trouble and lose credit.

Academic (mis)conduct

Students in this class are encouraged to discuss the programming assignments, but each student must produce his or her solutions completely independently. Specifically, you may verbally discuss problems, issues, and ideas, but you may not write anything down together. In addition, I ask that you document, in your code, anyone with whom you discussed the assignments.

Academic misconduct (also known as "cheating") is a very serious issue at Tufts. As a member of the University community, I am obligated to report any incidents. The consequences are painful for everyone involved. For more details, see the Tufts brochure on academic conduct: http://uss.tufts.edu/dosa/publications/documents/integrity.pdf

The most common reason for cheating is becoming overwhelmed by the work. Every one of us has been in this situation, and we're more than willing to help you if you feel like you're in trouble. Please, please come to us before you get into a situation where you're tempted to take someone elses solution.

Last updated January, 2014