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).
- Book (required): Programming Languages: Build, Prove, and Compare by Norman Ramsey (with Samuel L. Kamin). Available at the Computer Science Front office.
- Piazza: We will use Piazza for questions and discussions. The course page is here.
- Structured Office Hours (SOH): an extra hour each week in which the grad TA will lead an interactive discussion of a recent topic or homework problem. Details coming soon.
|Sep 3||Introduction, course logistics|
|Sep 8||Concrete and abstract syntax||Ch. 2 -- 2.2|
|Sep 10||Abstract syntax trees, semantics||Ch. 2.3|
|Sep 15||Operational semantics: evaluation and inference rules||Ch. 2.4||(a1) ImpCore programming|
|Sep 17||Operational semantics: variables, names, and environments||Ch. 2.4|
|Sep 22||TBA||Ch. 3 -- 3.3||(a2) ImpCore interpreter (due 9/23)|
|Sep 24||Introduction to Scheme||Ch. 3 -- 3.3|
|Sep 29||Recursion on lists||Ch. 3.7|
|Oct 1||First-class functions||Ch. 3.8 -- 3.10|
|Oct 6||Working with higher-order functions||Ch. 3.12|
|Oct 8||Scheme semantics||Ch. 3.11|
|Oct 13||Columbus Day|
|Oct 15||More Scheme semantics||Ch. 3.12|
|Oct 20||Midterm exam|
|Oct 22||Memory management and garbage collection||Ch. 4|
|Oct 27||ML and type-directed programming||Outside reading|
|Oct 29||More ML programming||Outside reading|
|Nov 3||Types and type systems||Ch. 6 (intro)|
|Nov 5||Type rules for Typed ImpCore; monomorphism||Ch. 6.1 -- 6.4|
|Nov 10||Type rules for Typed uScheme; polymorphism||Ch. 6.6|
|Nov 12||More polymorphism; kinds||Ch. 6.6|
|Nov 17||Type inference and uML||Ch. 7 (just overview, 7.1 -- 7.3)|
|Nov 19||Object-oriented programming; Smalltalk||Ch. 10 -- 10.1|
|Nov 24||More object-oriented programming||Ch. 10.2|
|Dec 1||Logic programming with Prolog||Ch. 11 -- 11.1|
|Dec 3||Lambda calculus||Outside reading|
|Dec 12||Final exam -- 3:30pm-5:30pm in Nelson|
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:
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 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 an army 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.
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.