X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=doc%2Fmanual%2Fintro.texinfo;h=f494e19f5df5cf1ff847bcb8d1a9975d673f70f0;hb=HEAD;hp=2795d9ac452b4f7f098da5b99220d43c5430dfbc;hpb=7ea27ded7ac98130c96beb6836d1259404e578d6;p=sbcl.git diff --git a/doc/manual/intro.texinfo b/doc/manual/intro.texinfo index 2795d9a..f494e19 100644 --- a/doc/manual/intro.texinfo +++ b/doc/manual/intro.texinfo @@ -8,13 +8,13 @@ not on behavior which is common to all implementations of ANSI Common Lisp. @menu -* ANSI Conformance:: -* Extensions:: -* Idiosyncrasies:: -* Development Tools:: -* More SBCL Information:: -* More Common Lisp Information:: -* History and Implementation of SBCL:: +* ANSI Conformance:: +* Extensions:: +* Idiosyncrasies:: +* Development Tools:: +* More SBCL Information:: +* More Common Lisp Information:: +* History and Implementation of SBCL:: @end menu @@ -24,16 +24,8 @@ Lisp. @section ANSI Conformance Essentially every type of non-conformance is considered a bug. (The -exceptions involve internal inconsistencies in the standard.) In SBCL -the master record of known bugs is in the @file{BUGS} file in the -distribution. - -The recommended way to report bugs is through the @cite{sbcl-help} or -@cite{sbcl-devel} mailing lists. For mailing list addresses, -see @ref{SBCL Homepage}; note that as a spam-reduction measure you -must subscribe before you can post. - - +exceptions involve internal inconsistencies in the standard.) +@xref{Reporting Bugs}. @node Extensions @comment node-name, next, previous, up @@ -73,6 +65,10 @@ non-blocking IO on multiple streams without using threads. @code{sb-mop} package provides a metaobject protocol for the Common Lisp Object System as described in @cite{Art of Metaobject Protocol}. +@item Extensible Sequences +SBCL allows users to define subclasses of the @code{sequence} +class. @xref{Extensible Sequences}. + @item Native Threads SBCL has native threads on x86/Linux, capable of taking advantage of SMP on multiprocessor machines. @xref{Threading}. @@ -83,7 +79,8 @@ both TCP and UDP sockets. @xref{Networking}. @item Introspective Facilities @code{sb-introspect} module offers numerous introspective extensions, -including access to function lambda-lists. +including access to function lambda-lists and a cross referencing +facility. @item Operating System Interface @code{sb-ext} contains a number of functions for running external @@ -104,8 +101,8 @@ streams} API proposed by Franz Inc. @xref{Simple Streams}. Profiler}. @code{sb-sprof} is a statistical profiler, capable of call-graph -generation and instruction level profiling. @xref{Statistical -Profiler}. +generation and instruction level profiling, which also supports +allocation profiling. @xref{Statistical Profiler}. @item Customization Hooks SBCL contains a number of extra-standard customization hooks that @@ -115,17 +112,13 @@ Hooks for Users}. @code{sb-aclrepl} provides an Allegro CL -style toplevel for SBCL, as an alternative to the classic CMUCL-style one. @xref{sb-aclrepl}. -@item CLTL2 Compatility Layer +@item CLTL2 Compatibility Layer @code{sb-cltl2} module provides @code{compiler-let} and environment access functionality described in @cite{Common Lisp The Language, 2nd Edition} which were removed from the language during the ANSI standardization process. -@item Executable Fasl Packaging -@code{sb-executable} can be used to concatenate multiple fasls into a -single executable (though the presence of an SBCL runtime and core image -is still required to run it). - +@item Executable Delivery The @code{:executable} argument to @ref{Function sb-ext:save-lisp-and-die} can produce a `standalone' executable containing both an image of the current Lisp session and an SBCL @@ -133,7 +126,7 @@ runtime. @item Bitwise Rotation @code{sb-rotate-byte} provides an efficient primitive for bitwise -rotation of integers, an operation required by eg. numerous +rotation of integers, an operation required by e.g. numerous cryptographic algorithms, but not available as a primitive in ANSI Common Lisp. @xref{sb-rotate-byte}. @@ -160,10 +153,11 @@ deals with choices that the ANSI standard leaves to the implementation. @menu -* Declarations:: -* Compiler-only Implementation:: -* Defining Constants:: -* Style Warnings:: +* Declarations:: +* FASL Format:: +* Compiler-only Implementation:: +* Defining Constants:: +* Style Warnings:: @end menu @node Declarations @@ -175,6 +169,35 @@ principle, and its implications, and the bugs which still keep the compiler from quite satisfying this principle, are discussed in @ref{Declarations as Assertions}. + +@node FASL Format +@comment node-name, next, previous, up +@subsection FASL Format + +SBCL fasl-format is binary compatible only with the exact SBCL version +it was generated with. While this is obviously suboptimal, it has +proven more robust than trying to maintain fasl compatibility across +versions: accidentally breaking things is far too easy, and can lead +to hard to diagnose bugs. + +The following snippet handles fasl recompilation automatically for +ASDF-based systems, and makes a good candidate for inclusion in +the user or system initialization file (@pxref{Initialization Files}.) + +@lisp +(require :asdf) + +;;; If a fasl was stale, try to recompile and load (once). +(defmethod asdf:perform :around ((o asdf:load-op) + (c asdf:cl-source-file)) + (handler-case (call-next-method o c) + ;; If a fasl was stale, try to recompile and load (once). + (sb-ext:invalid-fasl () + (asdf:perform (make-instance 'asdf:compile-op) c) + (call-next-method)))) +@end lisp + + @node Compiler-only Implementation @comment node-name, next, previous, up @subsection Compiler-only Implementation @@ -183,14 +206,17 @@ SBCL is essentially a compiler-only implementation of Common Lisp. That is, for all but a few special cases, @code{eval} creates a lambda expression, calls @code{compile} on the lambda expression to create a compiled function, and then calls @code{funcall} on the resulting -function object. This is explicitly allowed by the ANSI standard, but -leads to some oddities, e.g. collapsing @code{functionp} and -@code{compiled-function-p} into the same predicate. +function object. A more traditional interpreter is also available on +default builds; it is usually only called internally. This is +explicitly allowed by the ANSI standard, but leads to some oddities; +e.g. at default settings, @code{functionp} and +@code{compiled-function-p} are equivalent, and they collapse into the +same function when SBCL is built without the interpreter. @node Defining Constants @comment node-name, next, previous, up @subsection Defining Constants -@findex defconstant +@findex @cl{defconstant} SBCL is quite strict about ANSI's definition of @code{defconstant}. ANSI says that doing @code{defconstant} of the same symbol more than @@ -208,14 +234,14 @@ compiling and loading reasonable code like runs into this undefined behavior. Many implementations of Common Lisp try to help the programmer around this annoyance by silently accepting the undefined code and trying to do what the programmer probably -meant. +meant. SBCL instead treats the undefined behavior as an error. Often such code can be rewritten in portable ANSI Common Lisp which has the desired behavior. E.g., the code above can be given an exactly defined meaning by replacing @code{defconstant} either with @code{defparameter} or with a customized macro which does the right -thing, eg. +thing, e.g. @lisp (defmacro define-constant (name value &optional doc) `(defconstant ,name (if (boundp ',name) (symbol-value ',name) ,value) @@ -235,13 +261,13 @@ SBCL gives style warnings about various kinds of perfectly legal code, e.g. @itemize - + @item @code{defmethod} without a preceding @code{defgeneric}; - + @item multiple @code{defun}s of the same symbol in different units; - + @item special variables not named in the conventional @code{*foo*} style, and lexical variables unconventionally named in the @code{*foo*} style @@ -269,9 +295,9 @@ case, but still isn't as of SBCL 0.7.6.) @section Development Tools @menu -* Editor Integration:: -* Language Reference:: -* Generating Executables:: +* Editor Integration:: +* Language Reference:: +* Generating Executables:: @end menu @node Editor Integration @@ -288,7 +314,7 @@ Currently @dfn{SLIME}@footnote{Historically, the ILISP package at @uref{http://ilisp.cons.org/} provided similar functionality, but it does not support modern SBCL versions.} (Superior Lisp Interaction Mode for Emacs) together with Emacs is recommended for use with -SBCL, though other options exist as well. +SBCL, though other options exist as well. SLIME can be downloaded from @uref{http://www.common-lisp.net/project/slime/}. @@ -320,10 +346,10 @@ sb-ext:save-lisp-and-die}. @section More SBCL Information @menu -* SBCL Homepage:: -* Additional Distributed Documentation:: -* Online Documentation:: -* Internals Documentation:: +* SBCL Homepage:: +* Online Documentation:: +* Additional Documentation Files:: +* Internals Documentation:: @end menu @node SBCL Homepage @@ -334,22 +360,33 @@ The SBCL website at @uref{http://www.sbcl.org/} has some general information, plus links to mailing lists devoted to SBCL, and to archives of these mailing lists. Subscribing to the mailing lists @cite{sbcl-help} and @cite{sbcl-announce} is recommended: both are -fairly low-volume, and help you keep abrest with SBCL development. +fairly low-volume, and help you keep abreast with SBCL development. + +@node Online Documentation +@comment node-name, next, previous, up +@subsection Online Documentation + +Documentation for non-ANSI extensions for various commands is +available online from the SBCL executable itself. The extensions +for functions which have their own command prompts (e.g. the debugger, +and @code{inspect}) are documented in text available by typing +@command{help} at their command prompts. The extensions for functions +which don't have their own command prompt (such as @code{trace}) are +described in their documentation strings, unless your SBCL was +compiled with an option not to include documentation strings, in which +case the documentation strings are only readable in the source code. -@node Additional Distributed Documentation +@node Additional Documentation Files @comment node-name, next, previous, up -@subsection Additional Distributed Documentation +@subsection Additional Documentation Files Besides this user manual both SBCL source and binary distributions include some other SBCL-specific documentation files, which should be -installed along with this manual in on your system, eg. in +installed along with this manual on your system, e.g. in @file{/usr/local/share/doc/sbcl/}. @table @file -@item BUGS -Lists known bugs in the distribution. - @item COPYING Licence and copyright summary. @@ -364,25 +401,8 @@ information. @item NEWS Summarizes changes between various SBCL versions. -@item SUPPORT -Lists SBCL developers available for-pay development of SBCL. - @end table -@node Online Documentation -@comment node-name, next, previous, up -@subsection Online Documentation - -Documentation for non-ANSI extensions for various commands is -available online from the SBCL executable itself. The extensions -for functions which have their own command prompts (e.g. the debugger, -and @code{inspect}) are documented in text available by typing -@command{help} at their command prompts. The extensions for functions -which don't have their own command prompt (such as @code{trace}) are -described in their documentation strings, unless your SBCL was -compiled with an option not to include documentation strings, in which -case the documentation strings are only readable in the source code. - @node Internals Documentation @comment node-name, next, previous, up @subsection Internals Documentation @@ -404,9 +424,9 @@ it is not installed by default. @section More Common Lisp Information @menu -* Internet Community:: -* Third-party Libraries:: -* Common Lisp Books:: +* Internet Community:: +* Third-party Libraries:: +* Common Lisp Books:: @end menu @node Internet Community @@ -446,17 +466,15 @@ learn about Common Lisp, some books stand out: @table @cite -@c FIXME: Ask Seibel if he minds us referring to the preview -@c -@c @item Practical Common Lisp, by Peter Seibel -@c A forthcoming book from APress with a web free preview at -@c @uref{http://www.gigamonkeys.com/book/}. An excellent introduction to -@c the language, covering both the basics and ``advanced topics'' like -@c macros, CLOS, and packages. +@item Practical Common Lisp, by Peter Seibel +An excellent introduction to the language, covering both the basics +and ``advanced topics'' like macros, CLOS, and packages. Available +both in print format and on the web: @uref{http://www.gigamonkeys.com/book/}. -@item ANSI Common Lisp, by Paul Graham -Introduces most of the language, though some parts (eg. CLOS) are -covered only lightly. +@item Paradigms Of Artificial Intelligence Programming, by Peter Norvig +Good information on general Common Lisp programming, and many +nontrivial examples. Whether or not your work is AI, it's a very good +book to look at. @item On Lisp, by Paul Graham An in-depth treatment of macros, but not recommended as a first Common @@ -465,24 +483,19 @@ guard against non-standard usages, and since it doesn't really even try to cover the language as a whole, focusing solely on macros. Downloadable from @uref{http://www.paulgraham.com/onlisp.html}. -@item Paradigms Of Artificial Intelligence Programming, by Peter Norvig -Good information on general Common Lisp programming, and many -nontrivial examples. Whether or not your work is AI, it's a very good -book to look at. - @item Object-Oriented Programming In Common Lisp, by Sonya Keene -@c With the exception of @cite{Practical Common Lisp} -None the books above emphasize CLOS, but this one does. Even if you're -very knowledgeable about object oriented programming in the abstract, -it's worth looking at this book if you want to do any OO in Common -Lisp. Some abstractions in CLOS (especially multiple dispatch) go -beyond anything you'll see in most OO systems, and there are a number -of lesser differences as well. This book tends to help with the -culture shock. +With the exception of @cite{Practical Common Lisp} most introductory +books don't emphasize CLOS. This one does. Even if you're very +knowledgeable about object oriented programming in the abstract, it's +worth looking at this book if you want to do any OO in Common Lisp. +Some abstractions in CLOS (especially multiple dispatch) go beyond +anything you'll see in most OO systems, and there are a number of +lesser differences as well. This book tends to help with the culture +shock. @item Art Of Metaobject Programming, by Gregor Kiczales et al. -Currently to prime source of information on the Common Lisp Metaobject -Protocol, which is supported by SBCL. Section 2 (Chapers 5 and 6) are +Currently the prime source of information on the Common Lisp Metaobject +Protocol, which is supported by SBCL. Section 2 (Chapters 5 and 6) are freely available at @uref{http://www.lisp.org/mop/}. @end table @@ -494,7 +507,7 @@ freely available at @uref{http://www.lisp.org/mop/}. @comment node-name, next, previous, up @section History and Implementation of SBCL -You can work productively with SBCL without knowing anything +You can work productively with SBCL without knowing or understanding anything about where it came from, how it is implemented, or how it extends the ANSI Common Lisp standard. However, a little knowledge can be helpful in order to understand error @@ -544,13 +557,13 @@ can't be used interactively, and in fact the change is largely invisible to the casual user, since SBCL still can and does execute code interactively by compiling it on the fly. (It is visible if you know how to look, like using @code{compiled-function-p}; and it is visible in the -way that that SBCL doesn't have many bugs which behave differently in +way that SBCL doesn't have many bugs which behave differently in interpreted code than in compiled code.) What it means is that in SBCL, the @code{eval} function only truly ``interprets'' a few easy kinds of forms, such as symbols which are @code{boundp}. More complicated forms are evaluated by calling @code{compile} and then calling @code{funcall} on the returned result. - + The direct ancestor of SBCL is the x86 port of CMUCL. This port was in some ways the most cobbled-together of all the CMUCL ports, since a number of strange changes had to be made to support the register-poor @@ -592,7 +605,7 @@ Other major changes since the fork from CMUCL include SBCL has removed many CMUCL extensions, (e.g. IP networking, remote procedure call, Unix system interface, and X11 interface) from the core system. Most of these are available as contributed modules -(distributed with sbcl) or third-party modules instead. +(distributed with SBCL) or third-party modules instead. @item SBCL has deleted or deprecated some nonstandard features and code