Instructor: Cormac Flanagan
Office Hours: Thursday 1-2pm or by appointment, Engineering 2, room 367
Teaching Assistant:Jordan Johnson
TA Office Hours: Wednesday 3-4pm, Engineering 2, room 392
Lectures: Tu/Th, 10:00-11:45am, Engineering 2, room 194
Lab Sessions: Mondays 1:00-3:00pm and Thursdays 5:00-6:00pm, both in Baskin 105
FINAL: Thursday March 15th, in class.
This course provides a broad background in the different styles of programming languages, and the principles behind these languages. We will study programming language concepts by using them in programs, and will develop a deep understanding of these approaches by writing interpreters for various language constructs and styles.
In contrast to the more mainstream approach of statically-typed, imperative, object-oriented programming languages (such as C#, Java, etc), this course will focus more on dynamically-typed and declarative programming, both functional and logical. We will also cover various more advanced topics, time permitting, including: type systems, program analysis and verification, and peraps garbage collection.
This course requires a substantial amount of programming, and will assume that you have a solid programming background. Much of the programming in this course will be in the Scheme programming language, for two reasons. First, Scheme can express the language concepts that we will study in an especially succinct manner. Second, Scheme is simple enough that you can learn it in a relatively short time. This course will not expect you to know Scheme beforehand, though you will be expected to learn it fairly quickly.
The prerequisites for this course are:
The required text for this course is:
For learning Scheme, I recommend you read (some of):
More information on these books is available here, and they are also on reserve at the Science library.
The following exercises -- copied from the Brown CS173 course -- should also be helpful to you in learning Scheme.
The Revised Report on Scheme may also be helpful (although its a different dialect that we're using in DrScheme).
On the machines in Baskin 105, select "Actions" then "Run Program ..." then type "drscheme" and press return. After starting DrScheme, select "Language" then "Choose Language ..." then "PLAI - Pretty Big" (which may be hidden under "Programming Languages: Application and interpretation"). The bottom window should then say:
Welcome to DrScheme, version 360.
Language: PLAI - Pretty Big.
If you see this, you're good to go.
If the language level "PLAI - Pretty Big" is not available, you'll need to install it. In DrScheme, select "File" then "Install .plt File ...", then enter the URL:
http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/plai-350.plt
Restart DrScheme, then select "PLAI - Pretty Big", as described above.
There will be homework assignments, at least one each week. Homework will always be due at 11:59pm Pacific Time. That way you can get a good night's sleep before class. We will not accept late assignments, so plan accordingly. These assignments should be submitted via email to "cormac at cs.ucsc.edu" and "jmj at cs.ucsc.edu", with the subject "CMPS112 Assignment".
We will use codewalks to inspect some submitted assignments in detail. Also, see below on pair programming.
Here is some code for chapter 3 that shows how to hack up tracing in DrScheme. It defines a second function "calc" that wraps some tracing functionality around the original function, also called "calc".
The homework assignments should be done in two person teams. You are free to choose your own partner. To learn a about pair programming, please read All I Really Need to Know about Pair Programming I Learned In Kindergarten. You should also read the pair progamming guidelines and policy for the class. This explains what is considered to be acceptable pair programming and what to do if you have problems with your partner. (Exceptions to the pair programming requirement may be granted in some limited situations.)
We are very serious about requiring you to write clean, well-documented code. 20% of your grade for programming assignments will depend on your design, style, and comments. Since we expect that you document and test your code anyway, we think of this as giving you a free 20% for each assignment.
Not already knowing Scheme or having learned Scheme with a different style are not excuses for not following these requirements. We are using the coding style from How To Design Programs for this course.
All functions must have tests that exercise non-trivial cases. We require this to encourage good software development skills, but, more importantly, to force you to show us that you know what your code is supposed to do and that you're not getting a correct answer by guessing. We will not give full credit to untested functionality, even if it is correct!
Good test cases:
When writing test cases, resist the temptation to make them massive and complicated. Instead, write small, clean tests with clear purposes. While a mega-test can be good for exposing errors you did not think to write focused tests for, make sure that, should your mega-test fail, you figure out what aspect of it triggered an error and write a smaller test for that.
Any confirmed academic dishonesty including but not limited to copying programs or cheating on exams, will constitute a failure of the computer ethics portion of this class and result in a no-pass or failing grade. You are encouraged to read the campus policies regarding academic integrity.
Working with others in addition to your partner is a good way to learn the material and we encourage it. However, working together to find a good approach for solving a programming problem is cooperation; but listening while someone dictates a solution is cheating. You must limit collaboration to a high-level discussion of solution strategies, and stop short of actually writing down a group answer. Anything that you hand in, whether it is a written problem or a computer program, must be written in your own words. If you base your solution on any other written solution, you are cheating. A program will be in use to detect copying.
When taking a quiz or exam, you must work completely independently of everyone else. Any collaboration here is cheating. We do not distinguish between cheaters who copy other's work and cheaters who allow their work to be copied.
If you have any questions on these important points, please see your instructor.
This year, for the first time, CMPS112 is using Programming Languages: Application and Interpretation by Shriram Krishnamurthi as the course text. With Shriram's kind permission, we are also borrowing heavily from other parts of his CS173 course at Brown.