CSCI 330 Lab 1: Lisp fundamentals

You'll have two weeks to do the lab (including the lab sessions on Jan. 12th and 19th) and it will be due at the end of the day on Jan. 25th.

The exercise involves forking/cloning a git repository, editing the lab1.cl and test1.cl files, and then submitting your updated repository.

Instructions are given below and will be discussed in the lab sessions, along with a basic intro to working with lisp/sbcl.

In this first lab we include a review of the basic git process for obtaining/submitting labs, for later labs we'll simply dive straight into the actual lab requirements.

Marking: the lab will be marked out of 18. Of that, 14 marks are for the function implementations in lab1.cl and the other 4 are for your testing of those functions in test1.cl.

Git submission system

For this lab (and all CSCI 330 labs this term) you will be using an adaptation of the git version control system to get the starting lab material, to track changes as you make them, and ultimately to submit your completed lab.

You must use this system to obtain and submit your work - no other submission mechanism will be accepted.

For students new to ssh/linux/git intro to linux accounts, ssh, very basic linux - youtube, slides basic programming tips for ssh/C++ on our systems - youtube, slides git submit basics and troubleshooting - youtube, slides short guide to csci git project/lab submission

NOTE: if you have taken csci330 previously then it would be advisable to archive your old csci330 directory at the start of the term, e.g. mv csci330 old330

The basic instructions to obtain your lab1 are shown below (issued from cubs/pups).

    mkdir -p csci330
    ssh csci fork csci330/lab1 csci330/$USER/lab1
    cd csci330
    git clone csci:csci330/$USER/lab1
    cd lab1

Working on and submitting your lab

After your git fork/clone steps, in your lab1 directory you should find files named lab1.cl and test1.cl, which will be the files you are ultimately graded on for the lab.

Edit the files with whatever text editor you prefer, and whenever you are ready to submit the lab use the following commands (from within your lab1 repository):

git add lab1.cl git add test1.cl git commit -m "whatever your message is" git push

(You can do the add/commit/push cycle as often as desired when submitting the lab.)

Lab 1 objectives

Lab 1 is meant to give you practice with the fundamentals of programming in lisp:

• working with executable lisp scripts that also load other lisp files
• writing and calling functions, including recursive functions
• performing type checking
• using cond effectively
• performing basic i/o
• performing basic computation and string manipulation
• working with lists and strings
• devising and applying suitable suites of test cases to your lisp functions

Lab 1 requirements

