Overview

This course features several lab assignments, as listed on the assignments page.

• Unless otherwise stated:
• collaboration outside your partner IS NOT allowed on programming assignments.
• you may use language references to determine relevant Scheme or C syntax and semantics. Since syntax is standardized, we will consider this to be "general knowledge", and you need not cite reference sources.
• you may consult only the textbook and a language reference (e.g., The Scheme Programming Language) for information. All non-syntax consultations (including the textbook and Scheme references) require formal citation within the related program or write-up. Failure to do otherwise may constitute a violation of the college's academic honesty policy.
• You always may consult the instructor regarding questions on labs (at least if the instructor is in his office with the door open).
• You may always consult your colleagues regarding questions on interpreting assignment-related example/starter code or about what an assignment is asking. However, you may never consult with your colleagues about solutions or implementations.
• Programs (source code and output) are to be submitted in the format below.

Submitting Programs

In turning in any programs for the course, please follow these directions:

1. The first seven or more lines of any Scheme file should be comments containing your name, your mailbox number, the class section, an identification of assignment being solved, and a description of the contents of the file. For example

    
   ;;
   ;; File
   ;;   search.scm
   ;;
   ;; Author
   ;;   Jerod Weinman
   ;;   Box - Noyce Science Division Office
   ;;   CSC261.01
   ;;
   ;; Summary
   ;;   Provides a collection of routines finding solutions to search space problem
   ;;
   ;; Provides
   ;;   (search start-state problem enqueue heuristic)
   ;;   (breadth-first-search start-state problem)
   ;;   (depth-first-search start-state problem)
   ;;   (uniform-cost-search start-state problem)
       

2. A comment is required for every definition of a Scheme method, stating the purpose of the program unit in English. Complete 6-P documentation is not necessary for every method (unless specified otherwise), but it is strongly encouraged, especially on major routines. Documenting before you write a procedure can help you plan and clarify the requirements of your implementation.
3. Obtain a nicely formatted PDF listing of your source code using the enscript(1) command:
   enscript -Escheme -2 -r --color -p - source.scm ... | ps2pdf - prettysource.pdf
   where prettysource.pdf is the name of the file in which you want the formatted source code stored (enscript(1) generates a PostScript file, which you will pipe to ps2pdf(1) for conversion to PDF.) If your work involves several Scheme files, list the primary program first, then list any supplementary files. Multiple source files can be placed in one call to enscript(1). You may also use a wildcard such as *.scm. However, be sure this does not include any starter files, which should NOT be submitted.
4. As appropriate, create a transcript of your program's output runs using the script(1) command:
   1. In a terminal window, start recording output to a file called transcript with the command:
      script transcript
   2. Run your program with appropriate test cases to check its correctness (it is usually best if you have written one Scheme file to take care of most of this behavior). For instance:
      mzscheme -l lang/plt-pretty-big-text.ss -f driver.scm
      runs driver.scm with the "Pretty Big" version of PLT Scheme.
   3. When your run is complete, stop the script session by typing Ctrl-D.
   4. Convert the recorded text file to a nice, printable PDFfile using enscript(1):
      enscript -2 -r -p - transcript | ps2pdf - transcript.pdf
      where transcript is the name of the recording file you created above, and the ".pdf" file is the printable version enscript(1) creates.
5. Concatenate and print your program listing, transcript, etc, i.e.,
   pdfconcat -o submission.pdf prettysource.pdf transcript.pdf
6. Create an archive of your source files and PDF for electronic submission. For example,
   tar cf submission.tar submission.pdf source.scm ...
   where submission.tar is the name of the archive file you want your files stored in. You may list as many source files on line as you wish, or even use a wildcard (*.scm) Please be sure you do not include any intermediate PDF files, etc.
7. One group member should submit an electronic version of the archive (submission.tar from above) online via PioneerWeb by the due date.

Notes on Grading

Requirements

Since every programming task should yield readable and carefully tested code, the grading of all programs for this course will begin with the following algorithm (expressed in Scheme format):

    (if (or (not (commented? code))
            (not (visibly-tested? code)))
        0
        (grade code))
  

When a program is submitted according to the format specified above, it should be understood that the transcript reflects a complete session of program running. With this understanding, editing of any script file is strictly forbidden and will be considered a violation of academic honesty, which, by College policy, must be turned over to the Committee on Academic Standing for action.

Style

Because code maintainability is an important part of development, your labs will be graded in part on style, as well as correctness. After all, if I cannot understand your code (or it takes me too long to), I cannot give it a grade regarding its correctness.

Some style matters I care about:

• Indentation/whitespace that helps delineate code blocks. (Most editors will help you with this.)
• Helpful comments on blocks of code or particularly complicated expressions
• Procedures that are reasonably small. (A very good guideline I try to follow is getting an entire procedure to fit on much less than one screen; this makes interpreting a procedure's action more readable by forcing you to break it down into named steps that can be seen at once. It also promotes easier debugging and unit testing.)
• Code lines that are no wider than 80 characters. This makes them easier to read both on screen and on paper. (Note: If running enscript on your program code produces X lines were wrapped, where X is some number, then your lines are wider than 80 characters and you should re-format your code with additional linebreaks.