| Objectives |
Students taking this course can expect to acquire the following:
- an understanding of the major classes of high-level programming
languages, language features, and programming styles, with an emphasis
on applying concepts from programming language theory;
- formal methods of specifying the syntax and semantics of
programming languages;
- and the knowledge needed to write parsers, interpreters, and
simple compilers for the major classes of programming languages.
|
| Contacting the Course Staff |
- For email and the newsgroup: please allow about 24 or so hours
for a response, except on weekends (see below).
- The staff do not work on the weekends. If you send something late
Friday or over the weekend then you should not expect a reply before
Monday. The exception to this is weekends where an MP is due on the
following Monday. We will make our best effort to answer questions
promptly.
- Never ever EVER call any staff at
home.
|
| Extensions |
- Each MP will normally have an automatic 48-hour extension with
a point penalty of 20% on that MP. If we cannot give such an extension
for a particular MP, for example due to scheduling constraints,
we will announce that before the MP is handed out.
During the automatic extension, staff will not answer questions
for that MP. You are on your own.
Extensions without a point penalty for the first 48 hours and any
extension beyond the 48 hours will only be granted under very
unusual circumstances such as a medical or family emergency.
A signed note from a responsible party will be required.
If you do need such an extension for some legitimate reason,
do your best to let us know as soon as possible, preferably before
the normal MP deadline.
|
| Regrade Policy |
|
Our goal as the course staff is to grade your work carefully and
accurately. Unfortunately, occaisonally staff may overlook something,
misunderstand an otherwise correct answer, or record a score incorrectly.
This is where the regrade procedure steps in.
In order to have your regrade considered you must provide the following:
- your netid;
- what assignment or exam question was graded incorrectly; and
- why you think your answer deserves more points than what the
grader gave.
You must also submit your regrade request for a particular assignment
within one week of receiving grades for that assignment. Late regrade
requests will not be accepted or read.
Good reasons to ask for a regrade:
- You used a notation that was unfamiliar to the grader but is
standard (e.g., in a textbook for one of your other courses).
- The grader recorded a score incorrectly.
- The problem was ambiguous (or just plain wrong), causing you to
interpret it differently than the grader.
- The grader marked the problem wrong incorrectly.
Bad reasons to ask for a regrade:
- Part of your answer "matched" the answer given in the solution.
A partially correct answer is still wrong.
"The difference between an
almost right word and a right word is the difference between a
lightning bug and lightning." -- Mark Twain
- You wrote down two or more answers, only one of which was correct.
Never put more than one answer for a question unless we tell you that
such a thing is legitimate.
- You expended a lot of effort answering the problem. We are
measuring mastery, not effort.
- You wrote something down.
|
| Collaboration |
You are allowed to collaborate on the machine problems (MPs) of this
course, in order to figure out how to solve the problem, resolve things
you don't understand, and help each other track down errors or bugs.
Nevertheless, you must each write and test your code separately and
handin your own MP.
You don't have to tell us who you collaborated with. Whether you pass
this course or not will depend on whether you pass the exams -- and
those are non-collaborative.
We allow you to collaborate for several reasons:
- all research done indicates that students learn more when they are
allowed to work together;
- our own ability to respond to student questions is increased
because your peers are able to give help.
However, you have to collaborate intelligently in order to get the most
out of it. If you ask a friend to describe the solution completely to
you and then write it down (in substantially different form), you will
get the credit but you'll fail the exam because you never learned the
methods/techniques/concepts. Note that, according to class policy,
you should NOT leave discussions with written answers (see Lecture 1).
Realistically, there is no good way for us to prevent it, so you're
on the honor system.
If you copy a friend's solution directly or substantially, that
will be considered cheating. You should always write your own
solution, without reference to another solution to the same problem.
You can reference any code discussed in class.
The penalties for being discovered
cheating are described in the next section, below.
Think of MPs as being part of the practice for the exam. Many of the
problems will be used as a basis for the exam problems themselves. In
fact, when it comes time to study, we will likely advise you to redo
your MPs.
If you get really stuck, and do end up needing someone else to write
some small function on an MP for you, or use some code from any other
source, *acknowledge* it up front in your MP. Doing so may cost you
some credit, but you will be considered to not have cheated
|
| Policy on Cheating |
|
The penalty if you are caught cheating -- either sharing your solution or copying someone else's solution-- is an F grade for the class. Moreover, the cheating episode will be reported to the department. You should take all reasonable precautions to prevent others from cheating and report any suspected cheating.
|
| Grading |
|
Our goal is to have grades back to you as soon as possible. In practice,
this will probably take about a week for each assignment or exam.
Whenever your grades are changed, you will receive an email with
information about your grades. Do not ask when grades are available.
They will be in your inbox when they are available.
| Grading Breakdown |
|---|
| Work |
Weight |
Notes |
| Machine Problems (combined) | 35% |
| Midterm | 25% |
| Final Exam | 40% |
| Project | NA |
Only for 4-hour graduate students |
|
| Textbooks |
There is no required textbook for this course. However, the following textbooks are recommended reading: (see also the resources page)
-
The Objective Caml system, release 3.09
Documentation and user's manual by Xavier Leroy
(with Damien Doligez, Jacques Garrigue, Didier R?my and J?r?me
Vouillon), from the official INRIA website for OCAML.
- an
online book
about OCaml from CalTech.
- Compilers: Principles, Techniques, and Tools,
also known as "The Dragon Book"; by Aho, Sethi, and Ullman.
Published by Addison-Wesley. ISBN: 0-201-10088-6.
- Advanced Programming Language Design, by Raphael A.
Finkel. Addison Wesley Publishing Company, 1996.
- Programming Language Pragmatics, by Michael L. Scott.
Morgan Kaufman Publishers, 2000.
- Concepts, Techniques, and Models of Computer Programming
Peter Van Roy and Seif Haridi, MIT Press, 2004 ISBN 0-262-22069-5
- Essentials of Programming Languages - 2nd Edition
Daniel P. Friedman, Mitchell Wand and Christopher T. Haynes
MIT Press 2001
|
|
|