Beyond the &ANSI; Standard</> <para>Besides &ANSI;, we have other stuff..</para> <sect1 id="non-conformance"><title>Non-Conformance with the &ANSI; Standard</> <para> This section is essentially a placeholder. There is are important areas of non-conformance, like the difference between <function>sb-pcl:find-class</> and <function>cl:class</>, but progress is made and the list changes and I've tired of trying to keep the information here up to date. For information on the highlights, try the bugs sections of the Unix man page. For more detailed information, try the BUGS file in the system distribution. </para> </sect1> <sect1 id="idiosyncrasies"><title>Idiosyncrasies</> <para>Declarations are generally treated as assertions. This general principle, and its implications, and the bugs which still keep the compiler from quite satisfying this principle, are discussed in the <link linkend="compiler">chapter on the compiler</link>.</para> <para>&SBCL; is essentially a compiler-only implementation of &CommonLisp;. That is, for all but a few special cases, <function>eval</> creates a lambda expression, calls <function>compile</> on the lambda expression to create a compiled function, and then calls <function>funcall</> on the resulting function object. This is explicitly allowed by the &ANSI; standard, but leads to some oddities, e.g. collapsing <function>functionp</> and <function>compiled-function-p</> into the same predicate. </para> </sect1> <sect1 id="extensions"><title>Extensions</> <para>&SBCL; is derived from &CMUCL;, which implements many extensions to the &ANSI; standard. &SBCL; doesn't support as many extensions as &CMUCL;, but it still has quite a few.</para> <sect2><title>Things Which Might Be in the Next &ANSI; Standard</> <para>&SBCL; provides extensive support for calling external C code, described <link linkend="ffi">in its own chapter</link>.</para> <para>&SBCL; provides additional garbage collection functionality not specified by &ANSI;. Weak pointers allow references to objects to be maintained without keeping them from being GCed. And "finalization" hooks are available to cause code to be executed when an object is GCed.</para>  <para>&SBCL; supports Gray streams, user-overloadable CLOS classes whose instances can be used as Lisp streams (e.g. passed as the first argument to <function>format</>).</para> </sect2> <sect2><title>Support for Unix</> <para>The UNIX command line can be read from the variable <varname>sb-ext:*posix-argv*</>. The UNIX environment can be queried with the <function>sb-ext:posix-getenv</> function.</para> <para>The &SBCL; system can be terminated with <function>sb-ext:quit</>, optionally returning a specified numeric value to the calling Unix process. The normal Unix idiom of terminating on end of file on input is also supported.</para> </sect2> <sect2><title>Tools to Help Developers

Beyond the &ANSI; Standard</> <para>Besides &ANSI;, we have other stuff..</para> <sect1 id="non-conformance"><title>Non-Conformance with the &ANSI; Standard</> <para> This section is essentially a placeholder. There is are important areas of non-conformance, like the difference between <function>sb-pcl:find-class</> and <function>cl:class</>, but progress is made and the list changes and I've tired of trying to keep the information here up to date. For information on the highlights, try the bugs sections of the Unix man page. For more detailed information, try the BUGS file in the system distribution. </para> </sect1> <sect1 id="idiosyncrasies"><title>Idiosyncrasies</> <para>Declarations are generally treated as assertions. This general principle, and its implications, and the bugs which still keep the compiler from quite satisfying this principle, are discussed in the <link linkend="compiler">chapter on the compiler</link>.</para> <para>&SBCL; is essentially a compiler-only implementation of &CommonLisp;. That is, for all but a few special cases, <function>eval</> creates a lambda expression, calls <function>compile</> on the lambda expression to create a compiled function, and then calls <function>funcall</> on the resulting function object. This is explicitly allowed by the &ANSI; standard, but leads to some oddities, e.g. collapsing <function>functionp</> and <function>compiled-function-p</> into the same predicate. </para> </sect1> <sect1 id="extensions"><title>Extensions</> <para>&SBCL; is derived from &CMUCL;, which implements many extensions to the &ANSI; standard. &SBCL; doesn't support as many extensions as &CMUCL;, but it still has quite a few.</para> <sect2><title>Things Which Might Be in the Next &ANSI; Standard</> <para>&SBCL; provides extensive support for calling external C code, described <link linkend="ffi">in its own chapter</link>.</para> <para>&SBCL; provides additional garbage collection functionality not specified by &ANSI;. Weak pointers allow references to objects to be maintained without keeping them from being GCed. And "finalization" hooks are available to cause code to be executed when an object is GCed.</para>  <para>&SBCL; supports Gray streams, user-overloadable CLOS classes whose instances can be used as Lisp streams (e.g. passed as the first argument to <function>format</>).</para> </sect2> <sect2><title>Support for Unix</> <para>The UNIX command line can be read from the variable <varname>sb-ext:*posix-argv*</>. The UNIX environment can be queried with the <function>sb-ext:posix-getenv</> function.</para> <para>The &SBCL; system can be terminated with <function>sb-ext:quit</>, optionally returning a specified numeric value to the calling Unix process. The normal Unix idiom of terminating on end of file on input is also supported.</para> </sect2> <sect2><title>Tools to Help Developers &SBCL; provides a profiler and other extensions to the &ANSI; trace facility. See the online function documentation for trace for more information. The debugger supports a number of options. Its documentation is accessed by typing help at the debugger prompt. Documentation for inspect is accessed by typing help at the inspect prompt. Interface to Low-Level &SBCL; Implementation &SBCL; has the ability to save its state as a file for later execution. This functionality is important for its bootstrapping process, and is also provided as an extension to the user See the documentation for sb-ext:save-lisp-and-die for more information. &SBCL; has inherited from &CMUCL; various hooks to allow the user to tweak and monitor the garbage collection process. These are somewhat stale code, and their interface might need to be cleaned up. If you have urgent need of them, look at the code in src/code/gc.lisp and bring it up on the developers' mailing list. &SBCL; has various hooks inherited from &CMUCL;, like sb-ext:float-denormalized-p, to allow a program to take advantage of &IEEE; floating point arithmetic properties which aren't conveniently or efficiently expressible using the &ANSI; standard. These look good, and their interface looks good, but &IEEE; support is slightly broken due to a stupid decision to remove some support for infinities (because it wasn't in the &ANSI; spec and it didn't occur to me that it was in the &IEEE; spec). If you need this stuff, take a look at the ecode and bring it up on the developers' mailing list. Efficiency Hacks The sb-ext:purify function causes &SBCL; first to collect all garbage, then to mark all uncollected objects as permanent, never again attempting to collect them as garbage. (This can cause a large increase in efficiency when using a primitive garbage collector, but is less important with modern generational garbage collectors.) The sb-ext:truly-the operator does what the cl:the operator does in a more conventional implementation of &CommonLisp;, declaring the type of its argument without any runtime checks. (Ordinarily in &SBCL;, any type declaration is treated as an assertion and checked at runtime.) The sb-ext:freeze-type declaration declares that a type will never change, which can make type testing (typep, etc.) more efficient for structure types. The sb-ext:constant-function declaration specifies that a function will always return the same value for the same arguments. This is appropriate for functions like sqrt. It is not appropriate for functions like aref, which can change their return values when the underlying data are changed.