Announcements

09/07/2017: First LISP tutorial will be held on 09/08/2017 (Friday) from 5pm to 6pm at Goergen Hall 109. The place is subject to a change as I need to check if I can use my laptop with the projector there, but the time is fixed. For the people who cannot make it this Friday I will hold another tutorial next week (we'll figure out the date later).

General info

Classes are on Tuesdays and Thursdays, at 9:40am-10:55am, in CSB 601.

For programming assignments Allegro Common Lisp is recommended (which can be accessed by the acl command in the terminal, or, alternatively through this path: /p/lisp/acl/linux/latest/alisp). If you cannot access Allegro, you can use Steel Bank Common Lisp (SBCL). SBCL is integrated in the system, so just type sbcl to run the REPL.

Submitting Assignments

All written assignments must be put in my mailbox (in the CS mailroom - Weg 2601) before the time the assignment is due, or submitted in person just before the relevant class meeting. Programming assignments should be submitted via the turn_in script:

For grads: /u/cs444/turn_in <dir>

For undergrads: /u/cs244/turn_in <dir>

where <dir> is the directory containing all the files in your submission.
For each programming assignment, your submission must include the following three separate files (or face grade penalties):

yourCSid_src.lisp the source file containing all the code necessary for your solutions to the assignment;

If you have problems with turn_in, please email TA and ask for assistance. If it's close to the submission deadline, go ahead and email your assignment to TA to avoid late penalties.

!!NOTE!!: If you are a master student and cannot access /u/cs444/turn_in, use /u/cs244/turn_in.

Homework Guidelines

The source code accounts for about 60% of the grade and the rest is based on your test file, writeup, and coding style.

Code Style

Please comment your code thoughtfully:

At the beginning of each function, provide a statement of its purpose, the meaning and type of each of the parameters (with an example if the value has some special form), and the return value or effect of the function.

If anything is unclear in the body of a function, explain what is going on. This ranges from places where you are taking cars of cdrs of cars, to places where your recursive solution hinges on the fact that some recursive call has already taken care of the special case that the user might wonder about. When in doubt, comment.

Try to keep your Lisp code to 80 characters or less per line, and indent meaningfully. We should not have to modify any of your source code to grade your submission. If you can't get a particular function to work, please define a stub which prints a meaningful message such as "STUB: function [function-name] not implemented.". Be careful with global variables as they may be rewritten where you don't expect. Don't forget to type-check your inputs.

Test File

Include test cases for each problem, and make your test file (*_test.lisp) executable in one of the Common Lisp implementations on the URCS servers (preferably Allegro Common Lisp). A good, modular test framework for Lisp can be found in Practical Common Lisp. The basic idea is to print, for each test case:

the function and input being tested,

the expected result,

an indication of whether the test case passed or failed, and

(optionally) the actual result.

The TA should be able to tell, after reading your testing document, how well you understood the problem. Make sure to test all boundary cases (e.g., empty list, symbols, non-empty lists).

Writeup/README

Please include the following in your writeup:

the names of all your program and data files, with short descriptions of contents, if this is not evident from the names;

the names and types of arguments for functions we have to call to test your program;

general description of the algorithm, including your design choices such as storing data in a hash table vs a list; (In general, if you think I may have trouble understanding any part of the code, and the necessary explanations are inappropriate or beyond the scope of function or inline comments, then those explanations should be included in the README.)

the input and output data format;

which CL implementation you used

known bugs you did not have time to fix;

answers to any questions asked in the assignment;

(if applicable to you) which provided solutions (which version, which author, and which previous phase) you have used in your current version.

The level of detail of the write up should be proportional to the complexity of the code, if the function does something simple, e.g., sorts the lists, just mention it in a few words. Also, if you're running out of time and cannot implement something, describe in more detail how you would have done it - you may get some credit for this, too.

Late Assignments

Late assignments will sometimes be accepted, depending on your circumstances, with a 20% reduction in grade for every day late. Submissions will no longer be accepted once it is necessary for me to distribute grades or discuss solutions. We may refuse to accept severely late assignments, depending on the time required to grade the particular assignment or the quality of your excuse.

Regrade Policy

All regrade requests should be done within five weekdays of receiving your mark by email. No appeals will be accepted after this period. In addition, when presenting your request, you must submit a written statement of why you contest your mark and which questions you'd like me to re-evaluate. Requests will not be accepted without your written statement.

Credits

The structure and content of this page was mostly borrowed from Gene L. Kim's page, who was the previous TA for this class.