CS 131 Syllabus: Spring 2003

• Course Staff:
  • Professor Chris Stone
    • Office: 1253 Olin,
    • Office phone: x78975
    • E-mail: stone@cs.hmc.edu
  • Grutors
    • Elmer Kim, ekim@cs.hmc.edu
    • Gabriel Neer, gneer@cs.hmc.edu
  
  
• Lectures: (Attendance is expected)
  • Monday and Wednesday, 11:00-12:15, TG 103.

• Web Page: http://www.cs.hmc.edu/courses/2003/spring/cs131/
  
  
• Office Hours/Tutoring: The purpose of office hours is to provide you with a chance to discuss class-related topics, to ask questions about material you find interesting or confusing, and to provide comments about the class. Official office hours when it's guaranteed someone will be around and available are as follows: (Office hours for the grutors will be added soon.)
  • Tuesdays
    • 2:30-4pm, Chris Stone, Olin 1253
    • 7-9pm, Elmer Kim, Terminal Room
  • Thursdays
    • 2:30-4pm, Chris Stone, Olin 1253
  • Fridays
    • 2:30-4pm, Chris Stone, Olin 1253
  • Sundays
    • 2-4pm, Gabriel Neer, Terminal Room

  But, you're also free to drop by the professor's office outside office hours, or to make appointments for other times including lunch or dinner.

Some students prefer e-mail. If this includes you, please send questions to cs131help@cs.hmc.edu because such messages will be sent both to the professor and to the grutors and hence will be answered most quickly. If your question is about code, please submit it and/or attach the entire file to your mail.

 

• Goals for the course: Students completing this course should be able to think about programming languages analytically. This includes the abilities to:
  
  
  • Treat programs and languages as things-in-themselves to be analyzed and produced
  • Decompose languages into atomic features
  • Distinguish paradigms and languages
  • Separate syntax from semantics
  • Critique and compare programming language designs (at a deeper level than just syntax)
  • Suit the choice of language to the task to be performed
  • Learn new languages more quickly by relating them to those previously learned
  • Use standard PL vocabulary when discussing languages
  • Understand basic implementation techniques
  • Appreciate the importance of PL theory in language design and implementation (including the connection between lambda calculus and functional languages)
    
    
• Catalog Description: A thorough examination of issues and features in language design and implementation including language-provided data structuring and data-typing, modularity, scoping, inheritance, and concurrency. Compilation and run-time issues. Introduction to formal semantics. Prerequisites: Computer Science 70 and 80. 3 credits.
  
  
• Clearer Description: The goal of this course is to provide you with a framework for thinking about programming languages. The course is not primarily about programming (although there is a lot of this, and the course may well affect the way you program); instead, we go "up a level" and view not just particular programs but the languages themselves topics of study, with parts one can tease apart and study in isolation.
  
  You already had an introduction to this topic in CS 60, where you used four languages representing at least four different approaches: Java for object-oriented programming, rex for functional programming, Prolog for logic programming, and ISCAL for low-level (assembly) programming. This course, however, has a slightly different emphasis and uses what is sometimes referred to as the language principles approach. By organizing lectures around key ideas that recur in many different languages (and putting less emphasis on particular choices of syntax), you should be better able to understand many more than four languages, including ones that haven't even been invented yet. (Obviously, if you actually want to write programs in, for example, the language Haskell, details of syntax are absolutely critical! However if after this course you're told that Haskell is a statically scoped, polymorphically-typed, higher-order, lazy, purely-functional language, you immediately have a huge head-start in understanding the language.)
  
  The reason why this course should matter (besides being intrinsically fascinating, of course!) is that programming languages are ubiquitous in computer science. There are always new languages being devised, of which a very few actually become widely used; typically, these are specialized languages for particular applications (e.g., Java, VRML, or XSLT). As a computer scientist, you must be able to learn new languages as necessary, and the background you get from this course should make this easier. Some students will eventually want to design their own programming language — not necessarily a full-scale general-purpose language, but perhaps a language for describing input to or configuration of another program; this course should give you a better chance of avoiding common pitfalls when doing so. We will also talk a little bit about implementation of languages and how language design affects the implementation; if you are interested in this aspect you should definitely take the Compiler Design course this Spring which concentrates almost exclusively on implementation issues. Finally, you will almost certainly have to choose which programming language to use for a particular project. A final goal of this course is to give you enough background in the study of programming languages that you can argue persuasively why a particular language is appropriate (or inappropriate) for a particular problem.
  
  
• Course mailing list: The course mailing list cs-131-l will be used for announcements relevant to the entire class, some of which may be important. It is your responsibility to regularly read these messages and to contact the instructor if you are not on the list.
  
  
• Course materials: One source of information for the course will be the lecture slides and periodic handouts. The other, complementary, source will be the course text, available at Huntley Bookstore.
  
  

  Programming Language Pragmatics
  Michael L. Scott
  Morgan Kaufmann Publishers, 2000.
  ISBN 1-55860-442-1

  One copy of this text is on reserve at the Sprague Circulation Desk.
  
  
• Assignments and Grading: There will be nine weekly homework assignments over the course of the semester. Each of these assignments will be distributed on Wednesday and due before class the following Wednesday. Assignments will be accepted up to 25 hours late without penalty (i.e., until noon Thursday) but beyond this late assignments will not be accepted except in very rare special cases where prior arrangements have been made with the instructor, or in case of unforeseeable crises such major illness. In particular, do not expect to turn them in at the end of the semester; they will not be accepted. The homeworks count towards 50% of the final course grade. Because the grad e is so highly homework-weighted, it's easy to fail just by skipping homeworks.
  
  There will be numerous supplementary reading assignments, given on a weekly basis (see the course schedule). Most will be from the course text. I will assume that you have done the readings. Each reading assignment also includes a very short written response to be turned in at the beginning of class; these count towards 10% of the final course grade. There are no extensions for the readings.
  
  There will be a final project worth 25% of the final grade. Details will be distributed in the second half of the course.
  
  Finally, there will be a take-home midterm worth 15%.
  
  Final class scores of 90/80/70/60% guarantee letter grades of A/B/C/D respectively (modulo pluses and minuses). There is a small possibility these cutoffs may be moved downward, but don't count on it.
  
  The standard CS Academic Honesty Policy applies to this course, relaxed only as follows: unless explicitly stated you are free to discuss a problem with other students, and even discuss the merits of alternative solutions as long as you explicitly cite this (limited) collaboration. However, the actual work handed in must be entirely your own; as the honesty policy states, you may not share code or other specific answers in any form. For group assignments, this policy applies only to interactions between members of different groups.