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 * Things Which Might Be In The Next ANSI Standard::
  11 * Support For Unix::
  12 * Customization Hooks for Users::
  13 * Tools To Help Developers::
  14 * Stale Extensions::
  15 * Efficiency Hacks::
  16 @end menu
  17
  18 @node  Things Which Might Be In The Next ANSI Standard
  19 @comment  node-name,  next,  previous,  up
  20 @section Things Which Might Be In The Next ANSI Standard
  21
  22 SBCL provides extensive support for calling external C code,
  23 @ref{Foreign Function Interface}.
  24
  25 SBCL provides additional garbage collection functionality not
  26 specified by ANSI. Weak pointers allow references to objects to be
  27 maintained without keeping them from being GCed (garbage
  28 collected). And ``finalization'' hooks are available to cause code to
  29 be executed when an object has been GCed.
  30 @c <!-- FIXME: Actually documenting these would be good.:-| -->
  31
  32 SBCL supports @dfn{Gray streams}, user-overloadable CLOS classes whose
  33 instances can be used as Lisp streams (e.g. passed as the first
  34 argument to @code{format}).  Additionally, the bundled contrib module
  35 @dfn{sb-simple-streams} implements a subset of the Franz Allegro
  36 simple-streams proposal.
  37
  38 SBCL supports a MetaObject Protocol which is intended to be compatible
  39 with AMOP; present exceptions to this (as distinct from current bugs)
  40 are:
  41
  42 @itemize
  43
  44 @item
  45 the abstract @code{metaobject} class is not present in the class
  46 hierarchy;
  47
  48 @item
  49 the @code{standard-object} and @code{funcallable-standard-object}
  50 classes are disjoint;
  51
  52 @item
  53 @code{compute-effective-method} only returns one value, not two;
  54
  55 @item
  56 the system-supplied @code{:around} method for @code{compute-slots}
  57 specialized on @code{funcallable-standard-class} does not respect the
  58 requested order from a user-supplied primary method.
  59
  60 @end itemize
  61
  62 @node  Support For Unix
  63 @comment  node-name,  next,  previous,  up
  64 @section Support For Unix
  65
  66 The UNIX command line can be read from the variable
  67 @code{sb-ext:*posix-argv*}. The UNIX environment can be queried with
  68 the @code{sb-ext:posix-getenv} function.
  69
  70 @include fun-sb-ext-posix-getenv.texinfo
  71
  72
  73 @node  Customization Hooks for Users
  74 @comment  node-name,  next,  previous,  up
  75 @section Customization Hooks for Users
  76
  77 The toplevel repl prompt may be customized, and the function
  78 that reads user input may be replaced completely.
  79 @c <!-- FIXME but I don't currently remember how -->
  80
  81 The behaviour of @code{require} when called with only one argument is
  82 implementation-defined.  In SBCL, @code{require} behaves in the
  83 following way:
  84
  85 @include fun-common-lisp-require.texinfo
  86 @include var-sb-ext-star-module-provider-functions-star.texinfo
  87
  88 Although SBCL does not provide a resident editor, the @code{ed}
  89 function can be customized to hook into user-provided editing
  90 mechanisms as follows:
  91
  92 @include fun-common-lisp-ed.texinfo
  93 @include var-sb-ext-star-ed-functions-star.texinfo
  94
  95 @node  Tools To Help Developers
  96 @comment  node-name,  next,  previous,  up
  97 @section Tools To Help Developers
  98
  99 SBCL provides a profiler and other extensions to the ANSI @code{trace}
 100 facility.  For more information, see @ref{Macro common-lisp:trace}.
 101
 102 The debugger supports a number of options. Its documentation is
 103 accessed by typing @kbd{help} at the debugger prompt. @xref{Debugger}.
 104
 105 Documentation for @code{inspect} is accessed by typing @kbd{help} at
 106 the @code{inspect} prompt.
 107
 108 @node Stale Extensions
 109 @comment  node-name,  next,  previous,  up
 110 @section Stale Extensions
 111
 112 SBCL has inherited from CMUCL various hooks to allow the user to
 113 tweak and monitor the garbage collection process. These are somewhat
 114 stale code, and their interface might need to be cleaned up. If you
 115 have urgent need of them, look at the code in @file{src/code/gc.lisp}
 116 and bring it up on the developers' mailing list.
 117
 118 SBCL has various hooks inherited from CMUCL, like
 119 @code{sb-ext:float-denormalized-p}, to allow a program to take
 120 advantage of IEEE floating point arithmetic properties which aren't
 121 conveniently or efficiently expressible using the ANSI standard. These
 122 look good, and their interface looks good, but IEEE support is
 123 slightly broken due to a stupid decision to remove some support for
 124 infinities (because it wasn't in the ANSI spec and it didn't occur to
 125 me that it was in the IEEE spec). If you need this stuff, take a look
 126 at the code and bring it up on the developers' mailing
 127 list.
 128
 129
 130 @node  Efficiency Hacks
 131 @comment  node-name,  next,  previous,  up
 132 @section Efficiency Hacks
 133
 134 The @code{sb-ext:purify} function causes SBCL first to collect all
 135 garbage, then to mark all uncollected objects as permanent, never
 136 again attempting to collect them as garbage. This can cause a large
 137 increase in efficiency when using a primitive garbage collector, or a
 138 more moderate increase in efficiency when using a more sophisticated
 139 garbage collector which is well suited to the program's memory usage
 140 pattern. It also allows permanent code to be frozen at fixed
 141 addresses, a precondition for using copy-on-write to share code
 142 between multiple Lisp processes. it is less important with modern
 143 generational garbage collectors.
 144
 145 @include fun-sb-ext-purify.texinfo
 146
 147 The @code{sb-ext:truly-the} special form declares the type of the
 148 result of the operations, producing its argument; the declaration is
 149 not checked. In short: don't use it.
 150
 151 @include special-operator-sb-ext-truly-the.texinfo
 152
 153 The @code{sb-ext:freeze-type} declaration declares that a
 154 type will never change, which can make type testing
 155 (@code{typep}, etc.) more efficient for structure types.
 156
 157 The @code{sb-ext:constant-function} declaration specifies
 158 that a function will always return the same value for the same
 159 arguments, which may allow the compiler to optimize calls
 160 to it. This is appropriate for functions like @code{sqrt}, but
 161 is @emph{not} appropriate for functions like @code{aref},
 162 which can change their return values when the underlying data are
 163 changed.
 164 @c <!-- FIXME: This declaration does not seem to be supported in the
 165 @c      current compiler. -->