Common Lisp is intended to meet these goals:
-
Commonality
Common Lisp originated in an attempt to focus the work
of several implementation groups, each of which was constructing
successor implementations of MacLisp for different computers. These
implementations had begun to diverge because of the differences
in the implementation environments: microcoded personal computers
(Zetalisp, Spice Lisp), commercial timeshared computers (NIL—the
“New Implementation of Lisp”), and supercomputers (S-1 Lisp). While
the differences among the several implementation environments of
necessity will continue to force certain incompatibilities among the
implementations, Common Lisp serves as a common dialect to which
each implementation makes any necessary extensions.
-
Portability
Common Lisp intentionally excludes features that cannot
be implemented easily on a broad class of machines. On the
one hand, features that are difficult or expensive to implement
on hardware without special microcode are avoided or provided
in a more abstract and efficiently implementable form. (Examples
of this are the invisible forwarding pointers and locatives of
Zetalisp. Some of the problems that they solve are addressed in
different ways in Common Lisp.) On the other hand, features that
are useful only on certain “ordinary” or “commercial” processors
are avoided or made optional. (An example of this is the type
declaration facility, which is useful in some implementations and
completely ignored in others. Type declarations are completely optional
and for correct programs affect only efficiency, not semantics.)
Common Lisp is designed to make it easy to write programs that
depend as little as possible on machine-specific characteristics, such
as word length, while allowing some variety of implementation
techniques.
-
Consistency
Most Lisp implementations are internally inconsistent in that
by default the interpreter and compiler may assign different semantics
to correct programs. This semantic difference stems primarily from
the fact that the interpreter assumes all variables to be dynamically
scoped, whereas the compiler assumes all variables to be local unless
explicitly directed otherwise. This difference has been the usual practice
in Lisp for the sake of convenience and efficiency but can lead to very
subtle bugs. The definition of Common Lisp avoids such anomalies by
explicitly requiring the interpreter and compiler to impose identical
semantics on correct programs so far as possible.
-
Expressiveness
Common Lisp culls what experience has shown to be the
most useful and understandable constructs from not only MacLisp but
also Interlisp, other Lisp dialects, and other programming languages.
Constructs judged to be awkward or less useful have been excluded.
(An example is the store construct of MacLisp.)
-
Compatibility
Unless there is a good reason to the contrary, Common
Lisp strives to be compatible with Lisp Machine Lisp, MacLisp, and
Interlisp, roughly in that order.
-
E ciency
Common Lisp has a number of features designed to facilitate
the production of high-quality compiled code in those implementations
whose developers care to invest effort in an optimizing compiler.
One implementation of Common Lisp, namely S-1 Lisp, already has
a compiler that produces code for numerical computations that is
competitive in execution speed to that produced by a Fortran compiler
[11]. The S-1 Lisp compiler extends the work done in MacLisp to
produce extremely efficient numerical code [19].
-
Power
Common Lisp is a descendant of MacLisp, which has traditionally
placed emphasis on providing system-building tools. Such tools may
in turn be used to build the user-level packages such as Interlisp
provides; these packages are not, however, part of the Common Lisp
core specification. It is expected such packages will be built on top of
the Common Lisp core.
-
Stability
It is intended that Common Lisp will change only slowly and with
due deliberation. The various dialects that are supersets of Common
Lisp may serve as laboratories within which to test language extensions,
but such extensions will be added to Common Lisp only after careful
examination and experimentation.
The goals of Common Lisp are thus very close to those of Standard Lisp [31]
and Portable Standard Lisp [51]. Common Lisp differs from Standard Lisp
primarily in incorporating more features, including a richer and more complicated
set of data types and more complex control structures.
This book is intended to be a language specification rather than an
implementation specification (although implementation notes are scattered
throughout the text). It defines a set of standard language concepts and
constructs that may be used for communication of data structures and algorithms
in the Common Lisp dialect. This set of concepts and constructs is sometimes
referred to as the “core Common Lisp language” because it contains conceptually
necessary or important features. It is not necessarily implementationally minimal.
While many features could be defined in terms of others by writing Lisp code, and
indeed may be implemented that way, it was felt that these features should be
conceptually primitive so that there might be agreement among all users as
to their usage. (For example, bignums and rational numbers could be
implemented as Lisp code given operations on fixnums. However, it is
important to the conceptual integrity of the language that they be regarded by
the user as primitive, and they are useful enough to warrant a standard
definition.)
For the most part, this book defines a programming language, not a
programming environment. A few interfaces are defined for invoking such
standard programming tools as a compiler, an editor, a program trace facility, and
a debugger, but very little is said about their nature or operation. It
is expected that one or more extensive programming environments will
be built using Common Lisp as a foundation, and will be documented
separately.
There are now many implementations of Common Lisp, some programmed by
research groups in universities and some by companies that sell them
commercially, and a number of useful programming environments have
indeed grown up around these implementations. What is more, all the
goals stated above have been achieved, most notably that of portability.
Moving large bodies of Lisp code from one computer to another is now
routine.