-``compiler-only implementation'' of Common Lisp. A Common Lisp
-implementation is permitted to implement both a compiler and an
-interpreter, and there's some special support in the standard
-(e.g. the distinction between @code{functionp} and
-@code{compiled-function-p}) to help support that. But SBCL has only a
-vestigial, rudimentary true interpreter. In SBCL, the @code{eval}
-function only truly ``interprets'' a few special classes 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.
+``compiler-only implementation'' of Common Lisp. This is a change in
+implementation strategy, taking advantage of the freedom ``any of these
+facilities might share the same execution strategy'' guaranteed in the
+ANSI specification section 3.1 (``Evaluation''). It does not mean SBCL
+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
+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.
projects / sbcl.git / blobdiff