Next: , 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.