DOKK / manpages / debian 11 / cmucl / cmucl-lisp.1.en
CMUCL(1) General Commands Manual CMUCL(1)

cmucl - CMU Common Lisp

CMU Common Lisp is public domain "industrial strength" Common Lisp programming environment. Many of the X3j13 changes have been incorporated into CMU CL. Wherever possible, this has been done so as to transparently 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.

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 better.

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.

The `Advanced Compiler' chapter of the User's manual extensively discusses 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.
--
Full source level debugging of compiled code, including display of the exact call that got an error.
--
Good efficiency notes that tell you why an operation can't be open coded or where you are number-consing, and that provide unprecedented source context
--
Block compilation, partial evaluation, lightweight functions and proper tail-recursion allow low-cost use of function call abstraction.

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 different 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 compiled 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 erroneous 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.

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 declaration. The default compilation policy is type-safe.

Python is particular good at number crunching:

--
Good inline coding of float and 32 bit integer operations, with no number consing. This includes all the hardware primitives ROUND, TRUNCATE, COERCE, as well as important library routines such as SCALE-FLOAT and DECODE-FLOAT. Results that don't fit in registers go on a special number stack.
--
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 implementations (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 capabilities in more detail.

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.

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

This motif interface has been used to write the inspector and graphical debugger. There is also a Lisp control panel with a simple file management facility, apropos and inspector dialogs, and controls for setting global options.

Call INTERFACE:LISP-CONTROL-PANEL to create the control panel. When INTERFACE:*INTERFACE-STYLE* is :GRAPHICS (the default) and the DISPLAY environment variable is defined, the graphical inspector and debugger 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.

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 necessary to re-evaluate the definition of an interpreted function to cause new macro definitions to be noticed.

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 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.
The CMU CL User's Manual (148 pages) in postscript format. LaTeX source and DVI versions are also available.
Information on the changes between releases.
Postscript version of the Hemlock User's Manual (124 pages.)
Postscript version of the Hemlock Command Implementor's Manual (96 pages).

Bug reports should be sent to cmucl-bugs@cs.cmu.edu. Please consult 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 support is being done at CMU. There is a net community of mucl{} users and maintainers who communicate via comp.lang.lisp and the cmucl-bugs@cs.cmu.edu mailing list.

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.

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 development since the early 1980's (concurrent with the Common Lisp standardization effort.) Most of the CMU Common Lisp implementors are now working on the Gwydion environment for Dylan (see http://legend.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 programming language and environment construction.

lisp(1), README
The ``CMU Common Lisp User's Manual'',
the ``Hemlock User's Manual'', and
the ``Hemlock Command Implementor's Manual''

October 15, 1991 7th Edition