Next: Tools To Help Developers, Previous: Support For Unix, Up: Beyond the ANSI Standard

### 7.4 Customization Hooks for Users

The toplevel repl prompt may be customized, and the function that reads user input may be replaced completely.

The behaviour of `require` when called with only one argument is implementation-defined. In SBCL, `require` behaves in the following way:

— Function: cl:require module-name &optional pathnames

> Loads a module, unless it already has been loaded. `pathnames`, if supplied, is a designator for a list of pathnames to be loaded if the module needs to be. If `pathnames` is not supplied, functions from the list `*module-provider-functions*` are called in order with `module-name` as an argument, until one of them returns non-NIL. User code is responsible for calling `provide` to indicate a successful load of the module.

— Variable: sb-ext:*module-provider-functions*

> See function documentation for `require`.

Although SBCL does not provide a resident editor, the `ed` function can be customized to hook into user-provided editing mechanisms as follows:

— Function: cl:ed &optional x

> Starts the editor (on a file or a function if named). Functions from the list `*ed-functions*` are called in order with `x` as an argument until one of them returns non-NIL; these functions are responsible for signalling a `file-error` to indicate failure to perform an operation on the file system.

— Variable: sb-ext:*ed-functions*

> See function documentation for `ed`.

Conditions of type `warning` and `style-warning` are sometimes signaled at runtime, especially during execution of Common Lisp defining forms such as `defun`, `defmethod`, etc. To muffle these warnings at runtime, SBCL provides a variable `sb-ext:*muffled-warnings*`:

— Variable: sb-ext:*muffled-warnings*

> A type that ought to specify a subtype of `warning`. Whenever a warning is signaled, if the warning if of this type and is not handled by any other handler, it will be muffled.