For lab 1, you are to finish implementing the functions in the provided lab1.cl file, and test/debug them using your test1.cl script. (When I mark your lab1.cl code I'll be using my own test1.cl script as well as yours.)

The functions themselves are discussed in detail in the lab1.cl file (copied below), but in general they involve

DETAILS TBA

Attempting functional purity:

• Your lab1.cl functions cannot create or use any variables including variables implicitly declared through the use of setf/setq. (The only data values your functions can use/access are the passed parameters.)

• Your lab1.cl functions are not permitted to have side effects other than i/o with the user. (Note this effectively means you cannot use setf or its variants.)

• Your lab1.cl functions must use recursion, not loops, for any/all iteration/repetition. (The functions are not required to be tail recursive.)

• Your lab1.cl functions cannot use sequences of statements: each function's body must be a single statement which cannot be block, let, prog or their variants.

  General/structural requirements:

• The implementation of the lab1.cl functions must follow their specifications provided in (the original) lab1.cl as closely as possible.

• The lab1.cl file cannot have the #! line at the top, whereas the test1.cl file must have the #! line at the top.

• In the lab1.cl file no statements can appear outside function definitions: i.e. no stand-alone statements/function calls anywhere in the file outside a function definition.

  You can and should create as many additional helper functions in lab1.cl as needed. (I used a dozen or so helpers in the sample solution.)

• All error messages must clearly identify the specific nature of the error.

• While there are no specific code standards for the labs, you are still expected to follow sound practices in the use of identifiers, comments, layout etc. Penalties may be applied to code that is difficult to read/debug because of poor coding practices.

lab1.cl: the key functions you are to implement

Skeletal versions of the functions have been set up in the lab1.cl file, you'll be completing the bodies of each of the functions (at the moment they each simply return nil).

Do not alter the names of the functions or their parameter lists.

The specifications for the functions are provided in the comments in lab1.cl, and are repeated below (along with description strings for each).

DETAILS TBA

Additional tips:

• I would very much recommend taking an incremental approach to development: for each function get a very basic version of it working, possibly a version that isn't functionally pure, then slowly tweak it to improve the error checking, handle more complex cases, and achieve functional purity.

  The error messages from the sbcl compiler are generally not very intuitive, so add and debug small chunks of code at a time!

  We'll spend two lab sessions on this lab (Jan. 12th and 19th), but I strongly recommend trying to make decent progress in the first week.

• Expand your test cases using test1.cl as you get more complete functionality for each of the functions in lab1fun.cl (especially error checking: create test cases that pass invalid values to the various functions)

• Since you can't declare/use variables in your functions, think about using intermediate/helper functions (and their parameters).

  Example: DETAILS TBA

• If you have a function that seems to need to do two separate things in sequence, e.g. prompt a user then read/return their response, consider passing one of those actions as a parameter to a function that does the other.

  Example: Suppose I need to prompt the user to enter yes/no in response to a question, then return true if they answered yes, false otherwise. My yesOrNot function can take the result of the prompt as a dummy parameter and return the result of the read/compare The caller actually passes the result of the format prompt, e.g. (defun yesOrNot (promptResult) ; return the result of comparing the user response to "yes" (string= "yes" (read-line))) (defun someCaller () ; ask the user a yes/no question as part of the call to yesOrNot (if (yesOrNot (format t "Does this example make sense (yes or no)?")) ; deal with yes's (format t "yay~%") ; deal with no's (well, not yes's) (format t "boo~%")))

• Remember your recursion and (again) use helper functions at will

  Example: DETAILS TBA

• Misc. lisp tips that might be useful:
  • (typep c 'STANDARD-CHAR) will check if variable c currently holds a char
  • (format nil "~A~A~A" strpart1 c strpart2) might be a useful way to 'insert' a char into a string if you can divide it into two parts, which can be done with (subseq str 0 k) and (subseq str k)
  • (char str i) lets you access the i'th char in a string (0-indexed)
  • remember to use string= if you need to compare strings
  • I recommend read-line, rather than read, since read converts everything to uppercase

• If you want to try out your lab1.cl functions in the interpretter, rather than through the test1.cl script, do the following:
  • cd into your lab1 directory
  • start the interpretter, sbcl
  • load your lab1.cl file using the command
    (load "lab1.cl")
    this might give some style warnings (functions with unused parameters etc), but if the load succeeds it will return true (T) at the end
  • now you can try calling the individual functions in the interpretter
  • use (quit) to end the interpretter

• If it's any consolation, in labs 2 and 3 we'll be discarding functional purity while we focus on lisp's handling of higher order functions, its macro system, and its treatment of lisp code as lisp data.

test1.cl: a test script for checking/debugging your functions

The test1.cl script is executable. It loads the lab1.cl file and interacts with the user to carry out any desired testing.

Its intended use is as a testing (and debugging) mechanism for you to check that your lab1.cl functions actually work correctly. All testing and debugging code, including test values, belongs in the test1.cl script, NOT in lab1.cl. Marks will be deducted if you including testing/debugging content in your lab1.cl file.

A few sample data values and test calls are included in the initial version of test1.cl, but these are nowhere near complete. A copy of the initial test file is shown below.

#! /usr/bin/sbcl --script (format t "~%--- Begin loading lab1.cl ---~%") (load "lab1.cl") (format t "~%--- completed loading of lab1.cl ---~%") DETAILS TBA

Sample working self-test run

The example below shows a run of the initial test1.cl but where the functions in lab1.cl been completed:

--- Begin loading lab1.cl --- --- completed loading of lab1.cl --- DETAILS TBA ---END OF TESTING---

Hints/tips for the lab1.cl functions

You're definitely not required to use these approaches, but if you're struggling with any of the functions here are the approaches I used to try and meet our functionally pure(ish) goals.

If you'd like to use this as your approach I suggest sketching a quick graph of which functions call which (and which ones recurse), as that will definitely help clarify the structure of what's going on. (It's easy to get a bit muddled just reading through the functions individually.)

DETAILS TBA