-*- Indented-Text -*- $Header: user.txt,v 1.6 90/09/07 00:06:17 GMT cph Exp $ Notes on the Scheme User Interface Chris Hanson This document describes some of the procedures that are used to load and run programs. The procedures described here are not normally called from programs -- they are designed for use by people typing at Scheme's top level. * Getting In and Out of Scheme Starting up the Scheme interpreter is somewhat system dependent, so you should find out specifically how to do this from whoever maintains Scheme at your site. Usually, the program is invoked by typing scheme at your operating system's command interpreter. Scheme will load itself, clear the screen, and print something like this: Scheme saved on Wednesday November 14, 1990 at 8:47:34 AM Release 7.1.0 (alpha) Microcode 11.54 Runtime 14.102 This information, which can be printed again by evaluating (identify-world) tells you the following version information: "Release" is the release number for the entire Scheme system. Usually this number is incremented each time a new version of Scheme is released. An "(alpha)" or "(beta)" following the release number indicates that this is a alpha- or beta-test release. "Microcode" is the version number for the part of the system that is written in C. "Runtime" is the version number for the part of the system that is written in Scheme. Any other information following the above is version numbers for specific subsystems. "SF" refers to the scode optimization program SF, which is described below. Other systems include the "Liar" native-code compiler, the "Edwin" editor, and the "Student" S&ICP compatibility package. If the compiler is supported in your system, you can invoke it by the shell command scheme -compiler This command invokes Scheme with a larger constant space and heap, and causes it to load the world image containing the compiler. A more detailed explanation of Scheme's command-line options appears below. Scheme supports "init" files. On unix systems, the file "~/.scheme.init" is loaded immediately after the identification banner, and before the prompt is printed. There are two ways you can leave the Scheme interpreter. The first is to evaluate (exit) which will halt the Scheme system. Any information that was in the interpreter is lost, so this should not be done lightly. The other way is to suspend the interpreter. When this is done you may restart the interpreter where you left off. Unfortunately this is not possible in all operating systems -- currently it is known to work on BSD Unix, Ultrix, SunOS, HP-UX (version 6.5 or later). It does NOT work on AT&T Unix. (Specifically, for unix or POSIX systems, suspension is available if the system supports job control.) The command for suspending is (quit) If your system supports suspension, this will cause Scheme to stop, and you will be returned to the operating system's command interpreter. If your system doesn't support suspension, this procedure does nothing. * The Read-Eval-Print Loop When you first start up Scheme, you will be typing at a program called the "Read-Eval-Print Loop" (abbreviated REPL). It displays a prompt at the left hand side of the screen whenever it is waiting for input. You then type an expression (terminating it with RETURN). Scheme evaluates the expression, prints the result, and gives you another prompt. ** The Prompt and Level Number The REPL prompt normally has the form 1 ]=> The "1" in the prompt is a "level number", which is always a positive integer. This number is incremented under certain circumstances, the most common being an error. For example, here is what you will see if you type "f o o RETURN" after starting Scheme: 1 ]=> foo Unbound Variable FOO 2 Error-> In this case, the level number has been incremented to "2", which indicates that a new REPL has been started (also the prompt string has been changed to remind you that the REPL was started because of an error). The "2" means that this new REPL is "over" the old one. The original REPL still exists, and is waiting for you to return to it. Meanwhile, any changes you make to this REPL will not affect the original one. Furthermore, if an error occurs while you are in this REPL, yet another REPL will be started, and the level number will be increased to "3". This can continue ad infinitum, but normally it is rare to use more than a few levels. The normal way to get out of an error REPL and back to the top level REPL is to use the C-G interrupt. This is a single keystroke command executed by holding down the "CTRL" key and pressing the "G" key. C-G always terminates whatever is running and returns you to the top level REPL immediately. NOTE: The appearance of the Error prompt does not mean that the Scheme system is in some funny inconsistent state which you should avoid. It is merely a reminder that your program was in error (an illegal operation was attempted, but it was detected and avoided, so Scheme is fine). Often the best way to find out what is in error is to do some "poking around" in the error REPL. If you abort out of it, the context of the error will be destroyed, and you may not be able to find out what happened. ** Interrupts This brings up the subject of interrupts. This is a highly system dependent topic, so I will discuss the implementation for Unix only. You must find out the details from your system wizard for other implementations. Scheme has two interrupt keys under Unix (other systems may have more than two): C-G and C-C. The C-G key causes the current Scheme program to stop immediately and returns you to the top level REPL. C-C prompts you for another character and performs some action based on that character. It is not necessary to type RETURN after C-G or C-C, nor is it needed after the character that C-C will ask you for. Here are the more common options for C-C: *** I Ignore the interrupt. Type this if you made a mistake and didn't really mean to type C-C. *** ? Print help information. This will describe any other options not documented here. *** Q Similar to typing (EXIT) at the REPL, except that it works even if Scheme is not executing the REPL. *** Z Similar to typing (QUIT) at the REPL, except that it works even if Scheme is not executing the REPL. *** C-C or C-G or G Identical to typing C-G. Another way to get this effect is to evaluate (CMDL-INTERRUPT/ABORT-TOP-LEVEL). *** C-X or X Abort whatever Scheme program is currently running and return to the "current" REPL. If no program is running, this just causes another prompt to be printed. Another way to get this effect is to evaluate (CMDL-INTERRUPT/ABORT-NEAREST). *** C-U or U Abort whatever Scheme program is running and go up one level. If you are already at level number 1, it just stops the program, leaving you at level 1. Another way to get this effect is to evaluate (CMDL-INTERRUPT/ABORT-PREVIOUS). *** C-B or B Suspend whatever Scheme program is running and start a "breakpoint" REPL. The program can be resumed by evaluating (proceed) in that REPL at any time. ** Proceeding Another way of exiting REPLs is to use the PROCEED procedure. There are two ways to use this procedure from inside an error REPL (usage from other kinds of REPL is not necessarily the same): *** (PROCEED) Retry the expression that caused the error. Unless you have done something to fix the error condition, this will just cause the error to happen all over again. In the example above with the unbound variable FOO, the proper way to use PROCEED is to first define FOO to have a value, then evaluate (PROCEED). Your program should then continue from that point normally. One caveat: when you get an unbound variable error, the environment for the REPL is the environment in which you looked up the variable, which is not necessarily the same environment you wanted to define the variable in. It is best to use the GE procedure to guarantee that your definition goes into the right place. *** (PROCEED ) Return in place of the expression that caused the error. Thus, if you cannot easily fix a particular bug, but you know what the proper value for the expression is, you can continue the computation this way. ** The Current Environment and Syntax Table Every REPL has a "current" environment, which is the place where expressions are evaluated, and definitions are stored. When you start up Scheme, this environment is the value of a variable called USER-INITIAL-ENVIRONMENT. There are a number of other environments in the system, for example SYSTEM-GLOBAL-ENVIRONMENT (where all of the Scheme system definitions are stored). You can get the current environment by evaluating (nearest-repl/environment) Also, if you have a procedure object, you can get a pointer to the environment in which it was closed by evaluating (procedure-environment ) Your programs create new environments whenever a procedure is called. When an error occurs, the error REPL that is created is usually initialized so that its current environment is the one in which the error occurred. Sometimes it is useful to change the current environment to another value, which you can do like this: *** (GE ) Goes to an Environment. This makes the current environment be . The argument to GE is allowed to be a procedure as well as an environment object. If it is a procedure, then the closing environment for that procedure is the new environment. *** (GST ) In addition to the current environment, each REPL maintains a current syntax table. The current syntax table tells the REPL which keywords are used to identify special forms (e.g. IF, LAMBDA). If you write macros, often you will want to make your own syntax table, in which case it is useful to be able to make that syntax table be the current one. GST allows you to do that. * Files and Loading To load files of Scheme code, use the procedure LOAD, as described in R^3RS. MIT Scheme extends the definition of LOAD in several ways: ** The first argument to LOAD may be a list of filenames rather than a single filename, in which case it loads them all in order. ** There is an optional second argument, which specifies the environment in which the file is to be loaded. ** There is an optional third argument, which specifies the syntax table to use when syntaxing source code. ** Load determines whether the file to be loaded is binary or source code, and performs the appropriate action. By convention, files of source code have a pathname-type of "scm", and files of binary SCode have pathname-type "bin". Native code binaries have pathname-type "com". ** The variable LOAD-NOISILY?, if set to true, will cause the value of each expression in the file to be printed as it is evaluated. Otherwise, nothing is printed except for the value of the last expression in the file. The procedure LOAD-NOISILY provides the same effect independent of the value of this flag. (Note: the noisy loading feature is implemented for source code files only.) ** If the pathname given to LOAD does not specify the type or version of the file, it tries the following files in this order (examples are in Unix syntax): 1. The exact name given "" 2. Type = "com" ".com" 3. Type = "bin" ".bin" 4. Type = "scm" ".scm" The list of default file types is stored in the variable LOAD/DEFAULT-TYPES, which is normally set to ("com" "bin" "scm"). You can change the value of this variable to alter the defaults. All filenames are interpreted relative to a working directory, which is normally initialized to the default directory at the time the interpreter was started. The working directory can be obtained or modified with the following procedures: (WORKING-DIRECTORY-PATHNAME) (SET-WORKING-DIRECTORY-PATHNAME! ) For typing convenience, there are aliases for these procedures, called PWD and CD, respectively. The long versions of the names are intended to be used in programs, the short names for interactive use. WORKING-DIRECTORY-PATHNAME always returns a pathname that has no name, type, or version components. SET-WORKING-DIRECTORY-PATHNAME!, if given a pathname with name/type/version components, will convert it into a pathname of the former type by adding those components to the end of the directory specification. Thus, under Unix, (SET-WORKING-DIRECTORY-PATHNAME! "/foo/bar") returns the pathname "/foo/bar/" as its value. * World Images Scheme provides support for saving and restoring entire world images, in two different ways. The first method writes a file containing all of the Scheme code in the world, which is called a "band". The file "lib/runtime.com" which is loaded by the microcode is just such a band. To make your own band, use the procedure DISK-SAVE: (DISK-SAVE ) or (DISK-SAVE ) Calling this procedure causes a band to be written into the specified file. The optional argument controls what happens when that band is restored, as follows: ** not specified Start up in the top-level REPL, identifying the world in the normal way. ** a string Do the same thing except print that string instead of "Scheme" when restarting. ** the constant #T Restart exactly where you were when the call to DISK-SAVE was performed. This is especially useful for saving your state when an error has occurred and you are not in the top-level REPL. ** the constant #F Just like #T, except that the runtime system will not perform normal restart initializations; in particular, it will not load your init file. To restore a saved band, use the "-band" argument to Scheme when it is started, or else use the procedure (DISK-RESTORE ) from a running Scheme, which will destroy the current world, replacing it with the saved world. DISK-RESTORE's argument may be omitted, in which case it defaults to the filename from which the current world was last restored. An alternative method for saving the world is the DUMP-WORLD procedure, which accepts the same arguments as DISK-SAVE, and works in much the same way. However, rather than dumping a band, DUMP-WORLD saves an executable image, which you start up in the normal (operating system dependent) way. This has the advantage of being considerably faster to start on some systems, but such an image typically takes a factor of 2 or more in disk space than the corresponding band. * CF (Compile File) [Note: the procedures described in this section are only available in the "compiler.com" world image.] CF is the program which transforms source code files into native code binary form. The simplest way to use CF is: (CF "foo") which compiles the file "foo.scm", producing the file "foo.com" (incidentally it will also produce "foo.bin", "foo.binf", and possibly "foo.ext"). If you later say (LOAD "foo"), "foo.com" will be loaded rather than "foo.scm". CF accepts an optional second argument, which is used to decide where the output files 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 the second argument is not a directory, it is the root name of the output: (CF "foo" "bar") takes "foo.scm" and generates "bar.com". About the ".binf" files: these files contain the debugging information that Scheme uses when you call (DEBUG) from within compiled code. When you load a ".com" file, Scheme remembers where it was loaded from, and when the debugger looks at the compiled code from that file, it attempts to find the ".binf" file in the same directory from which the ".com" file was loaded. Thus it is a good idea to leave these files together. Another useful thing that is contained in the ".binf" file is the symbol table produced by the assembler. If you have both the "foo.com" and "foo.binf" files, you can generate an assembly listing in "foo.lap" by evaluating: (COMPILER:WRITE-LAP-FILE "foo") More precise control over the compilation process is possible, but that will be documented (in the future) somewhere else. * SF (Syntax File) [Note: the procedures described in this section are only available in the "compiler.com" world image.] SF is the program that transforms source code files into binary SCode form. It performs numerous optimizations that can make your programs run considerably faster. Also, binary files load very quickly compared to source files. The simplest way to use SF is just to say: (SF ) This will cause your file to be transformed, and the new 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. Version numbers are preserved, that is, if the input file has a version number, the output file will have the same version number. 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 uses that directory instead. ** Declarations, and USUAL-INTEGRATIONS Several declarations can be added to your program to help SF make it more efficient. Normally, all files have a line (DECLARE (USUAL-INTEGRATIONS)) near their beginning, which tells SF that free variables whose names are defined in SYSTEM-GLOBAL-ENVIRONMENT will not be shadowed by other definitions when the program is loaded. If you redefine some global name in your code, for example CAR, you should indicate it in the declaration: (DECLARE (USUAL-INTEGRATIONS CAR CDR CONS)) You can obtain an alphabetically-sorted list of the names that this declaration affects by evaluating the following expression: (EVAL '(SORT (APPEND USUAL-INTEGRATIONS/CONSTANT-NAMES USUAL-INTEGRATIONS/EXPANSION-NAMES) (LAMBDA (X Y) (STRING<=? (SYMBOL->STRING X) (SYMBOL->STRING Y)))) (->ENVIRONMENT '(SCODE-OPTIMIZER))) ** INTEGRATE and INTEGRATE-OPERATOR Declarations Another useful facility provided by SF is the ability to in-line code procedure definitions. In fact, SF will perform full beta conversion, with automatic renaming, if you request it. Here are the relevant declarations: *** (DECLARE (INTEGRATE ...)) The variables etc. should be defined in the same file as this declaration. Any references to those names that appear in the same block as the declaration, or one of its descendants, will be replaced by the code from the definition. *** (DECLARE (INTEGRATE-OPERATOR ...)) Similar to the INTEGRATE declaration, except that it only substitutes for references that appear in the operator position of a combination. All other references are ignored. Note that the most common use of this facility, in-line coding of procedure definitions, requires a somewhat complicated use of these declarations. Because this is so common, there is a special form, DEFINE-INTEGRABLE, which is like DEFINE but performs the appropriate declarations. For example: (DEFINE-INTEGRABLE (FOO-BAR FOO BAR) (VECTOR-REF (VECTOR-REF FOO BAR) 3)) Here is how you do the same thing without this special form: there should be an INTEGRATE-OPERATOR declaration for the procedure's name, and (internal to the procedure's definition) an INTEGRATE declaration for each of the procedure's parameters, like this: (DECLARE (INTEGRATE-OPERATOR FOO-BAR)) (DEFINE FOO-BAR (LAMBDA (FOO BAR) (DECLARE (INTEGRATE FOO BAR)) (VECTOR-REF (VECTOR-REF FOO BAR) 3))) The reason for this complication is as follows: the INTEGRATE-OPERATOR declaration finds all the references to FOO-BAR and replaces them with the lambda expression from the definition. Then, the INTEGRATE declarations take effect because the combination in which the reference to FOO-BAR occurred supplies code which is substituted throughout the body of the procedure definition. For example: (FOO-BAR (CAR BAZ) (CDR BAZ)) First use the INTEGRATE-OPERATOR declaration: ((LAMBDA (FOO BAR) (DECLARE (INTEGRATE FOO BAR)) (VECTOR-REF (VECTOR-REF FOO BAR) 3)) (CAR BAZ) (CDR BAZ)) Next use the internal INTEGRATE declaration: ((LAMBDA (FOO BAR) (VECTOR-REF (VECTOR-REF (CAR BAZ) (CDR BAZ)) 3)) (CAR BAZ) (CDR BAZ)) Next notice that the variables FOO and BAR are not used, and eliminate them: ((LAMBDA () (VECTOR-REF (VECTOR-REF (CAR BAZ) (CDR BAZ)) 3))) Finally, remove the ((LAMBDA () ...)) to produce (VECTOR-REF (VECTOR-REF (CAR BAZ) (CDR BAZ)) 3) ** The REDUCE-OPERATOR declaration The REDUCE-OPERATOR declaration is provided to inform SF that certain names are n-ary versions of binary operators. Examples: The declaration (DECLARE (REDUCE-OPERATOR (CONS* cons) (LIST cons (NULL-VALUE '() ANY)) (+ %+ (NULL-VALUE 0 NONE) (GROUP RIGHT)) (- %- (NULL-VALUE 0 SINGLE) (GROUP LEFT)))) will cause the following replacements to take place: (CONS* x y z w) => (cons x (cons y (cons z w))), (CONS* x y) => (cons x y) (CONS* x) => x (CONS*) => error (LIST x y z w) => (cons x (cons y (cons z (cons w '())))) (LIST x y) => (cons x (cons y '())) (LIST x) => (cons x '()) (LIST) => '() (+ x y z w) => (%+ x (%+ y (%+ z w))) (+ x y) => (%+ x y) (+ x) => x (+) => 0 (- x y z w) => (%- (%- (%- x y) z) w) (- x y) => (%- x y) (- x) => (%- 0 x) (-) => 0 IMPORTANT NOTE: This declaration does not cause an appropriate definition of + (or other operators) to appear in your code. It merely informs SF that certain optimizations can be performed on calls to + by replacing them with calls to %+. You should provide a definition of + as well, although it is not required. The general format of the declaration is: (REDUCE-OPERATOR ( { (GROUP ) (NULL-VALUE ) (SINGLETON ) (WRAPPER ) })) where - is a symbol - , , , and are simple expressions: ' (PRIMITIVE { }) - is a member of {ALWAYS, ANY, ONE, SINGLE, NONE, EMPTY} - is a member of {LEFT, RIGHT, ASSOCIATIVE} The meaning of these fields is: - is the name of the n-ary operation to be reduced. - is a binary operation which performs the reduction. - The GROUP option specifies whether associates to the right or to the left to produce . - The NULL-VALUE option specifies a value to use in the following cases (each case is included in the following): NONE, EMPTY: When no arguments are supplied to , is returned. ONE, SINGLE: When a single argument is provided to , becomes the second argument to . It is provided on the left if the operator groups left, on the right otherwise. ANY, ALWAYS: is used on the "last" argument, and provides the remaining argument to . In the above options, when is supplied to , it is supplied on the left if grouping to the left, otherwise it is supplied on the right. - The SINGLETON option specifies a function, , to be invoked on the single argument left. This option supersedes the null-value option, which can only take the value NONE. - The WRAPPER option specifies a function, , to be invoked on the result of the outermost call to after the expansion. ** Miscellaneous Declarations: *** (DECLARE (INTEGRATE-EXTERNAL )) Causes SF to use the top level integrations provided by . should not specify a file type, and ".scm" must have been previously processed by SF. If is a relative filename (the normal case), it is interpreted as being relative to the file in which the declaration appears. Thus if the declaration appears in file "/usr/cph/foo.scm", then SF looks for a file called "/usr/cph/.ext". NOTE: When SF finds top level integrations, it collects them and outputs them into an auxiliary file with extension ".ext". This ".ext" file is what the INTEGRATE-EXTERNAL declaration refers to. *** (DECLARE (AUTOMAGIC-INTEGRATIONS)) Will cause SF to integrate LET bindings if they are trivial (other variables or constants). This optimization is usually turned OFF; if turned on, it can be disabled by the declaration (DECLARE (NO-AUTOMAGIC-INTEGRATIONS)). The native-code compiler automatically performs a more sophisticated form of this optimization. It is undesirable to use the AUTOMAGIC-INTEGRATIONS declaration in conjunction with the compiler. *** (DECLARE (ETA-SUBSTITUTION)) Will cause SF to replace (LAMBDA (X) (BAR X)) by BAR. This optimization can cause SF to go into loops, if not exercised with care, and can have other undesirable effects. This optimization is usually turned OFF; if turned on, it can be disabled by the declaration (DECLARE (NO-ETA-SUBSTITUTION)). The native-code compiler automatically performs the safe cases of this optimization. It is unnecessary to use the ETA-SUBSTITUTION declaration in conjunction with the compiler. * GNU Emacs interface There is an interface library called "xscheme", distributed with both MIT Scheme and GNU Emacs, which facilitates running Scheme as a subprocess of Emacs. If you wish to use this interface, please install the version of "xscheme.el" that comes with MIT Scheme, as it is guaranteed to be correct for your version of Scheme. To invoke Scheme from Emacs, use M-x run-scheme, which is defined when the library "scheme" is loaded. You can also give run-scheme a prefix argument, in which case it will allow you to edit the command line which is used to invoke Scheme. DO NOT remove the "-emacs" option! Scheme will be started up as a subprocess in a buffer called "*scheme*". This buffer will be in scheme-interaction-mode and all output from the Scheme process will go there. Also, the mode line will be changed to have information like the following in it between the filename and the mode information: 1 [Evaluator] (Scheme Interaction: input) The first field is the level number. The second field describes the type of REPL that is running. Other values include: [Debugger] [Where] The mode after Scheme Interaction is one of: input Scheme is waiting for input run Scheme is running your code gc Scheme is garbage collecting When "xscheme" is loaded, scheme-mode is extended to include commands for evaluating expressions (do C-h m in any scheme-mode buffer for the most up-to-date information): ** ESC o (xscheme-send-buffer) evaluates the current buffer. This has no effect when executed in the "*scheme*" buffer. ** ESC z (xscheme-send-definition) evaluates the current definition. This is also bound to ESC C-x. ** ESC C-z (xscheme-send-region) evaluates the current region. ** C-x C-e (xscheme-send-previous-expression) evaluates the expression to the left of point. This is also bound to M-RET. ** C-c C-s (xscheme-select-process-buffer) selects the "*scheme*" buffer and places you at its end. ** C-c C-y (xscheme-yank-previous-send) yanks the most recently evaluated expression, placing it at point. This works only in the "*scheme*" buffer. Also, the following commands provide interrupt capability: ** C-c C-c (xscheme-send-control-g-interrupt) is like typing C-g when running Scheme without Emacs. ** C-c C-x (xscheme-send-control-x-interrupt) is like typing C-c C-x when running Scheme without Emacs. ** C-c C-u (xscheme-send-control-u-interrupt) is like typing C-c C-u when running Scheme without Emacs. ** C-c C-b (xscheme-send-breakpoint-interrupt) is like typing C-c C-b when running Scheme without Emacs. ** C-c C-p (xscheme-send-proceed) is like evaluating (PROCEED). * Command-line Options Scheme accepts the following command-line options. The options may appear in any order, but they must all appear before any other arguments on the command line. (At present, any arguments other than these options will generate a warning message when Scheme starts. In the future, there will be an advertised mechanism by which the extra arguments can be handled by user code.) -band FILENAME Specifies the initial band to be loaded. Searches for FILENAME in the working directory and the library directories, using the full pathname of the first readable file of that name. If FILENAME is an absolute pathname (on unix, this means it starts with a "/"), then no search occurs -- FILENAME is tested for readability and then used directly. If this option isn't given, the filename is the value of the environment variable MITSCHEME_BAND, or if that isn't defined, "runtime.com"; in these cases the library directories are searched, but not the working directory. -compiler This option specifies defaults appropriate for loading the compiler. It specifies the use of large sizes, exactly like "-large". If the "-band" option is also specified, that is the only effect of this option. Otherwise, the default band's filename is the value of the environment variable MITSCHEME_COMPILER_BAND, if defined, or "compiler.com"; the library directories are searched in the usual way to locate this file. Note that the "-compiler" option is available only on machines with compiled-code support. -edwin This option specifies defaults appropriate for loading the editor. It specifies the use of large sizes, exactly like "-large". If the "-band" option is also specified, that is the only effect of this option. Otherwise, the default band's filename is the value of the environment variable MITSCHEME_EDWIN_BAND, if defined, or "edwin.com"; the library directories are searched in the usual way to locate this file. Note that the "-edwin" option is available only on machines with compiled-code support. -large Specifies that large heap, constant, and stack default sizes should be used. These are specified by the environment variables MITSCHEME_LARGE_HEAP, MITSCHEME_LARGE_CONSTANT, and MITSCHEME_LARGE_STACK. If this option isn't given, the small sizes are used, specified by the environment variables MITSCHEME_SMALL_HEAP, MITSCHEME_SMALL_CONSTANT, and MITSCHEME_SMALL_STACK. There are reasonable built-in defaults for all of these environment variables, should any of them be undefined. Note that any or all of the defaults can be individually overridden by the "-heap", "-constant", and "-stack" options. [Note: the Scheme procedure (PRINT-GC-STATISTICS) shows how much heap and constant space is available and in use.] -heap BLOCKS Specifies the size of the heap in 1024-word blocks. Overrides any default. Normally two such heaps are allocated; `bchscheme' allocates only one, and uses a disk file for the other. -constant BLOCKS Specifies the size of constant space in 1024-word blocks. Overrides any default. Constant space is holds the compiled code for the runtime system and other subsystems. -stack BLOCKS Specifies the size of the stack in 1024-word blocks. Overrides any default. This is Scheme's stack, NOT the unix stack used by C programs. -option-summary Causes Scheme to write an option summary to standard error. -emacs Specifies that Scheme is running as a subprocess of GNU Emacs. This option is automatically supplied by GNU Emacs, and should not be given under other circumstances. -interactive If this option isn't specified, and Scheme's standard I/O is not a terminal, Scheme will detach itself from its controlling terminal. This will prevent it from getting signals sent to the process group of that terminal. If this option is specified, Scheme will not detach itself from the controlling terminal. This detaching behavior is useful for running Scheme as a background job. For example, using the C shell in unix, the following will run Scheme as a background job, redirecting its input and output to files, and preventing it from being killed by keyboard interrupts or by logging out: scheme < /usr/cph/foo.in >& /usr/cph/foo.out & -nocore Specifies that Scheme should not generate a core dump under any circumstances. -gcfile FILENAME Specifies that FILENAME should be used for garbage collection. This option is recognized only by `bchscheme'. -library PATH Sets the library search path to PATH. This is a colon-separated list of directories that is searched to find various library files, such as bands. If this option is not given, the value of the environment variable MITSCHEME_LIBRARY_PATH is used; if that isn't defined, "/usr/local/lib/mit-scheme" is used. -utabmd FILENAME Specifies the name of the microcode tables file. The file is searched for in the working directory and the library directories. If this option isn't given, the filename is the value of the environment variable MITSCHEME_UTABMD_FILE, or if that isn't defined, "utabmd.bin"; in these cases the library directories are searched, but not the working directory. -utab FILENAME An alternate name for the "-utabmd" option. At most one of these options may be given. -fasl FILENAME Specifies that a cold load should be performed, using FILENAME as the initial file to be loaded. If this option isn't given, a normal load is performed instead. This option may not be used together with the "-band" option. This option is useful only for maintainance and development of the Scheme runtime system. Summary of environment variables: MITSCHEME_BAND (default: "runtime.com") The initial band to be loaded. Overridden by "-band", "-compiler", or "-edwin". MITSCHEME_COMPILER_BAND (default: "compiler.com") The initial band to be loaded if the "-compiler" option is given. Overridden by "-band". MITSCHEME_EDWIN_BAND (default: "edwin.com") The initial band to be loaded if the "-edwin" option is given. Overridden by "-band". MITSCHEME_LARGE_CONSTANT (default: 1000) The size of constant space, in 1024-word blocks, if the "-large", "-compiler", or "-edwin" options are given. Overridden by "-constant". [Note that the default for this option is somewhat larger on certain machines.] MITSCHEME_LARGE_HEAP (default: 1000) The size of the heap, in 1024-word blocks, if the "-large", "-compiler", or "-edwin" options are given. Overridden by "-heap". MITSCHEME_LARGE_STACK (default: 100) The size of the stack, in 1024-word blocks, if the "-large", "-compiler", or "-edwin" options are given. Overridden by "-stack". MITSCHEME_LIBRARY_PATH (default: "/usr/local/lib/mit-scheme") A colon-separated list of directories. These directories are searched, left to right, to find bands and various other files. MITSCHEME_SMALL_CONSTANT (default: 400) The size of constant space, in 1024-word blocks, if the options are not given. Overridden by "-constant", "-large", "-compiler", and "-edwin". [Note that the default for this option is somewhat larger on certain machines.] MITSCHEME_SMALL_HEAP (default: 250) The size of the heap, in 1024-word blocks, if the options are not given. Overridden by "-heap", "-large", "-compiler", and "-edwin". MITSCHEME_SMALL_STACK (default: 100) The size of the stack, in 1024-word blocks, if the options are not given. Overridden by "-stack", "-large", "-compiler", and "-edwin". MITSCHEME_UTABMD_FILE (default: "utabmd.bin") The file containing the microcode tables. Overridden by "-utabmd" and "-utab".