package local nicknames
[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 * Reader Extensions::           
11 * Package-Local Nicknames::     
12 * Garbage Collection::          
13 * Metaobject Protocol::         
14 * Support For Unix::            
15 * Customization Hooks for Users::  
16 * Tools To Help Developers::    
17 * Resolution of Name Conflicts::  
18 * Hash Table Extensions::       
19 * Random Number Generation::    
20 * Miscellaneous Extensions::    
21 * Stale Extensions::            
22 * Efficiency Hacks::            
23 @end menu
24
25 @node Reader Extensions
26 @comment  node-name,  next,  previous,  up
27 @section Reader Extensions
28 @cindex Reader Extensions
29
30 SBCL supports extended package prefix syntax, which allows specifying
31 an alternate package instead of @code{*package*} for the reader to use
32 as the default package for interning symbols:
33
34 @lisp
35 <package-name>::<form-with-interning-into-package>
36 @end lisp
37
38 Example:
39
40 @lisp
41   'foo::(bar quux zot) == '(foo::bar foo::quux foo::zot)
42 @end lisp
43
44 Doesn't alter @code{*package*}: if @code{foo::bar} would cause a
45 read-time package lock violation, so does @code{foo::(bar)}.
46
47 @node  Package-Local Nicknames
48 @comment  node-name,  next,  previous,  up
49 @section Package-Local Nicknames
50 @cindex Package-Local Nicknames
51
52 SBCL allows giving packages local nicknames: they allow short and
53 easy-to-use names to be used without fear of name conflict associated
54 with normal nicknames.
55
56 A local nickname is valid only when inside the package for which it
57 has been specified. Different packages can use same local nickname for
58 different global names, or different local nickname for same global
59 name.
60
61 @findex @cl{defpackage}
62 @defmac @cl{defpackage} name [[option]]* @result{} package
63
64 Options are extended to include
65
66 @itemize
67 @item
68 @code{:local-nicknames} @var{(local-nickname actual-package-name)}*
69
70 The package has the specified local nicknames for the corresponding
71 actual packages.
72 @end itemize
73
74 Example:
75
76 @lisp
77 (defpackage :bar (:intern "X"))
78 (defpackage :foo (:intern "X"))
79 (defpackage :quux (:use :cl) (:local-nicknames (:bar :foo) (:foo :bar)))
80 (find-symbol "X" :foo) ; => FOO::X
81 (find-symbol "X" :bar) ; => BAR::X
82 (let ((*package* (find-package :quux)))
83   (find-symbol "X" :foo))               ; => BAR::X
84 (let ((*package* (find-package :quux)))
85   (find-symbol "X" :bar))               ; => FOO::X
86 @end lisp
87 @end defmac
88
89 @include fun-sb-ext-package-local-nicknames.texinfo
90 @include fun-sb-ext-package-locally-nicknamed-by.texinfo
91 @include fun-sb-ext-add-package-local-nickname.texinfo
92 @include fun-sb-ext-remove-package-local-nickname.texinfo
93
94 @node  Garbage Collection
95 @comment  node-name,  next,  previous,  up
96 @section Garbage Collection
97 @cindex Garbage collection
98
99 SBCL provides additional garbage collection functionality not
100 specified by ANSI.
101
102 @include var-sb-ext-star-after-gc-hooks-star.texinfo
103 @include fun-sb-ext-gc.texinfo
104
105 @subsection Finalization
106 @cindex Finalization
107
108 Finalization allows code to be executed after an object has been
109 garbage collected. This is useful for example for releasing foreign
110 memory associated with a Lisp object.
111
112 @include fun-sb-ext-finalize.texinfo
113 @include fun-sb-ext-cancel-finalization.texinfo
114
115 @subsection Weak Pointers
116 @cindex Weak pointers
117
118 Weak pointers allow references to objects to be maintained without
119 keeping them from being garbage collected: useful for building caches
120 among other things.
121
122 Hash tables can also have weak keys and values: @pxref{Hash Table
123 Extensions}.
124
125 @include fun-sb-ext-make-weak-pointer.texinfo
126 @include fun-sb-ext-weak-pointer-value.texinfo
127
128 @subsection Introspection and Tuning
129
130 @include var-sb-ext-star-gc-run-time-star.texinfo
131 @include fun-sb-ext-bytes-consed-between-gcs.texinfo
132 @include fun-sb-ext-dynamic-space-size.texinfo
133 @include fun-sb-ext-get-bytes-consed.texinfo
134 @include fun-sb-ext-gc-logfile.texinfo
135 @include fun-sb-ext-generation-average-age.texinfo
136 @include fun-sb-ext-generation-bytes-allocated.texinfo
137 @include fun-sb-ext-generation-bytes-consed-between-gcs.texinfo
138 @include fun-sb-ext-generation-minimum-age-before-gc.texinfo
139 @include fun-sb-ext-generation-number-of-gcs-before-promotion.texinfo
140 @include fun-sb-ext-generation-number-of-gcs.texinfo
141
142 @node Metaobject Protocol
143 @comment  node-name,  next,  previous,  up
144 @section Metaobject Protocol
145
146 @subsection AMOP Compatibility of Metaobject Protocol
147
148 SBCL supports a metaobject protocol which is intended to be compatible
149 with AMOP; present exceptions to this (as distinct from current bugs)
150 are:
151
152 @itemize
153
154 @item
155 @findex @sbmop{compute-effective-method}
156 @code{compute-effective-method} only returns one value, not two.
157
158 There is no record of what the second return value was meant to
159 indicate, and apparently no clients for it.
160
161 @item
162 @tindex @cl{generic-function}
163 @tindex @cl{standard-generic-function}
164 @tindex @sbmop{funcallable-standard-object}
165 @tindex @cl{standard-object}
166 @tindex @cl{function}
167 The direct superclasses of @code{sb-mop:funcallable-standard-object} are
168 @code{(function standard-object)}, not @code{(standard-object function)}.
169
170 This is to ensure that the @code{standard-object} class is the last of
171 the standardized classes before @code{t} appearing in the class
172 precedence list of @code{generic-function} and
173 @code{standard-generic-function}, as required by section 1.4.4.5 of the
174 ANSI specification.
175
176 @item
177 @findex @cl{ensure-generic-function}
178 @findex @sbmop{generic-function-declarations}
179 the arguments @code{:declare} and @code{:declarations} to
180 @code{ensure-generic-function} are both accepted, with the leftmost
181 argument defining the declarations to be stored and returned by
182 @code{generic-function-declarations}.
183
184 Where AMOP specifies @code{:declarations} as the keyword argument to
185 @code{ensure-generic-function}, the Common Lisp standard specifies
186 @code{:declare}.  Portable code should use @code{:declare}.
187
188 @item
189 @findex @sbmop{validate-superclass}
190 @findex @sbmop{finalize-inheritance}
191 @tindex @cl{standard-class}
192 @tindex @sbmop{funcallable-standard-class}
193 @tindex @cl{function}
194 @findex @sbmop{class-prototype}
195 although SBCL obeys the requirement in AMOP that
196 @code{validate-superclass} should treat @code{standard-class} and
197 @code{funcallable-standard-class} as compatible metaclasses, we
198 impose an additional requirement at class finalization time: a class
199 of metaclass @code{funcallable-standard-class} must have
200 @code{function} in its superclasses, and a class of metaclass
201 @code{standard-class} must not.
202
203 @findex @cl{typep}
204 @findex @cl{class-of}
205 @findex @cl{subtypep}
206 After a class has been finalized, it is associated with a class
207 prototype which is accessible by a standard mop function
208 @code{sb-mop:class-prototype}.  The user can then ask whether this
209 object is a @code{function} or not in several different ways: whether it
210 is a function according to @code{typep}; whether its @code{class-of} is
211 @code{subtypep} @code{function}, or whether @code{function} appears in
212 the superclasses of the class.  The additional consistency requirement
213 comes from the desire to make all of these answers the same.
214
215 The following class definitions are bad, and will lead to errors
216 either immediately or if an instance is created:
217 @lisp
218 (defclass bad-object (funcallable-standard-object)
219   ()
220   (:metaclass standard-class))
221 @end lisp
222 @lisp
223 (defclass bad-funcallable-object (standard-object)
224   ()
225   (:metaclass funcallable-standard-class))
226 @end lisp
227 The following definition is acceptable:
228 @lisp
229 (defclass mixin ()
230   ((slot :initarg slot)))
231 (defclass funcallable-object (funcallable-standard-object mixin)
232   ()
233   (:metaclass funcallable-standard-class))
234 @end lisp
235 and leads to a class whose instances are funcallable and have one slot.
236
237 @tindex @sbmop{funcallable-standard-object}
238 Note that this requirement also applies to the class
239 @code{sb-mop:funcallable-standard-object}, which has metaclass
240 @code{sb-mop:funcallable-standard-class} rather than
241 @code{standard-class} as AMOP specifies.
242
243 @item
244 the requirement that ``No portable class @math{C_p} may inherit, by
245 virtue of being a direct or indirect subclass of a specified class, any
246 slot for which the name is a symbol accessible in the
247 @code{common-lisp-user} package or exported by any package defined in
248 the ANSI Common Lisp standard.'' is interpreted to mean that the
249 standardized classes themselves should not have slots named by external
250 symbols of public packages.
251
252 The rationale behind the restriction is likely to be similar to the ANSI
253 Common Lisp restriction on defining functions, variables and types named
254 by symbols in the Common Lisp package: preventing two independent pieces
255 of software from colliding with each other.
256
257 @item
258 @findex @sbmop{slot-value-using-class}
259 @findex @setf{@sbmop{slot-value-using-class}}
260 @findex @sbmop{slot-boundp-using-class}
261 specializations of the @code{new-value} argument to @code{(setf
262 sb-mop:slot-value-using-class)} are not allowed: all user-defined
263 methods must have a specializer of the class @code{t}.
264
265 This prohibition is motivated by a separation of layers: the
266 @code{slot-value-using-class} family of functions is intended for use in
267 implementing different and new slot allocation strategies, rather than
268 in performing application-level dispatching.  Additionally, with this
269 requirement, there is a one-to-one mapping between metaclass, class and
270 slot-definition-class tuples and effective methods of @code{(setf
271 slot-value-using-class)}, which permits optimization of @code{(setf
272 slot-value-using-class)}'s discriminating function in the same manner as
273 for @code{slot-value-using-class} and @code{slot-boundp-using-class}.
274
275 Note that application code may specialize on the @code{new-value}
276 argument of slot accessors.
277
278 @item
279 @findex @cl{defclass}
280 @findex @sbmop{ensure-class}
281 @findex @sbmop{ensure-class-using-class}
282 @findex @cl{find-class}
283 @findex @cl{class-name}
284 the class named by the @code{name} argument to @code{ensure-class}, if
285 any, is only redefined if it is the proper name of that class;
286 otherwise, a new class is created.
287
288 This is consistent with the description of @code{ensure-class} in AMOP
289 as the functional version of @code{defclass}, which has this behaviour;
290 however, it is not consistent with the weaker requirement in AMOP, which
291 states that any class found by @code{find-class}, no matter what its
292 @code{class-name}, is redefined.
293
294 @end itemize
295
296 @subsection Metaobject Protocol Extensions
297
298 In addition, SBCL supports extensions to the Metaobject protocol from
299 AMOP; at present, they are:
300
301 @itemize
302
303 @item
304 @findex @cl{defmethod}
305 @findex @cl{find-class}
306 @findex @sbmop{intern-eql-specializer}
307 @findex @sbpcl{make-method-specializers-form}
308 @findex @sbmop{make-method-lambda}
309 compile-time support for generating specializer metaobjects from
310 specializer names in @code{defmethod} forms is provided by the
311 @code{make-method-specializers-form} function, which returns a form
312 which, when evaluated in the lexical environment of the
313 @code{defmethod}, returns a list of specializer metaobjects.  This
314 operator suffers from similar restrictions to those affecting
315 @code{make-method-lambda}, namely that the generic function must be
316 defined when the @code{defmethod} form is expanded, so that the
317 correct method of @code{make-method-specializers-form} is invoked.
318 The system-provided method on @code{make-method-specializers-form}
319 generates a call to @code{find-class} for each symbol specializer
320 name, and a call to @code{intern-eql-specializer} for each @code{(eql
321 @var{x})} specializer name.
322
323 @item
324 @findex @cl{find-method}
325 @findex @sbpcl{parse-specializer-using-class}
326 @findex @sbpcl{unparse-specializer-using-class}
327 run-time support for converting between specializer names and
328 specializer metaobjects, mostly for the purposes of
329 @code{find-method}, is provided by
330 @code{parse-specializer-using-class} and
331 @code{unparse-specializer-using-class}, which dispatch on their first
332 argument, the generic function associated with a method with the given
333 specializer.  The system-provided methods on those methods convert
334 between classes and proper names and between lists of the form
335 @code{(eql @var{x})} and interned eql specializer objects.
336
337 @item
338 @vindex @sbpcl{+slot-unbound+}
339 @findex @sbmop{standard-instance-access}
340 @findex @sbmop{funcallable-standard-instance-access}
341 distinguishing unbound instance allocated slots from bound ones when
342 using @code{standard-instance-access} and
343 @code{funcallable-standard-instance-access} is possible by comparison
344 to the constant @code{+slot-unbound+}.
345
346 @end itemize
347
348 @node  Support For Unix
349 @comment  node-name,  next,  previous,  up
350 @section Support For Unix
351
352 @menu
353 * Command-line arguments::      
354 * Querying the process environment::  
355 * Running external programs::   
356 @end menu
357
358 @node Command-line arguments
359 @subsection Command-line arguments
360 @vindex @sbext{@earmuffs{posix-argv}}
361
362 The UNIX command line can be read from the variable
363 @code{sb-ext:*posix-argv*}.
364
365 @node Querying the process environment
366 @subsection Querying the process environment
367
368 The UNIX environment can be queried with the
369 @code{sb-ext:posix-getenv} function.
370
371 @include fun-sb-ext-posix-getenv.texinfo
372
373 @node Running external programs
374 @subsection Running external programs
375
376 External programs can be run with @code{sb-ext:run-program}.
377 @footnote{In SBCL versions prior to 1.0.13, @code{sb-ext:run-program}
378 searched for executables in a manner somewhat incompatible with other
379 languages.  As of this version, SBCL uses the system library routine
380 @code{execvp(3)}, and no longer contains the function,
381 @code{find-executable-in-search-path}, which implemented the old
382 search.  Users who need this function may find it
383 in @file{run-program.lisp} versions 1.67 and earlier in SBCL's CVS
384 repository here
385 @url{http://sbcl.cvs.sourceforge.net/sbcl/sbcl/src/code/run-program.lisp?view=log}. However,
386 we caution such users that this search routine finds executables that
387 system library routines do not.}
388
389 @include fun-sb-ext-run-program.texinfo
390
391 When @code{sb-ext:run-program} is called with @code{wait} equal to
392 NIL, an instance of class @var{sb-ext:process} is returned.  The
393 following functions are available for use with processes:
394
395 @include fun-sb-ext-process-p.texinfo
396
397 @include fun-sb-ext-process-input.texinfo
398
399 @include fun-sb-ext-process-output.texinfo
400
401 @include fun-sb-ext-process-error.texinfo
402
403 @include fun-sb-ext-process-alive-p.texinfo
404
405 @include fun-sb-ext-process-status.texinfo
406
407 @include fun-sb-ext-process-wait.texinfo
408
409 @include fun-sb-ext-process-exit-code.texinfo
410
411 @include fun-sb-ext-process-core-dumped.texinfo
412
413 @include fun-sb-ext-process-close.texinfo
414
415 @include fun-sb-ext-process-kill.texinfo
416
417 @node  Customization Hooks for Users
418 @comment  node-name,  next,  previous,  up
419 @section Customization Hooks for Users
420
421 The toplevel repl prompt may be customized, and the function
422 that reads user input may be replaced completely.
423 @c <!-- FIXME but I don't currently remember how -->
424
425 The behaviour of @code{require} when called with only one argument is
426 implementation-defined.  In SBCL, @code{require} behaves in the
427 following way:
428
429 @include fun-common-lisp-require.texinfo
430 @include var-sb-ext-star-module-provider-functions-star.texinfo
431
432 Although SBCL does not provide a resident editor, the @code{ed}
433 function can be customized to hook into user-provided editing
434 mechanisms as follows:
435
436 @include fun-common-lisp-ed.texinfo
437 @include var-sb-ext-star-ed-functions-star.texinfo
438
439 Conditions of type @code{warning} and @code{style-warning} are
440 sometimes signaled at runtime, especially during execution of Common
441 Lisp defining forms such as @code{defun}, @code{defmethod}, etc.  To
442 muffle these warnings at runtime, SBCL provides a variable
443 @code{sb-ext:*muffled-warnings*}:
444
445 @include var-sb-ext-star-muffled-warnings-star.texinfo
446
447 @node Tools To Help Developers
448 @comment  node-name,  next,  previous,  up
449 @section Tools To Help Developers
450 @findex @cl{trace}
451 @findex @cl{inspect}
452
453 SBCL provides a profiler and other extensions to the ANSI @code{trace}
454 facility.  For more information, see @ref{Macro common-lisp:trace}.
455
456 The debugger supports a number of options. Its documentation is
457 accessed by typing @kbd{help} at the debugger prompt. @xref{Debugger}.
458
459 Documentation for @code{inspect} is accessed by typing @kbd{help} at
460 the @code{inspect} prompt.
461
462 @node Resolution of Name Conflicts
463 @section Resolution of Name Conflicts
464 @tindex @sbext{name-conflict}
465 @findex @sbext{name-conflict-symbols}
466
467 The ANSI standard (section 11.1.1.2.5) requires that name conflicts in
468 packages be resolvable in favour of any of the conflicting symbols.  In
469 the interactive debugger, this is achieved by prompting for the symbol
470 in whose favour the conflict should be resolved; for programmatic use,
471 the @code{sb-ext:resolve-conflict} restart should be invoked with one
472 argument, which should be a member of the list returned by the condition
473 accessor @code{sb-ext:name-conflict-symbols}.
474
475 @node    Hash Table Extensions
476 @comment  node-name,  next,  previous,  up
477 @section Hash Table Extensions
478 @cindex Hash tables
479
480 Hash table extensions supported by SBCL are all controlled by keyword
481 arguments to @code{make-hash-table}.
482
483 @include fun-common-lisp-make-hash-table.texinfo
484
485 @include macro-sb-ext-define-hash-table-test.texinfo
486
487 @include macro-sb-ext-with-locked-hash-table.texinfo
488
489 @include fun-sb-ext-hash-table-synchronized-p.texinfo
490
491 @include fun-sb-ext-hash-table-weakness.texinfo
492
493 @node    Random Number Generation
494 @comment  node-name,  next,  previous,  up
495 @section Random Number Generation
496 @cindex Random Number Generation
497
498 The initial value of @code{*random-state*} is the same each time SBCL
499 is started. This makes it possible for user code to obtain repeatable
500 pseudo random numbers using only standard-provided functionality. See
501 @code{seed-random-state} below for an SBCL extension that allows to
502 seed the random number generator from given data for an additional
503 possibility to achieve this. Non-repeatable random numbers can always
504 be obtained using @code{(make-random-state t)}.
505
506 The sequence of numbers produced by repeated calls to @code{random}
507 starting with the same random state and using the same sequence of
508 @code{limit} arguments is guaranteed to be reproducible only in the
509 same version of SBCL on the same platform, using the same code under
510 the same evaluator mode and compiler optimization qualities. Just two
511 examples of differences that may occur otherwise: calls to
512 @code{random} can be compiled differently depending on how much is
513 known about the @code{limit} argument at compile time, yielding
514 different results even if called with the same argument at run time,
515 and the results can differ depending on the machine's word size, for
516 example for limits that are fixnums under 64-bit word size but bignums
517 under 32-bit word size.
518
519 @include fun-sb-ext-seed-random-state.texinfo
520
521 Some notes on random floats: The standard doesn't prescribe a specific
522 method of generating random floats. The following paragraph describes
523 SBCL's current implementation and should be taken purely informational,
524 that is, user code should not depend on any of its specific properties.
525 The method used has been chosen because it is common, conceptually
526 simple and fast.
527
528 To generate random floats, SBCL evaluates code that has an equivalent
529 effect as
530 @lisp
531 (* limit
532    (float (/ (random (expt 2 23)) (expt 2 23)) 1.0f0))
533 @end lisp
534 (for single-floats) and correspondingly (with @code{52} and
535 @code{1.0d0} instead of @code{23} and @code{1.0f0}) for double-floats.
536 Note especially that this means that zero is a possible return value
537 occurring with probability @code{(expt 2 -23)} respectively
538 @code{(expt 2 -52)}. Also note that there exist twice as many
539 equidistant floats between 0 and 1 as are generated. For example, the
540 largest number that @code{(random 1.0f0)} ever returns is
541 @code{(float (/ (1- (expt 2 23)) (expt 2 23)) 1.0f0)} while
542 @code{(float (/ (1- (expt 2 24)) (expt 2 24)) 1.0f0)} is the
543 largest single-float less than 1. This is a side effect of the fact
544 that the implementation uses the fastest possible conversion from bits
545 to floats.
546
547 SBCL currently uses the Mersenne Twister as its random number
548 generator, specifically the 32-bit version under both 32- and 64-bit
549 word size. The seeding algorithm has been improved several times by
550 the authors of the Mersenne Twister; SBCL uses the third version
551 (from 2002) which is still the most recent as of June 2012. The
552 implementation has been tested to provide output identical to the
553 recommended C implementation.
554
555 While the Mersenne Twister generates random numbers of much better
556 statistical quality than other widely used generators, it uses only
557 linear operations modulo 2 and thus fails some statistical
558 tests@footnote{See chapter 7 "Testing widely used RNGs" in
559 @cite{TestU01: A C Library for Empirical Testing of Random Number
560 Generators} by Pierre L'Ecuyer and Richard Simard, ACM Transactions on
561 Mathematical Software, Vol. 33, article 22, 2007.}.
562 For example, the distribution of ranks of (sufficiently large) random
563 binary matrices is much distorted compared to the theoretically
564 expected one when the matrices are generated by the Mersenne Twister.
565 Thus, applications that are sensitive to this aspect should use a
566 different type of generator.
567
568 @node    Miscellaneous Extensions
569 @comment  node-name,  next,  previous,  up
570 @section Miscellaneous Extensions
571
572 @include fun-sb-ext-array-storage-vector.texinfo
573 @include fun-sb-ext-delete-directory.texinfo
574 @include fun-sb-ext-get-time-of-day.texinfo
575 @include macro-sb-ext-wait-for.texinfo
576
577 @node Stale Extensions
578 @comment  node-name,  next,  previous,  up
579 @section Stale Extensions
580
581 SBCL has inherited from CMUCL various hooks to allow the user to
582 tweak and monitor the garbage collection process. These are somewhat
583 stale code, and their interface might need to be cleaned up. If you
584 have urgent need of them, look at the code in @file{src/code/gc.lisp}
585 and bring it up on the developers' mailing list.
586
587 SBCL has various hooks inherited from CMUCL, like
588 @code{sb-ext:float-denormalized-p}, to allow a program to take
589 advantage of IEEE floating point arithmetic properties which aren't
590 conveniently or efficiently expressible using the ANSI standard. These
591 look good, and their interface looks good, but IEEE support is
592 slightly broken due to a stupid decision to remove some support for
593 infinities (because it wasn't in the ANSI spec and it didn't occur to
594 me that it was in the IEEE spec). If you need this stuff, take a look
595 at the code and bring it up on the developers' mailing
596 list.
597
598
599 @node  Efficiency Hacks
600 @comment  node-name,  next,  previous,  up
601 @section Efficiency Hacks
602
603 The @code{sb-ext:purify} function causes SBCL first to collect all
604 garbage, then to mark all uncollected objects as permanent, never again
605 attempting to collect them as garbage. This can cause a large increase
606 in efficiency when using a primitive garbage collector, or a more
607 moderate increase in efficiency when using a more sophisticated garbage
608 collector which is well suited to the program's memory usage pattern. It
609 also allows permanent code to be frozen at fixed addresses, a
610 precondition for using copy-on-write to share code between multiple Lisp
611 processes.  This is less important with modern generational garbage
612 collectors, but not all SBCL platforms use such a garbage collector.
613
614 @include fun-sb-ext-purify.texinfo
615
616 The @code{sb-ext:truly-the} special form declares the type of the
617 result of the operations, producing its argument; the declaration is
618 not checked. In short: don't use it.
619
620 @include special-operator-sb-ext-truly-the.texinfo
621
622 The @code{sb-ext:freeze-type} declaration declares that a
623 type will never change, which can make type testing
624 (@code{typep}, etc.) more efficient for structure types.