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