cmucl (1)
NAME
CMU Common Lisp
DESCRIPTION
CMU Common Lisp is public domain "industrial strength" Common Lisp pro-
gramming environment. Many of the X3j13 changes have been incorporated
into CMU CL. Wherever possible, this has been done so as to transpar-
ently allow use of either CLtL1 or proposed ANSI CL. Probably the new
features most interesting to users are SETF functions, LOOP and the
WITH-COMPILATION-UNIT macro.
HARDWARE REQUIREMENTS
CMU CL is currently available for a variety of Unix workstations. See
the README file for current platforms. At least 16 megabytes of memory
and 25 megabytes of disk space are recommended. As usual, more is bet-
ter.
OVERVIEW
When compared other Common Lisp implementations, CMU CL has two broad
advantages:
-- The new CMU CL compiler (Python) is more sophisticated than other
Common Lisp compilers. It both produces better code and is easier
to use.
-- The programming environment based on the Hemlock editor is better
integrated than gnu-emacs based environments. (Though you can still
use GNU if you want.)
CMU CL also has significant non-technical advantages:
-- It has good local support for CMU users, and is well integrated with
the CMU CS environment.
-- It is public domain, and is freely available to non-CMU sites that
aren't able to afford a site-license for a commercial Lisp.
COMPILER FEATURES
The `Advanced Compiler' chapter of the User's manual extensively dis-
cusses Python's optimization capabilities (See DOCUMENTATION below.)
Here are a few high points:
-- Good efficiency and type-checking at the same time. Compiling code
safe gives a 2x speed reduction at worst.
-- In safe code, type declarations are verified, allowing declarations
to be debugged in safe code. When you go to compile unsafe, you
know the declarations are right.
tion.
TYPE SUPPORT
Important note: Even debugged programs may contain type errors that
remain undetected by other compilers. When compiled with type checking
suppressed using the CMU Common Lisp compiler, these type errors may
cause said debugged programs to die strangely. If type checking is not
suppressed, these programs will die with an explicit type error.
The most visible way in which Python differs from previous Common Lisp
compilers is that it has a greater knowledge about types and a differ-
ent approach to type checking. In particular, Python implements type
checking which is `eager' and `precise':
-- Eager in the sense that type checking is done immediately whenever
there is a declaration, rather than being delayed until the the
value is actually used. For example:
(let ((x ...))
(declare (fixnum x))
...)
Here, the type of the initial value of X must be a FIXNUM or an
error will be signalled.
-- Precise in the sense that the exact type specified is checked. For
example, if a variable is declared to be of type (integer 3 7), then
the value must always be an integer between 3 and 7.
Since Python does more type checking, programs that work fine when com-
piled with other compilers may get type errors when compiled with
Python. It is important to initially compile programs with the default
(safe) policy, and then test this version. If a program with an erro-
neous declaration is compiled with type checking suppressed (due to the
SAFETY optimize quality being reduced), then the type error may cause
obscure errors or infinite looping. See the section `Getting Existing
Programs to Run' (6.6) in the compiler chapter of the user manual.
CMU CL adheres to the X3J13 function type cleanup, which means that
quoted lambda-lists are not of type FUNCTION, and are no longer
directly callable. Use COERCE with the FUNCTION result type.
OPTIMIZATION
Python does many optimizations that are absent or less general in other
Common Lisp compilers: Proper tail recursion, lightweight function
call, block compilation, inter-procedural type inference, global flow
analysis, dynamic type inference, global register allocation, stack
number allocation, control optimization, integer range analysis,
enhanced inline expansion, multiple value optimization and source-to-
source transforms.
Optimization and type-checking are controlled by the OPTIMIZE declara-
tion. The default compilation policy is type-safe.
-- Full support for IEEE single and double (denorms, +-0, etc.)
-- In block compiled code, numbers are passed as function arguments and
return values in registers (and without number consing.)
-- Calls to library functions (SIN, ...) are optimized to a direct call
to the C library routine (with no number consing.) On hardware with
direct support for such functions, these operations can easily be
open-coded.
-- Substantially better bignum performance than commercial implementa-
tions (2x-4x). Bignums implemented in lisp using word integers, so
you can roll your own.
Python's compiler warnings and efficiency notes are especially valuable
in numeric code. 50+ pages in the user manual describe Python's capa-
bilities in more detail.
THE DEBUGGER
In addition to a Motif-based windowing interface and a basic command-
line interface, the debugger also has several powerful new features:
-- The "source" and "vsource" commands print the *precise* original
source form responsible for the error or pending function call. It
is no longer necessary to guess which call to CAR caused some "not a
list" error.
-- Variables in compiled code can be accessed by name, so the debugger
always evaluates forms in the lexical environment of the current
frame. This variable access is robust in the presence of compiler
optimization --- although higher levels of optimization may make
variable values unavailable at some locations in the variable's
scope, the debugger always errs on the side of discretion, refusing
to display possibly incorrect values.
-- Compiled code can be stepped, stopping at each control transfer.
-- Integration with the Hemlock editor. In a slave, the "edit" command
causes the editor edit the source for the current code location.
The editor can also send non-line-mode input to the debugger using
C-M-H bindings. Try apropos "debug" in Hemlock.
See the debugger chapter in the user manual for more details. We are
working on integrating the debugger with Hemlock and X windows.
THE GRAPHICAL INTERFACE
CMU Common Lisp has an interface to Motif which is functionally similar
to CLM, but works better in CMU CL. See:
doc/motif-toolkit.doc
doc/motif-internals.doc
will be invoked by INSPECT or when an error is signalled. Possible
values are :GRAPHICS and :TTY. If the value is :GRAPHICS, but there is
no X display, then we quietly use the TTY interface.
THE INTERPRETER
As far as Common Lisp semantics are concerned, there is no interpreter;
this is effectively a compile-only implementation. Forms typed to the
read-eval-print loop or passed to EVAL are in effect compiled before
being run. In implementation, there is an interpreter, but it operates
on the internal representation produced by the compiler's font-end.
It is not recommended that programs be debugged by running the whole
program interpreted, since Python and the debugger eliminate the main
reasons for debugging using the interpreter:
-- Compiled code does much more error checking than interpreted code.
-- It is as easy to debug compiled code as interpreted code.
Note that the debugger does not currently support single-stepping.
Also, the interpreter's pre-processing freezes in the macro definitions
in effect at the time an interpreted function is defined. Until we
implement automatic reprocessing when macros are redefined, it is nec-
essary to re-evaluate the definition of an interpreted function to
cause new macro definitions to be noticed.
DOCUMENTATION
The CMU CL documentation is printed as tech reports, and is available
(at CMU) in the document room:
CMU Common Lisp User's Manual
Hemlock User's Manual
Hemlock Command Implementor's Manual
Non-CMU users may get documentation from the doc/ directory in the
binary distribution:
cmu-user.info
CMU CL User's Manual in Gnu Info format. The ``cmu-
user.info-<N>'' files are subfiles. You can either have your
EMACS maintainer install this in the info root, or you can
use the info ``g(...whatever.../doc/cmu-user.info)'' command.
cmu-user.ps
The CMU CL User's Manual (148 pages) in postscript format.
LaTeX source and DVI versions are also available.
release-notes.txt
Information on the changes between releases.
hemlock-user.ps
Postscript version of the Hemlock User's Manual (124 pages.)
your local CMU CL maintainer or Common Lisp expert to verify that the
problem really is a bug before sending to this list.
The CMU Common Lisp project is no longer funded, so only minimal sup-
port is being done at CMU. There is a net community of who communicate
via comp.lang.lisp and the cmucl-bugs@cs.cmu.edu mailing list.
DISTRIBUTION
CMU Common Lisp is a public domain implementation of Common Lisp. Both
sources and executables are freely available via anonymous FTP; this
software is "as is", and has no warranty of any kind. CMU and the
authors assume no responsibility for the consequences of any use of
this software. See the README file in the distribution for FTP
instructions.
ABOUT THE CMU COMMON LISP PROJECT
Organizationally, CMU Common Lisp was a small, mostly autonomous part
within the Mach operating system project. The CMU CL project was more
of a tool development effort than a research project. The project
started out as Spice Lisp, which provided a modern Lisp implementation
for use in the CMU community. CMU CL has been under continuous devel-
opment since the early 1980's (concurrent with the Common Lisp stan-
dardization effort.) Most of the CMU Common Lisp implementors are now
working on the Gwydion environment for Dylan (see http://leg-
end.gwydion.cs.cmu.edu:8001/gwydion/.)
CMU CL was funded by DARPA under CMU's "Research on Parallel Computing"
contract. Rather than doing pure research on programming languages and
environments, the emphasis was on developing practical programming
tools. Sometimes this required new technology, but much of the work
was in creating a Common Lisp environment that incorporates state-of-
the-art features from existing systems (both Lisp and non-Lisp.)
Because sources are freely available, CMU Common Lisp has been ported
to experimental hardware, and used as a basis for research in program-
ming language and environment construction.
SEE ALSO
lisp(1), README
The ``CMU Common Lisp User's Manual'',
the ``Hemlock User's Manual'', and
the ``Hemlock Command Implementor's Manual''
7th Edition October 15, 1991 cmucl(1)