fasl file version.
changes in sbcl-0.7.0 relative to sbcl-0.6.13:
-* major incompatible change: The default fasl file extension has changed
+* major incompatible change: The default fasl file extension, i.e. the
+ default extension for files produced by COMPILE-FILE, has changed
to ".fasl", for all architectures. (No longer ".x86f" and ".axpf".)
* compiler changes:
** There are many changes in the implementation of the compiler.
various related bugs (IR1-1, IR1-2, IR1-3, IR1-3a) have gone away.
Since the code is newer, there might still be some new bugs
(though not as many as before Martin Atzmueller's fixes:-). But
- hopefully any remaining bugs will be simpler, less fundamental,
- and more fixable then the bugs in the old IR1 interpreter code.
+ the new code is substantially simpler and clearer, and hopefully
+ any remaining bugs will be simpler, less fundamental, and more
+ fixable then the bugs in the old code.
** The revised compiler is still a little unsteady on its feet.
In particular,
*** The debugging information it produces (particularly the names
*** the function-of-all-trades COERCE
Mostly these should be transparent, but there's one
potentially-annoying problem (bug 117): when the compiler
- inline-expands a function and does type analysis on the
- result, it can find control paths which have type
- mismatches, and when it can't prove that they're not taken,
+ inline-expands a function and does type analysis on the result,
+ it can create control paths which have type mismatches, and
+ when it can't prove that those control paths aren't taken,
it will issue WARNINGs about the type mismatches. This is
a particular problem in practice for the new sequence functions.
- It's not clear how to make the compiler smart enough to fix
- this in general, but a workaround is given in the entry for
- 117 in the BUGS file.
+ It's not clear how this should be fixed, and for now, a
+ workaround is given in the entry for 117 in the BUGS file.
** (Because of the interaction between the two previous items --
- occasional inlining problems and new inline expansions -- the
- new sequence function optimizations won't really kick in
- properly until debugging information is straightened out in
- some future version.)
+ occasional inlining problems and new inline expansions -- some
+ of the new sequence function optimizations won't really kick in
+ completely until debugging information, and then inlining, are
+ straightened out in some future version.)
* minor incompatible changes:
** As part of a bug fix by Christophe Rhodes to DIRECTORY behavior,
DIRECTORY no longer implicitly promotes NIL slots of its
- pathname argument to :WILD. In particular, asking for the
- contents of a directory, which you used to be able
- to do without explicit wildcards, e.g. (DIRECTORY "/tmp/"),
- now needs explicit wildcards, e.g. (DIRECTORY "/tmp/*.*").
+ pathname argument to :WILD. In particular, when you ask for the
+ contents of a directory (which you used to be able to do without
+ explicit wildcards, e.g. (DIRECTORY "/tmp/")) you now need to use
+ explicit wildcards, e.g. (DIRECTORY "/tmp/*.*").
** changes in behavior that ANSI explicitly defines to be
implementation dependent:
*** The new compiler-only implementation still conforms with ANSI,
- but acts a little different. Besides the obvious changes in
- performance tradeoffs (that the cost per form passed to EVAL
- has gone up, and the cost per form executed by EVAL has gone
- down), the behavior of the system changes a little because
- there are no longer any interpreted function objects.
+ but acts a little different than before. Besides the obvious
+ changes in performance tradeoffs (that the cost per form passed
+ to EVAL has gone up, and the cost per form executed by EVAL
+ has gone down), the behavior of the system changes a little
+ because there are no longer any interpreted function objects.
COMPILED-FUNCTION-P is now synonymous with FUNCTIONP, and
e.g. doing COMPILE on the output of interactive DEFUN is
now a no-op.
4 million. (If your application spends a lot of time GCing and
you have a lot of RAM, you might want to experiment with
increasing it even more.)
- ** The debugger prompt sequence now goes "5]", "5[2]", "5[3]",
- etc. as you get deeper into recursive calls to the debugger
- command loop, instead of the old "5]", "5]]", "5]]]"
- sequence. (I was motivated to do this when squabbles between
- ILISP and SBCL left me very deeply nested in the debugger. In the
- short term, this change will probably provoke more ILISP/SBCL
- squabbles, but hopefully it will be an improvement in the long run.)
+ ** The SB-C-CALL package has been merged into the SB-ALIEN package.
+ However, almost all old code should still continue to work without
+ immediate update, as SB-C-CALL is now a (deprecated) nickname
+ for SB-ALIEN.
** Old operator names in the style DEF-FOO are now deprecated in
favor of new corresponding names DEFINE-FOO, for consistency with
the naming convention used in the ANSI standard (DEFSTRUCT, DEFVAR,
internal symbols, but a few supported extensions like
SB-ALIEN:DEF-ALIEN-FUNCTION are also affected. (So e.g.
DEF-ALIEN-FUNCTION becomes DEFINE-ALIEN-FUNCTION.)
- ** The SB-C-CALL package has been merged into the SB-ALIEN package.
- However, almost all old code should still continue to work without
- immediate update, as SB-C-CALL is now a (deprecated) nickname
- for SB-ALIEN.
+ ** The debugger prompt sequence now goes "5]", "5[2]", "5[3]",
+ etc. as you get deeper into recursive calls to the debugger
+ command loop, instead of the old "5]", "5]]", "5]]]"
+ sequence. (I was motivated to do this when squabbles between
+ ILISP and SBCL left me very deeply nested in the debugger. In the
+ short term, this change will probably provoke more ILISP/SBCL
+ squabbles, but hopefully it will be an improvement in the long run.)
** SB-ALIEN:DEFINE-ALIEN-FUNCTION (also known by the old deprecated
name DEF-ALIEN-FUNCTION) now does DECLAIM FTYPE for the defined
function, since declaiming return types involving aliens is
longer reexported by the SB-EXT package. They're solely useful
for alien code, so it seems more logical that you should get
them from the SB-ALIEN package, not in SB-EXT.
+ ** :SB-CONSTRAIN-FLOAT-TYPE, :SB-PROPAGATE-FLOAT-TYPE, and
+ :SB-PROPAGATE-FUN-TYPE are no longer considered to be optional
+ features. Instead, the code that they used to control is always
+ built into the system.
* many other bug fixes
** DEFSTRUCT and DEFCLASS have been substantially updated to take
advantage of the new EVAL-WHEN stuff and to clean them up in
Christophe Rhodes cleaned up the system self-test scripts (in tests/*),
contributed the optimization of FIND-IF-NOT and POSITION-IF-NOT, and
continues to work on the SPARC port (for those of you in a position
- to look down on our little "PC" machines).
+ to look down upon our little PC-compatible boxes from a great height).
** PPRINT-LOGICAL-BLOCK now copies the *PRINT-LINES* value on entry
and uses that copy, rather than the current dynamic value, when
- it's trying to decide whether to truncate output . Thus e.g.
+ it's trying to decide whether to truncate output. Thus e.g.
(let ((*print-lines* 50))
(pprint-logical-block (stream nil)
(dotimes (i 10)
(let ((*print-lines* 8))
(print (aref possiblybigthings i) stream)))))
- should truncate the logical block only at 50 lines, instead of
- often truncating it at 8 lines.
-* :SB-CONSTRAIN-FLOAT-TYPE, :SB-PROPAGATE-FLOAT-TYPE, and
- :SB-PROPAGATE-FUN-TYPE are no longer considered to be optional
- features. Instead, the code that they used to control is always
- built into the system.
+ should now truncate the logical block only at 50 lines, instead of
+ often truncating it at 8 lines, as it did before.
* The doc/cmucl/ directory, containing old CMU CL documentation
from the time of the fork, is no longer part of the base system.
SourceForge has shut down its anonymous FTP service, and with it
and UNTRACE. (This shouldn't matter, though, unless you are
using profiling. If you never profile anything, TRACE should
continue to behave as before.)
-?? Inlining can now be controlled the ANSI way, without
+* Inlining can now be controlled the ANSI way, without
MAYBE-INLINE, since the idiom
(DECLAIM (INLINE FOO))
(DEFUN FOO (..) ..)
-for 0.7.0:
-
-* filed off the roughest edges (or, perhaps, at least hammered down the
- protruding rusty nails and snipped off the trailing razor wire,
- leaving some filing for later:-) from the monster
- EVAL/EVAL-WHEN/%COMPILE/DEFUN/DEFSTRUCT cleanup:
-* more renaming (esp. for global as opposed to lexical names):
-* pending patches and bug reports that go in (or else get handled
- somehow, rejected/logged/whatever) before 0.7.0:
-=======================================================================
for early 0.7.x:
* patches postponed until after 0.7.0:
** used %COMPILE where COMPILE-TOP-LEVEL used to be used
** removed now-redundant COMPILE-TOP-LEVEL and
FUNCTIONAL-KIND=:TOP-LEVEL stuff from the compiler
- ** made FUNCTION-NAME logic work on closures, so that
+ ** (ideally, but perhaps too hard, given what I've discovered
+ about the godawful internals of function debug names):
+ made FUNCTION-NAME logic work on closures, so that
various public functions like CL:PACKAGEP which
are now implemented as closures (because
they're structure slot accessors) won't be so
** cut-and-pasted DEF-BOOLEAN-ATTRIBUTE (maybe easier to fix
now that EVAL-WHEN does what it should..)
** incomplete manual
- ** :IGNORE-ERRORS-P cruft in stems-and-flags.lisp-expr
+ ** :IGNORE-ERRORS-P cruft in stems-and-flags.lisp-expr. (It's
+ reasonable to support this as a crutch when initially
+ bootstrapping from balky xc hosts with their own
+ idiosyncratic ideas of what merits FAILURE-P, but it's
+ embarrassing to have to use it when bootstrapping
+ under SBCL!),
** weird double-loading (first in GENESIS, then in warm init)
of src/assembly/target/*.lisp stuff, and the associated
weirdness of the half-baked state (compiler almost but
to remove dead symbols
* made system handle stack overflow safely unless SAFETY is dominated
by SPEED or SPACE
-* Probably get rid of or at least rework the fdefinition/encapsulation
- system so that (SYMBOL-FUNCTION 'FOO) = (FDEFINITION 'FOO).
+* Either get rid of or at least rework the fdefinition/encapsulation
+ system so that (SYMBOL-FUNCTION 'FOO) is identically equal to
+ (FDEFINITION 'FOO).
=======================================================================
for 0.9:
acknowledge the connection: steel and banking are the industries where
Carnegie and Mellon made the big bucks.)
+.SH LICENSING
+
It is free software, mostly in the public domain, but with some
subsystems under BSD-style licenses which allow modification and
reuse as long as credit is given. It is provided "as is", with no
To run SBCL, type "sbcl" at the command line with no arguments. (SBCL
understands command line arguments, but you probably won't need to use
-them unless you're a fairly advanced user, in which case you should
+them unless you're a fairly advanced user. If you are, you should
read the COMMAND LINE SYNTAX section, below.) You should see some
startup messages, then a prompt ("*"). Type a Lisp expression at the
-prompt, and SBCL will read it, execute it, print the result,
+prompt, and SBCL will read it, execute it, print any values returned,
give you another prompt, and wait for your next input. E.g.
+
* (+ 1 2 3)
+
6
+ * (funcall (lambda (x y) (list x y y)) :toy :choo)
+
+ (:TOY :CHOO :CHOO)
+ * "Hello World"
+
+ "Hello World"
*
Many people like to run SBCL, like other Lisp systems, as a subprocess
.SH OVERVIEW
-SBCL aims for but has not reached ANSI compliance.
-
-SBCL compiles Common Lisp to native code, and is essentially a
-"compiler-only" implementation of the ANSI standard. (Unlike earlier
-versions of SBCL, byte compilation is no longer supported, and there
-is only a vestigial interpreter. Thus, in particular,
-COMPILED-FUNCTION-P is always equal to FUNCTIONP.)
-
-SBCL uses a generational conservative garbage collector for some ports,
-and a simple stop-and-copy garbage collector for other ports.
-
-SBCL also includes some non-ANSI extensions, notably
- * Lispy extensions:
- ** CMU-CL-style safe implementation of type declarations:
- "Declarations are assertions."
- ** source level debugger
- ** profiler
- ** saving the state of the running SBCL process, producing a
- "core" file which can be restarted later
- ** Gray streams (overloadable CLOS classes whose instances can
- be used wherever ANSI streams can be used)
- ** weak pointers and finalization (which have unfortunately
- suffered from at least some code rot, e.g. weak hash tables
- don't work)
- * system interface extensions:
- ** calling out to C code (a.k.a. FFI, foreign function interface)
- ** some simple support for operations with a "scripting language"
- flavor, e.g. reading POSIX argc and argv, or executing a
- subprogram
+SBCL compiles Common Lisp to native code. (Even today, some 30 years
+after the MacLisp compiler, people will tell you that Lisp is an
+interpreted language. Ignore them.)
+
+SBCL aims for but has not yet reached compliance with the ANSI
+standard for Common Lisp. More information on this is available in the
+BUGS section below.
+
+SBCL also includes various non-ANSI extensions.
+
+Many Lispy extensions have been retained from CMU CL:
+.TP 3
+\--
+CMU-CL-style safe implementation of type declarations:
+"Declarations are assertions."
+.TP 3
+\--
+the source level debugger (very similar to CMU CL's)
+.TP 3
+\--
+the profiler (now somewhat different from CMU CL's)
+.TP 3
+\--
+saving the state of the running SBCL process, producing a
+"core" file which can be restarted later
+.TP 3
+\--
+Gray streams (a de-facto standard system of overloadable CLOS classes
+whose instances can be used wherever ordinary ANSI streams can be used)
+.TP 3
+\--
+weak pointers and finalization (which have unfortunately
+suffered from at least some code rot, so that e.g. weak hash
+tables don't work)
+.PP
+
+Fundamental system interface extensions are also provided:
+.TP 3
+\--
+calling out to C code (a.k.a. FFI, foreign function interface,
+with very nearly the same interface as CMU CL)
+.TP 3
+\--
+some simple support for operations with a "scripting language"
+flavor, e.g. reading POSIX argc and argv, or executing a
+subprogram
+.PP
.SH DIFFERENCES FROM CMU CL
SBCL can be built from scratch using a plain vanilla ANSI Common Lisp
system and a C compiler, and all of its properties are specified by
-the version of the source code that it was created from. (This clean
+the version of the source code that it was created from. This clean
bootstrappability was the immediate motivation for forking off of the
-CMU CL development tree.) A variety of internal implementation
-differences are motivated by this.
+CMU CL development tree. A variety of implementation differences are
+motivated by this design goal.
-Maintenance work in SBCL since the fork has diverged in various
-details from the maintenance work in CMU CL. E.g. as of 2001-04-12,
-SBCL was more ANSI-compliant than CMU CL in various details such as
-support for PRINT-OBJECT and DESCRIBE-OBJECT, and SBCL's compiler was
-substantially better than CMU CL's at optimizing operations on
-non-simple vectors.
+Maintenance work in SBCL since the fork has diverged somewhat from the
+maintenance work in CMU CL. Many but not all bug fixes and
+improvements have been shared between the two projects, and sometimes
+the two projects disagree about what would be an improvement.
Most extensions supported by CMU CL are not supported in SBCL,
including Motif support, the Hemlock editor, search paths, the
-low-level Unix interface, the WIRE protocol, multithreading support,
-various user-level macros and functions (e.g. LETF, ITERATE, MEMQ,
+low-level Unix interface, the WIRE protocol, multithreading, various
+user-level macros and functions (e.g. LETF, ITERATE, MEMQ,
REQUIRED-ARGUMENT), and many others.
SBCL has retained some extensions from parent CMU CL. Many of the
retained extensions are in these categories:
.TP 3
\--
-things which might be in the new ANSI spec, e.g. weak pointers,
-finalization, foreign function interface to C, and Gray streams
+things which might be in the new ANSI spec, e.g. safe type
+declarations, weak pointers, finalization, foreign function
+interface to C, and Gray streams
.TP 3
\--
things which are universally available in Unix scripting languages,
.TP 3
\--
hooks into the low level workings of the system which can be useful
-for debugging, e.g. a list of functions to be run whenever GC occurs,
-or parameters to modify compiler diagnostic output
+for debugging, e.g. requesting that a particular function be executed
+whenever GC occurs, or tuning compiler diagnostic output
.TP 3
\--
-unportable performance hacks, e.g. TRULY-THE, FREEZE-TYPE, and PURIFY
+unportable performance hacks, e.g. FREEZE-TYPE and PURIFY. For more
+information about these, look at the online documentation for symbols
+in the SB-EXT package, and look at the user manual.
.PP
-There are also a few retained extensions which don't fall into
-any particular category, e.g.
-.TP 3
-\--
-the ability to save running Lisp images as executable files
-.PP
+There are also a few retained extensions which don't fall into any
+particular category, e.g. the ability to save running Lisp images as
+executable files.
Some of the retained extensions have new names and/or different
options than their CMU CL counterparts. For example, the SBCL function
-which saves a Lisp image to disk and kills it is called
-SAVE-LISP-AND-DIE instead of SAVE-LISP, and it supports fewer keyword
-options than CMU CL's SAVE-LISP.
-
-(Why doesn't SBCL support more extensions? Why the hell did I (WHN)
-drop all those nice extensions from CMU CL when the code already
-exists? This is a frequently asked question on the mailing list. The
-answer is that they're hard to maintain, and I have enough on my hands
-already. Also, in the case of some big and unquestionably useful
-extensions, like sockets and Motif, I think that SBCL has done its job
-by supplying the FFI, and that people who need, and understand, and
-are motivated to maintain the functionality should supply it as a
-separate library, which I'd be happy to distribute or link to on the
-SBCL home page. Finally, in the case of multithreading, I do think it
-belongs in the new ANSI spec, and it'd be a good feature to have, but
-I didn't think the CMU CL implementation was sufficiently mature, and
-it's such a complicated and far-reaching extension that I thought that
-trying to fix it would interfere with the more urgent task of getting
-basic ANSI support up to speed.)
+which saves a Lisp image to disk and kills the running process is
+called SAVE-LISP-AND-DIE instead of SAVE-LISP, and SBCL's
+SAVE-LISP-AND-DIE supports fewer keyword options than CMU CL's
+SAVE-LISP does.
+
+(Why doesn't SBCL support more extensions? Why drop all those nice
+extensions from CMU CL when the code already exists? This is a
+frequently asked question on the mailing list. In other cases, it's a
+design philosophy issue: arguably SBCL has done its job by supplying a
+stable FFI, and the right design decision is to move functionality
+derived from that, like socket support, into separate libraries,
+distributed as separate software packages by separate maintainers. In
+other cases it's a practical decision, hoping that focusing on a
+smaller number of things will let us do a better job on them. This is
+very much the case for multithreading: it's an important, valuable
+extension, but it's not easy to get right, and especially while SBCL
+is still working on basic ANSI compliance, difficult extensions aren't
+likely to be a priority.)
.SH THE COMPILER
-As noted above, SBCL is essentially a compiler-only implementation of
-Lisp, with all nontrivial code being implemented by compilation, even
-when you type it interactively at the "interpreter" prompt.
+SBCL is essentially a compiler-only implementation of Lisp. All
+nontrivial Lisp code is compiled to native machine code before being
+executed, even when the Lisp code is typed interactively at the
+"interpreter" prompt.
SBCL inherits from CMU CL the "Python" native code compiler. (Though
-we've essentially dropped the name to avoid confusion with the
-scripting language also called Python.) This compiler is very clever
-about understanding the type system of Common Lisp and using it to
-optimize code, and about producing notes to let the user know when the
-compiler doesn't have enough type information to produce efficient
+we've essentially dropped that name in order to avoid confusion with
+the scripting language also called Python.) This compiler is very
+clever about understanding the type system of Common Lisp and using it
+to optimize code, and about producing notes to let the user know when
+the compiler doesn't have enough type information to produce efficient
code. It also tries (almost always successfully) to follow the unusual
but very useful principle that "declarations are assertions", i.e.
type declarations should be checked at runtime unless the user
small constant factors. However, even on the X86 it tends to be faster
than byte interpreted languages (and can be a lot faster).
+The compiled code uses garbage collection to automatically
+manage memory. The garbage collector implementation varies considerably
+from CPU to CPU. In particular, on some CPUs the GC is nearly exact,
+while on others it's more conservative, and on some CPUs the GC
+is generational, while on others simpler stop and copy strategies
+are used.
+
For more information about the compiler, see the user manual.
.SH DOCUMENTATION
"CONSTANT-ARG"
;; various internal defaults
- "*DEFAULT-PACKAGE-USE-LIST*"
"DEFAULT-INIT-CHAR" "*DEFAULT-INIT-CHAR-FORM*"
"*LOAD-SOURCE-DEFAULT-TYPE*"
(in-package "SB!IMPL")
+;;; the list of packages to use by default when no :USE argument is
+;;; supplied to MAKE-PACKAGE or other package creation forms
+;;;
+;;; ANSI specifies (1) that MAKE-PACKAGE and DEFPACKAGE use the same
+;;; value, and (2) that it (as an implementation-defined value) should
+;;; be documented, which we do in the doc string. So for OAOO reasons
+;;; we represent this value as a variable only at compile time, and
+;;; then use #. readmacro hacks to splice it into the target code as a
+;;; constant.
+(eval-when (:compile-toplevel)
+ (defparameter *default-package-use-list*
+ ;; ANSI says this is implementation-defined. So we make it NIL,
+ ;; the way God intended. Anyone who actually wants a random value
+ ;; is free to :USE (PACKAGE-USE-LIST :CL-USER) anyway.:-|
+ nil))
+
(defmacro defpackage (package &rest options)
#!+sb-doc
"Defines a new package called PACKAGE. Each of OPTIONS should be one of the
(let ((package (or (find-package name)
(progn
(when (eq use :default)
- (setf use *default-package-use-list*))
+ (setf use '#.*default-package-use-list*))
(make-package name
:use nil
:internal-symbols (or size 10)
(!cold-init-forms
(/show0 "entering !PACKAGE-COLD-INIT"))
-
-;;; the list of packages to use by default when no :USE argument is
-;;; supplied to MAKE-PACKAGE or other package creation forms
-(defvar *default-package-use-list*)
-(!cold-init-forms (setf *default-package-use-list* nil))
\f
;;;; PACKAGE-HASHTABLE stuff
(push n (package-%nicknames package)))))))
(defun make-package (name &key
- (use *default-package-use-list*)
+ (use '#.*default-package-use-list*)
nicknames
(internal-symbols 10)
(external-symbols 10))
#!+sb-doc
- "Makes a new package having the specified Name and Nicknames. The
- package will inherit all external symbols from each package in
- the use list. :INTERNAL-SYMBOLS and :EXTERNAL-SYMBOLS are
+ #.(format nil
+ "Make a new package having the specified NAME, NICKNAMES, and
+ USE list. :INTERNAL-SYMBOLS and :EXTERNAL-SYMBOLS are
estimates for the number of internal and external symbols which
will ultimately be present in the package. The default value of
- USE is implementation-dependent, and in this implementation
- it is simply NIL."
+ USE is implementation-dependent, and in this implementation
+ it is ~S."
+ *default-package-use-list*)
;; Check for package name conflicts in name and nicknames, then
;; make the package.
;;; for internal versions, especially for internal versions off the
;;; main CVS branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.pre7.142"
+"0.7.0"
projects / sbcl.git / commitdiff