Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
CMUCL(1)		    General Commands Manual		      CMUCL(1)

       cmucl - CMU Common Lisp

       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

       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-

       When  compared  other Common Lisp implementations, CMU CL has two broad

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

       -- 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 unprece-
	  dented source	context

       -- Block	compilation, partial  evaluation,  lightweight	functions  and
	  proper  tail-recursion  allow	low-cost use of	function call abstrac-

       Important note: Even debugged programs may contain type errors that re-
       main  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 er-
	  ror 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  di-
       rectly 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, en-
       hanced 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.

       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


	  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.

       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:


       This motif interface has	been used to write the inspector and graphical
       debugger.  There	is also	a Lisp control panel with a simple  file  man-
       agement	facility, apropos and inspector	dialogs, and controls for set-
       ting 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 im-
       plement automatic reprocessing when macros are redefined, it is	neces-
       sary  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 bi-
       nary distribution:
		 CMU  CL  User's  Manual  in  Gnu  Info	 format.   The	``cmu-<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/'' 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  Man-
		 ual (96 pages).

       Bug  reports  should  be	sent to	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 sup-
       port is being done at CMU.  There is a net community of who communicate
       via comp.lang.lisp and the	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 au-
       thors assume no responsibility for the consequences of any use of  this
       software.   See	the  README  file in the distribution for FTP instruc-

       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-

       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.

       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)


Want to link to this manual page? Use this URL:

home | help