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

• 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.
• Never ever EVER call any staff at home.

There are two kinds of assignments in this course: machine problems (MPs) and hand-written assignments (HWs). MPs are submitted as text files with a name of mpX where X is the number of the assignment, and with an extension, usually .ml, approporiate to the code type. HWs are submitted as PDFs, with a name of hwX-submission.pdf, unless otherwise specified in the assignemnt.

Each student is given an svn directory that needs to be checked out once before it can be used for submitting assignments as follows:

mkdir <working_directory> svn co https://subversion.ews.illinois.edu/svn/fa14-cs421/<your_netid> <working_directory>

After the initial checkout, <working_directory> will contain a subdirectory assignments. Once an assignment (MP or HW) has been announced, if you do an

svn up

you will add a directory named after the assignment (e.g. mp1) in the assignments directory. That directory will contain the information posted on the web for that assignment.

For an HW, the directory will contain the file hwX.pdf, whereX is the number of the HW. You need to add to that directory your submission, which needs to be called as specified in the distributed file hwX.pdf. Typically, your submission will need to be called hwX-submission.pdf, but check the assignment's instructions. To submit your assignment, you will need to do the following:

svn add hwX-submission.pdf svn commit -m "<your comment here>"

Submissions for HWs should be in pdf format.

When you retrieve an MP via svn up the directory added will contain a pdf named mpX.pdf describing the work to be done for the assignment, a file of a name (typically mpX.ml) that is the same name as the file you must submit, and infrastructure to help you test your code. The file mpX.ml is just a stub. You need to delete or comment out the stub code and add your own. The webpage mps contains further information about how to test your code. For submission, you will only need do

svn commit -m "<your comment here>"

in the directory where your MP is. You do not need to add it, since we added it is as a stub for you. Please try to avoid committing the .cmo and .cmi files into the svn repository; it only occupies unnecessary space on the server and wastes unnecessary network traffic. You may always restrict svn commit to a specific collection of files and directories by adding a list to the end of the command.

Before submitting an MP assignment, you MUST make sure that your MP compiles with the student grading script supplied with the assignment. If your MP fails to compile with the student grading script, your assignment will get NO CREDIT. There will be no partial credit for assignments that fail to compile.

You may do multiple commits of either the MPs or the HWs. We will only grade the last version committed before the Extension deadline. Each homework will be classified as on time if its last submission is logged before the Due date of the assignment. If the last submission before the Extension deadline is after the Due date, you will receive a late penalty as described in the next section. <-- the version that is in the repository at the time specified by the due date in the assignment instructions is the one that will be collected and graded. -->

Each MP/HW will normally have an automatic 48-hour extension with a penalty on that MP/HW of 20% the total value of the assignment. If we cannot give such an extension for a particular MP/HW, for example due to scheduling constraints, we will announce that when the MP/HW is handed out.

During the automatic extension, staff is not obliged to answer questions for that MP/HW. 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/HW deadline.

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.

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), when no specific notation was prescribed in class.
• 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.

If your collaboration extended beyond understanding for what the problem was asking, then you should note on your assignment with whom you collaborated. As always, you are subject to the rules for plagiarism. Whether you pass this course or not will depend heavily 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.

Think of MPs and written assignments 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 and written assignments.

We will be looking for cheating on both assignments and exams. The penalty for being caught cheating a first time -- either sharing your solution or copying anyone else's solution on an exam, or copying anyone else's solution on an assignment without citation -- is that you will receive a negative score for the unit cheated on equal to the value of the unit. A assignment (MP or hand written assignment) is one unit. A numbered problem on a test, including all its parts, is a unit. The penalty if you are caught cheating a second time is a grade of F for the class. You should take all reasonable precautions to prevent others from cheating and report any suspected cheating.

Exams will only be handed back in class once. If you are not present when the exam is handed back, you must pick up your assignment from the instructor during the instructor's office hours. All work will be returned only to the author; no proxy may collect your exam for you.

• The Objective Caml system, release 3.12 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.
• Modern Compiler Implementation in ML by Andrew Appel. Published by Cambridge University Press. ISBN 0-521-60764-7 (paperback).
• 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.
• Essentials of Programming Languages, 2nd Edition; by Friedman, Wand, and Haynes. Published by MIT Press 2001. ISBN: 0-262-06217-8.
• 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