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.
|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:
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 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.
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.