### 4.1 Compilation Procedures

procedure: cf filename [destination]

  This is the program that transforms a source-code file into native-code binary form. If destination is not given, as in

      (cf "foo")

  `cf` compiles the file `foo.scm`, producing the file `foo.com` (incidentally it will also produce `foo.bin`, `foo.bci`, and possibly `foo.ext`). If you later evaluate

      (load "foo")

  `foo.com` will be loaded rather than `foo.scm`.

  If destination is given, it says where the output files should go. If this argument is a directory, they go in that directory, e.g.:

      (cf "foo" "../bar/")

  will take `foo.scm` and generate the file `../bar/foo.com`. If destination is not a directory, it is the root name of the output:

      (cf "foo" "bar")

  takes `foo.scm` and generates `bar.com`.

About the `.bci` files: these files contain the debugging information that Scheme uses when you call `debug` to examine compiled code. When you load a `.com` file, Scheme remembers where it was loaded from, and when the debugger (or `pp`) looks at the compiled code from that file, it attempts to find the `.bci` file in the same directory from which the `.com` file was loaded. Thus it is a good idea to leave these files together.

`.bci` files are stored in a compressed format. The debugger has to uncompress the files when it looks at them, and on a slow machine this can take a noticeable time. The system takes steps to reduce the impact of this behavior: debugging information is cached in memory, and uncompressed versions of `.bci` files are kept around. The default behavior is that a temporary file is created and the `.bci` file is uncompressed into it. The temporary file is kept around for a while afterwards, and during that time if the uncompressed `.bci` file is needed the temporary file is used. Each such reference updates an ‘access time’ that is associated with the temporary file. The garbage collector checks the access times of all such temporary files, and deletes any that have not been accessed in five minutes or more. All of the temporaries are deleted automatically when the Scheme process is killed.

Two other behaviors are available. One of them uncompresses the `.bci` file each time it is referenced, and the other uncompresses the `.bci` file and writes it back out as a `.bif` file. The `.bif` file remains after Scheme exits. The time interval and the behavior are controlled by the following variables.

variable: *save-uncompressed-files?*

  This variable affects what happens when `.bci` files are uncompressed. It allows a trade-off between performance and disk space. There are three possible values:

  `#f`

    The uncompressed versions of `.bci` files are never saved. Each time the information is needed the `.bci` file is uncompressed. This option requires the minimum amount of disk space and is the slowest.

  `automatic`

    Uncompressed versions of `.bci` files are kept as temporary files. The temporary files are deleted when Scheme exits, or if they have not been used for a while. This is the default.

  `#t`

    The `.bci` files are uncompressed to permanent `.bif` files. These files remain on disk after Scheme exits, and are rather large—about twice the size of the corresponding `.bci` files. If you choose this option and you are running out of disk space you may delete the `.bif` files. They will be regenerated as needed.

variable: *uncompressed-file-lifetime*

  The minimum length of time that a temporary uncompressed version of a `.bci` file will stay on disk after it is last used. The time is in milliseconds; the default is ‘`300000`’ (five minutes).

variable: load-debugging-info-on-demand?

  If this variable is `#f`, then printing a compiled procedure will print the procedure’s name only if the debugging information for that procedure is already loaded. Otherwise, it will force loading of the debugging information. The default value is `#f`.

procedure: sf filename [destination]

  `sf` is the program that transforms a source-code file into binary SCode form; it is used on machines that do not support native-code compilation. It performs numerous optimizations that can make your programs run considerably faster than unoptimized interpreted code. Also, the binary files that it generates load very quickly compared to source-code files.

  The simplest way to use `sf` is just to say:

      (sf filename)

  This will cause your file to be transformed, and the resulting binary file to be written out with the same name, but with pathname type `"bin"`. If you do not specify a pathname type on the input file, `"scm"` is assumed.

  Like `load`, the first argument to `sf` may be a list of filenames rather than a single filename.

  `sf` takes an optional second argument, which is the filename of the output file. If this argument is a directory, then the output file has its normal name but is put in that directory instead.