1 @node Beyond the ANSI Standard
2 @comment node-name, next, previous, up
3 @chapter Beyond the ANSI Standard
5 SBCL is derived from CMUCL, which implements many extensions to the
6 ANSI standard. SBCL doesn't support as many extensions as CMUCL, but
7 it still has quite a few. @xref{Contributed Modules}.
10 * Things Which Might Be In The Next ANSI Standard::
12 * Customization Hooks for Users::
13 * Tools To Help Developers::
14 * Interface To Low-Level SBCL Implementation::
19 @node Things Which Might Be In The Next ANSI Standard
20 @comment node-name, next, previous, up
21 @section Things Which Might Be In The Next ANSI Standard
23 SBCL provides extensive support for calling external C code,
24 @ref{Foreign Function Interface}.
26 SBCL provides additional garbage collection functionality not
27 specified by ANSI. Weak pointers allow references to objects to be
28 maintained without keeping them from being GCed (garbage
29 collected). And ``finalization'' hooks are available to cause code to
30 be executed when an object has been GCed.
31 @c <!-- FIXME: Actually documenting these would be good.:-| -->
33 SBCL supports @dfn{Gray streams}, user-overloadable CLOS classes whose
34 instances can be used as Lisp streams (e.g. passed as the first
35 argument to @code{format}). Additionally, the bundled contrib module
36 @dfn{sb-simple-streams} implements a subset of the Franz Allegro
37 simple-streams proposal.
39 SBCL supports a MetaObject Protocol which is intended to be compatible
40 with AMOP; present exceptions to this (as distinct from current bugs)
46 the abstract @code{metaobject} class is not present in the class
50 the @code{standard-object} and @code{funcallable-standard-object}
54 @code{compute-effective-method} only returns one value, not two;
57 the system-supplied @code{:around} method for @code{compute-slots}
58 specialized on @code{funcallable-standard-class} does not respect the
59 requested order from a user-supplied primary method.
63 @node Support For Unix
64 @comment node-name, next, previous, up
65 @section Support For Unix
67 The UNIX command line can be read from the variable
68 @code{sb-ext:*posix-argv*}. The UNIX environment can be queried with
69 the @code{sb-ext:posix-getenv} function.
71 @include fun-sb-ext-posix-getenv.texinfo
74 @node Customization Hooks for Users
75 @comment node-name, next, previous, up
76 @section Customization Hooks for Users
78 The toplevel repl prompt may be customized, and the function
79 that reads user input may be replaced completely.
80 @c <!-- FIXME but I don't currently remember how -->
82 The behaviour of @code{require} when called with only one argument is
83 implementation-defined. In SBCL, @code{require} behaves in the
86 @include fun-common-lisp-require.texinfo
87 @include var-sb-ext-star-module-provider-functions-star.texinfo
89 Although SBCL does not provide a resident editor, the @code{ed}
90 function can be customized to hook into user-provided editing
91 mechanisms as follows:
93 @include fun-common-lisp-ed.texinfo
94 @include var-sb-ext-star-ed-functions-star.texinfo
96 @node Tools To Help Developers
97 @comment node-name, next, previous, up
98 @section Tools To Help Developers
100 SBCL provides a profiler and other extensions to the ANSI @code{trace}
101 facility. For more information, see @ref{macro-common-lisp-trace}.
103 The debugger supports a number of options. Its documentation is
104 accessed by typing @kbd{help} at the debugger prompt. @xref{Debugger}.
106 Documentation for @code{inspect} is accessed by typing @kbd{help} at
107 the @code{inspect} prompt.
109 @node Interface To Low-Level SBCL Implementation
110 @comment node-name, next, previous, up
111 @section Interface To Low-Level SBCL Implementation
113 SBCL has the ability to save its state as a file for later
114 execution. This functionality is important for its bootstrapping
115 process, and is also provided as an extension to the user. Note that
116 foreign libraries loaded via @code{load-shared-object} don't survive
117 this process; a core should not be saved in this case.
119 @emph{FIXME: what should be done for foreign libraries?}
121 @emph{FIXME: document load-shared-object somewhere - it's in
124 @include fun-sb-ext-save-lisp-and-die.texinfo
127 @node Stale Extensions
128 @comment node-name, next, previous, up
129 @section Stale Extensions
131 SBCL has inherited from CMUCL various hooks to allow the user to
132 tweak and monitor the garbage collection process. These are somewhat
133 stale code, and their interface might need to be cleaned up. If you
134 have urgent need of them, look at the code in @file{src/code/gc.lisp}
135 and bring it up on the developers' mailing list.
137 SBCL has various hooks inherited from CMUCL, like
138 @code{sb-ext:float-denormalized-p}, to allow a program to take
139 advantage of IEEE floating point arithmetic properties which aren't
140 conveniently or efficiently expressible using the ANSI standard. These
141 look good, and their interface looks good, but IEEE support is
142 slightly broken due to a stupid decision to remove some support for
143 infinities (because it wasn't in the ANSI spec and it didn't occur to
144 me that it was in the IEEE spec). If you need this stuff, take a look
145 at the code and bring it up on the developers' mailing
149 @node Efficiency Hacks
150 @comment node-name, next, previous, up
151 @section Efficiency Hacks
153 The @code{sb-ext:purify} function causes SBCL first to collect all
154 garbage, then to mark all uncollected objects as permanent, never
155 again attempting to collect them as garbage. This can cause a large
156 increase in efficiency when using a primitive garbage collector, or a
157 more moderate increase in efficiency when using a more sophisticated
158 garbage collector which is well suited to the program's memory usage
159 pattern. It also allows permanent code to be frozen at fixed
160 addresses, a precondition for using copy-on-write to share code
161 between multiple Lisp processes. it is less important with modern
162 generational garbage collectors.
164 @include fun-sb-ext-purify.texinfo
166 The @code{sb-ext:truly-the} special form declares the type of the
167 result of the operations, producing its argument; the declaration is
168 not checked. In short: don't use it.
170 @include special-operator-sb-ext-truly-the.texinfo
172 The @code{sb-ext:freeze-type} declaration declares that a
173 type will never change, which can make type testing
174 (@code{typep}, etc.) more efficient for structure types.
176 The @code{sb-ext:constant-function} declaration specifies
177 that a function will always return the same value for the same
178 arguments, which may allow the compiler to optimize calls
179 to it. This is appropriate for functions like @code{sqrt}, but
180 is @emph{not} appropriate for functions like @code{aref},
181 which can change their return values when the underlying data are
183 @c <!-- FIXME: This declaration does not seem to be supported in the
184 @c current compiler. -->