Beyond the ANSI Standard
************************

SBCL is derived from CMUCL, which implements many extensions to the ANSI standard. SBCL doesn't support as many extensions as CMUCL, but it still has quite a few.  See Contributed Modules.

Garbage Collection
==================

SBCL provides additional garbage collection functionality not specified by ANSI. Weak pointers allow references to objects to be maintained without keeping them from being garbage collected, and ``finalization'' hooks are available to cause code to be executed when an object has been garbage collected. Additionally users can specify their own cleanup actions to be executed with garbage collection.

     [file fun-sb-ext-finalize.texinfo not included]
     [file fun-sb-ext-cancel-finalization.texinfo not included]
     [file fun-sb-ext-make-weak-pointer.texinfo not included]
     [file fun-sb-ext-weak-pointer-value.texinfo not included]
     [file var-sb-ext-star-after-gc-hooks-star.texinfo not included]

Metaobject Protocol
===================

SBCL supports a metaobject protocol which is intended to be compatible with AMOP; present exceptions to this (as distinct from current bugs) are:

  * the abstract metaobject class is not present in the class hierarchy;

  * the standard-object and funcallable-standard-object classes are disjoint;

  * compute-effective-method only returns one value, not two;

  * the system-supplied :around method for compute-slots specialized on funcallable-standard-class does not respect the requested order from a user-supplied primary method.

Support For Unix
================

The UNIX command line can be read from the variable sb-ext:*posix-argv*. The UNIX environment can be queried with the sb-ext:posix-getenv function.

     [file fun-sb-ext-posix-getenv.texinfo not included]

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:

     [file fun-common-lisp-require.texinfo not included]
     [file var-sb-ext-star-module-provider-functions-star.texinfo not included]

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

     [file fun-common-lisp-ed.texinfo not included]
     [file var-sb-ext-star-ed-functions-star.texinfo not included]

Tools To Help Developers
========================

SBCL provides a profiler and other extensions to the ANSI trace facility.  For more information, see Macro common-lisp:trace.

The debugger supports a number of options. Its documentation is accessed by typing help at the debugger prompt. See Debugger.

Documentation for inspect is accessed by typing help at the inspect prompt.

Resolution of Name Conflicts
============================

The ANSI standard (section 11.1.1.2.5) requires that name conflicts in packages be resolvable in favour of any of the conflicting symbols.  In the interactive debugger, this is achieved by prompting for the symbol in whose favour the conflict should be resolved; for programmatic use, the sb-ext:resolve-conflict restart should be invoked with one argument, which should be a member of the list returned by the condition accessor sb-ext:name-conflict-symbols.

Stale Extensions
================

SBCL has inherited from CMUCL various hooks to allow the user to tweak and monitor the garbage collection process. These are somewhat stale code, and their interface might need to be cleaned up. If you have urgent need of them, look at the code in src/code/gc.lisp and bring it up on the developers' mailing list.

SBCL has various hooks inherited from CMUCL, like sb-ext:float-denormalized-p, to allow a program to take advantage of IEEE floating point arithmetic properties which aren't conveniently or efficiently expressible using the ANSI standard. These look good, and their interface looks good, but IEEE support is slightly broken due to a stupid decision to remove some support for infinities (because it wasn't in the ANSI spec and it didn't occur to me that it was in the IEEE spec). If you need this stuff, take a look at the code and bring it up on the developers' mailing list.

Efficiency Hacks
================

The sb-ext:purify function causes SBCL first to collect all garbage, then to mark all uncollected objects as permanent, never again attempting to collect them as garbage. This can cause a large increase in efficiency when using a primitive garbage collector, or a more moderate increase in efficiency when using a more sophisticated garbage collector which is well suited to the program's memory usage pattern. It also allows permanent code to be frozen at fixed addresses, a precondition for using copy-on-write to share code between multiple Lisp processes.  This is less important with modern generational garbage collectors, but not all SBCL platforms use such a garbage collector.

     [file fun-sb-ext-purify.texinfo not included]

The sb-ext:truly-the special form declares the type of the result of the operations, producing its argument; the declaration is not checked. In short: don't use it.

     [file special-operator-sb-ext-truly-the.texinfo not included]

The sb-ext:freeze-type declaration declares that a type will never change, which can make type testing (typep, etc.) more efficient for structure types.

The sb-ext:constant-function declaration specifies that a function will always return the same value for the same arguments, which may allow the compiler to optimize calls to it. This is appropriate for functions like sqrt, but is not appropriate for functions like aref, which can change their return values when the underlying data are changed.