0.9.4.56:
[sbcl.git] / doc / manual / beyond-ansi.texinfo
1 @node  Beyond the ANSI Standard
2 @comment  node-name,  next,  previous,  up
3 @chapter Beyond the ANSI Standard
4
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}.
8
9 @menu
10 * Garbage Collection::          
11 * Metaobject Protocol::         
12 * Support For Unix::            
13 * Customization Hooks for Users::  
14 * Tools To Help Developers::    
15 * Resolution of Name Conflicts::  
16 * Stale Extensions::            
17 * Efficiency Hacks::            
18 @end menu
19
20 @node  Garbage Collection
21 @comment  node-name,  next,  previous,  up
22 @section Garbage Collection
23
24 SBCL provides additional garbage collection functionality not
25 specified by ANSI. Weak pointers allow references to objects to be
26 maintained without keeping them from being garbage collected, and
27 ``finalization'' hooks are available to cause code to be executed when
28 an object has been garbage collected. Additionally users can specify
29 their own cleanup actions to be executed with garbage collection.
30
31 @include fun-sb-ext-finalize.texinfo
32 @include fun-sb-ext-cancel-finalization.texinfo
33 @include fun-sb-ext-make-weak-pointer.texinfo
34 @include fun-sb-ext-weak-pointer-value.texinfo
35 @include var-sb-ext-star-after-gc-hooks-star.texinfo
36
37 @node Metaobject Protocol
38 @comment  node-name,  next,  previous,  up
39 @section Metaobject Protocol
40
41 SBCL supports a metaobject protocol which is intended to be compatible
42 with AMOP; present exceptions to this (as distinct from current bugs)
43 are:
44
45 @itemize
46   
47 @item
48 @tindex metaobject
49 the abstract @code{metaobject} class is not present in the class
50 hierarchy;
51   
52 @item
53 @findex compute-effective-method
54 @findex sb-mop:compute-effective-method
55 @code{compute-effective-method} only returns one value, not two;
56   
57 @item
58 @findex compute-slots
59 @findex sb-mop:compute-slots
60 @tindex funcallable-standard-class 
61 @tindex sb-mop:funcallable-standard-class 
62 the system-supplied @code{:around} method for @code{compute-slots}
63 specialized on @code{funcallable-standard-class} does not respect the
64 requested order from a user-supplied primary method.
65
66 @item
67 @findex ensure-generic-function
68 @findex generic-function-declarations
69 @findex sb-mop:generic-function-declarations
70 the arguments @code{:declare} and @code{:declarations} to
71 @code{ensure-generic-function} are both accepted, with the leftmost
72 argument defining the declarations to be stored and returned by
73 @code{generic-function-declarations}.
74
75 @item
76 @findex validate-superclass
77 @findex finalize-inheritance
78 @findex sb-mop:validate-superclass
79 @findex sb-mop:finalize-inheritance
80 @tindex standard-class
81 @tindex funcallable-standard-class
82 @tindex sb-mop:funcallable-standard-class
83 although we obey the requirement in AMOP for @code{validate-superclass}
84 for @code{standard-class} and @code{funcallable-standard-class} to be
85 compatible metaclasses, we impose an additional requirement at class
86 finalization time: a class of metaclass
87 @code{funcallable-standard-class} must have @code{function} in its
88 superclasses, and a class of metaclass @code{standard-class} must not.
89
90 @end itemize
91
92 @node  Support For Unix
93 @comment  node-name,  next,  previous,  up
94 @section Support For Unix
95
96 The UNIX command line can be read from the variable
97 @code{sb-ext:*posix-argv*}. The UNIX environment can be queried with
98 the @code{sb-ext:posix-getenv} function.
99
100 @include fun-sb-ext-posix-getenv.texinfo
101
102
103 @node  Customization Hooks for Users
104 @comment  node-name,  next,  previous,  up
105 @section Customization Hooks for Users
106
107 The toplevel repl prompt may be customized, and the function
108 that reads user input may be replaced completely.
109 @c <!-- FIXME but I don't currently remember how -->
110
111 The behaviour of @code{require} when called with only one argument is
112 implementation-defined.  In SBCL, @code{require} behaves in the
113 following way:
114
115 @include fun-common-lisp-require.texinfo
116 @include var-sb-ext-star-module-provider-functions-star.texinfo
117
118 Although SBCL does not provide a resident editor, the @code{ed}
119 function can be customized to hook into user-provided editing
120 mechanisms as follows:
121
122 @include fun-common-lisp-ed.texinfo
123 @include var-sb-ext-star-ed-functions-star.texinfo
124
125 @node Tools To Help Developers
126 @comment  node-name,  next,  previous,  up
127 @section Tools To Help Developers
128
129 SBCL provides a profiler and other extensions to the ANSI @code{trace}
130 facility.  For more information, see @ref{Macro common-lisp:trace}.
131
132 The debugger supports a number of options. Its documentation is
133 accessed by typing @kbd{help} at the debugger prompt. @xref{Debugger}.
134
135 Documentation for @code{inspect} is accessed by typing @kbd{help} at
136 the @code{inspect} prompt.
137
138 @node Resolution of Name Conflicts
139 @section Resolution of Name Conflicts
140
141 The ANSI standard (section 11.1.1.2.5) requires that name conflicts in
142 packages be resolvable in favour of any of the conflicting symbols.  In
143 the interactive debugger, this is achieved by prompting for the symbol
144 in whose favour the conflict should be resolved; for programmatic use,
145 the @code{sb-ext:resolve-conflict} restart should be invoked with one
146 argument, which should be a member of the list returned by the condition
147 accessor @code{sb-ext:name-conflict-symbols}.
148
149 @node Stale Extensions
150 @comment  node-name,  next,  previous,  up
151 @section Stale Extensions
152
153 SBCL has inherited from CMUCL various hooks to allow the user to
154 tweak and monitor the garbage collection process. These are somewhat
155 stale code, and their interface might need to be cleaned up. If you
156 have urgent need of them, look at the code in @file{src/code/gc.lisp}
157 and bring it up on the developers' mailing list.
158
159 SBCL has various hooks inherited from CMUCL, like
160 @code{sb-ext:float-denormalized-p}, to allow a program to take
161 advantage of IEEE floating point arithmetic properties which aren't
162 conveniently or efficiently expressible using the ANSI standard. These
163 look good, and their interface looks good, but IEEE support is
164 slightly broken due to a stupid decision to remove some support for
165 infinities (because it wasn't in the ANSI spec and it didn't occur to
166 me that it was in the IEEE spec). If you need this stuff, take a look
167 at the code and bring it up on the developers' mailing
168 list.
169
170
171 @node  Efficiency Hacks
172 @comment  node-name,  next,  previous,  up
173 @section Efficiency Hacks
174
175 The @code{sb-ext:purify} function causes SBCL first to collect all
176 garbage, then to mark all uncollected objects as permanent, never again
177 attempting to collect them as garbage. This can cause a large increase
178 in efficiency when using a primitive garbage collector, or a more
179 moderate increase in efficiency when using a more sophisticated garbage
180 collector which is well suited to the program's memory usage pattern. It
181 also allows permanent code to be frozen at fixed addresses, a
182 precondition for using copy-on-write to share code between multiple Lisp
183 processes.  This is less important with modern generational garbage
184 collectors, but not all SBCL platforms use such a garbage collector.
185
186 @include fun-sb-ext-purify.texinfo
187
188 The @code{sb-ext:truly-the} special form declares the type of the
189 result of the operations, producing its argument; the declaration is
190 not checked. In short: don't use it.
191
192 @include special-operator-sb-ext-truly-the.texinfo
193
194 The @code{sb-ext:freeze-type} declaration declares that a
195 type will never change, which can make type testing
196 (@code{typep}, etc.) more efficient for structure types.
197
198 The @code{sb-ext:constant-function} declaration specifies
199 that a function will always return the same value for the same
200 arguments, which may allow the compiler to optimize calls
201 to it. This is appropriate for functions like @code{sqrt}, but
202 is @emph{not} appropriate for functions like @code{aref},
203 which can change their return values when the underlying data are
204 changed.
205 @c <!-- FIXME: This declaration does not seem to be supported in the 
206 @c      current compiler. -->