Tips for using Scheme and debugging your code

This page contains a number of tips and tools, most of which I've talked about in class, for the following topics:

Using Scheme
Debugging your code

If there are any questions that aren't addressed here, let me know and I'll update this document.

Using Scheme

Here are a few other commands that should make your life a little easier. These can all be found in the MIT Scheme reference and user's manual. I highly recommend browsing these manuals.

(load "myprogram.scm")
loads all the definitions from a file into the Scheme interpreter.
(pwd)
prints the working directory (the default directory for loading files)
(cd "dirname")
changes the working directory. You can specify relative pathnames such as "../assign3".

For some assignments, you will probably want to start Scheme with more memory. In UNIX, you can just give some additional command line switches. In Windows, you should probably create some new shortcuts based on the ones that already exist in your start menu. You can edit the shortcuts to add the following command line switches.

scheme -large
Starts Scheme with a larger heap (about 3-4 times larger than usual).
scheme -heap 4000
Starts Scheme with a heap of 4000K words. For reference, the -large switch is equivalent to about 1200K or 1300K words.

You can get information on the amount memory that Scheme is using with the command (print-gc-statistics).

Debugging Scheme code

Debugging is a learned art. Part of that art is learning how to use available tools to see what's going on in your code. Here are a few tools/suggestions:

Take advantage of the interpreter
Scheme is an interpreted language; this means that it's easy to run small parts of your program to make sure that they're doing the right thing.
Use the debugger
The Edwin debugger will show you lists of subproblems and reductions (see the MIT Scheme User's manual for a more detailed explanation of this). It will also let you evaluate expressions in the environments for these subproblems and reductions.
Don't expect to understand everything that appears on the screen in the debugging window. It can be a bit cryptic, so you'll have to look carefully for information that you can use and that makes sense to you.
To start, use the debugger to find out where in your code the error is being generated and what inputs cause that error.
Trace your procedures
Tracing procedures is a powerful mechanism for debugging. You can trace a function with the command:
```
  (trace function-name)
```
Then, whenever this function is called, it will print a message to the screen showing what arguments it was called with. When the procedure returns, it will print a message showing what value that call returned.
To turn off tracing, use the command:
```
  (untrace function-name)
```
Or, to turn off all tracing, simply:
```
  (untrace)
```
When you reload a file, all the procedures will be reset to being untraced. You can put these commands in your Scheme file while you are developing your code. (But take them out before you submit your file!)
Print messages from your procedures
This is the old standby, perhaps the most straightforward approach to debugging but the least sophisticated. The Edwin debugger is good for seeing what causes an error, but is harder to use for interactively debugging your code as it runs (i.e. setting breakpoints and such).
The display procedure takes a single argument which it will print to the screen. I often define a "print" procedure which allows me to give it an arbitrary number of arguments.
```
(define (print . args)
  (cond ((not (null? args))
         (display (car args))
         (apply print (cdr args)))))
```
Here is an example of how to use it for debugging:
```
(define (my-function a b c)
  (print "\nMy function was called with the arguments: " 
         a " " b " " c "\n")
  (if (= a b)
    (begin
      (display "\nHey, A and B are the same!\n")
      (my-fun-helper b c))
    (begin
      (display "\nOops, A and B are different!\n\n")
      (my-fun-helper a b))))
```