Homework 4 Guidelines

+, −, *, /, mod, =, <, >, <=, >=, abs, and, append, atom, car, cdr [cadadr, etc.], cond, cons, defun, equal, first, second [third, etc.], last, length, let, let*, list, listp, max, min, not, nth, nthcdr, null, numberp, or, quote ['], rest, reverse, stringp, symbolp, and time.

1. hw4.lsp — This file should contain all functions and all commented LISP code. This code should not contain dribble statements or the bye command. Everything in this file that is not code must be protected by the comment character (semicolon ";"). For full credit, this file must load correctly into gcl without error.
   
   
2. hw3.out — This file should contain only the sample execution of your code. You should include any test cases provided in the assignment, as well as sufficient cases to demonstrate correct functionality.

[westholme1] script hw4.out
Script started, file is hw4.out
[westholme1] gcl
GCL (GNU Common Lisp)  Version(2.3) Mon Mar 13 14:49:55 PST 2000
Licensed under GNU Library General Public License
Contains Enhancements by W. Schelter

>(load "hw4.lsp")

<... run your test cases here ...>

>(bye)

[westholme2] exit
Script done, file is hw4.out

Correct Filenames

Assignments must be submitted using the filenames specified. Filenames are case sensitive. Submissions using other filenames may be ignored, but will most likely result in a deduction of points.

Name/Assignment Header and General Comment

At the top of each file submitted, there should be a comment that includes the name, date, and so forth.

;;;;;
;; Name: Your Full Name
;; login: Your SEASnet username
;; ID: Your UCLA Student ID
;; CS161, Lecture 1
;; Homework 4
;; Date: The Date
;;;;;

There should also be a general, overall comment that discusses in detail the algorithmic approach to the solutions to each of the problems.

Function Header Comments

For each function in the assignment, including any helper functions that may be allowed, you must write a header comment. It should include the function name. It must include the names of the arguments, the data-types and domains that are acceptable arguments to the function, and the data-type and range that is the return value. The header should explain simply in natural language what the function does.

Internal Comments

Each function should have internal comments that explain the interesting parts of the code. These comments should loosely relate the code to the general algorithm discussed in the general comment at the top. For example, comments like "split the tree in half using split-list and then recursively apply list2btree to each half". Each part of the code that does something "interesting" should have some sort of comment. These comments should be embedded at the point of the code they describe. They can be brief.

Meaningful, Intuitive, Non-confusing Variable Names

Variable names should be consistently determined and should relate to the values a variable represents. Single letter variable names should be avoided except in special cases (the list L, geometric coordinates x and y, etc.). Just because LISP is case insensitive does not mean that it is acceptable to alternate between uppercase and lowercase versions of variable names to represent the same variable. This is very confusing. Don't do it. Also, avoid using l (lowercase L) as a variable name; it can be easily confused for a 1 when reading arithmetic operations. In general, variables should be named with small words, e.g., Len1, Len2, elem, L-branch, R-branch, etc.

Illegal Built-Ins and Extraneous Helper Functions

Do not use LISP built-ins that are not on the permitted list. Points will be deducted for using them. Do not write helper functions for problems that ask you to use a single, pure LISP function. Points will be deducted for using more functions to solve a problem than are allowed.

Code Layout, Indentation, and Spacing

Please indent your code so that it is easily readable. Indent using either spaces or tabs, but not a mix of both. A mix of both can appear completely messed up when viewed on other machines. Ideally, source code fits in 80 column width. You should limit each line in your code to no more than 80 column width. Bear in mind that tabs may take up as many as 8 columns when displayed on some machines, so if you are unsure, use spaces to indent, rather than tabs.

telnet courseweb.seas.ucla.edu 13