/[cmucl]/src/general-info/cmucl.1
ViewVC logotype

Contents of /src/general-info/cmucl.1

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.12.2.1 - (show annotations)
Thu Apr 11 00:22:57 2002 UTC (12 years ago) by pmai
Branch: RELENG_18
CVS Tags: RELEASE_18d
Changes since 1.12: +1 -1 lines
Merged missing documentation files for release tarballs from main branch.
1 .\" -*- Mode: Text -*-
2 .\"
3 .\" **********************************************************************
4 .\" This code was written as part of the CMU Common Lisp project at
5 .\" Carnegie Mellon University, and has been placed in the public domain.
6 .\" If you want to use this code or any part of CMU Common Lisp, please contact
7 .\" Scott Fahlman or slisp-group@cs.cmu.edu.
8 .\"
9 .\"$Header: /tiger/var/lib/cvsroots/cmucl/src/general-info/cmucl.1,v 1.12.2.1 2002/04/11 00:22:57 pmai Exp $
10 .\"
11 .\" **********************************************************************
12 .\"
13 .\" Man page introduction to CMU CL.
14 .TH CMUCL 1 "October 15, 1991"
15 .AT 3
16 .SH NAME
17 CMU Common Lisp
18
19 .SH DESCRIPTION
20
21 CMU Common Lisp is public domain "industrial strength" Common Lisp programming
22 environment. Many of the X3j13 changes have been incorporated into CMU CL.
23 Wherever possible, this has been done so as to transparently allow use of
24 either CLtL1 or proposed ANSI CL. Probably the new features most interesting
25 to users are SETF functions, LOOP and the WITH-COMPILATION-UNIT macro.
26
27 .SH HARDWARE REQUIREMENTS
28
29 CMU CL is currently available for a variety of Unix workstations. See the
30 README file for current platforms. At least 16 megabytes of memory and 25
31 megabytes of disk space are recommended. As usual, more is better.
32
33 .SH OVERVIEW
34 When compared other Common Lisp implementations, CMU CL has
35 two broad advantages:
36 .TP 3
37 \--
38 The new CMU CL compiler (Python) is more sophisticated than other
39 Common Lisp compilers. It both produces better code and is easier to use.
40 .TP 3
41 \--
42 The programming environment based on the Hemlock editor is better
43 integrated than gnu-emacs based environments. (Though you can still use
44 GNU if you want.)
45 .PP
46
47 CMU CL also has significant non-technical advantages:
48 .TP 3
49 \--
50 It has good local support for CMU users, and is well integrated with the
51 CMU CS environment.
52 .TP 3
53 \--
54 It is public domain, and is freely available to non-CMU sites that aren't
55 able to afford a site-license for a commercial Lisp.
56
57
58 .SH COMPILER FEATURES
59
60 The `Advanced Compiler' chapter of the User's manual extensively discusses
61 Python's optimization capabilities (See DOCUMENTATION below.) Here are a few
62 high points:
63 .TP 3
64 \--
65 Good efficiency and type-checking
66 .I at the same time.
67 Compiling code safe gives a 2x speed reduction at worst.
68 .TP 3
69 \--
70 In safe code, type declarations are verified, allowing declarations to
71 be debugged in safe code. When you go to compile unsafe, you know the
72 declarations are right.
73 .TP 3
74 \--
75 Full source level debugging of compiled code, including display of the
76 exact call that got an error.
77 .TP 3
78 \--
79 Good efficiency notes that tell you why an operation can't be open coded
80 or where you are number-consing, and that provide unprecedented source context
81 .TP 3
82 \--
83 Block compilation, partial evaluation, lightweight functions and proper
84 tail-recursion allow low-cost use of function call abstraction.
85 .PP
86
87 .SH TYPE SUPPORT
88
89 .B Important note:
90 Even debugged programs may contain type errors that remain undetected by
91 other compilers. When compiled with type checking suppressed using the
92 CMU Common Lisp compiler, these type errors may cause said debugged
93 programs to die strangely. If type checking is not suppressed, these
94 programs will die with an explicit type error.
95
96 The most visible way in which Python differs from previous Common Lisp
97 compilers is that it has a greater knowledge about types and a different
98 approach to type checking. In particular, Python implements type checking
99 which is `eager' and `precise':
100 .TP 3
101 \--
102 Eager in the sense that type checking is done immediately whenever there is
103 a declaration, rather than being delayed until the the value is actually
104 used. For example:
105 .nf
106 (let ((x ...))
107 .br
108 (declare (fixnum x))
109 .br
110 ...)
111 .br
112 .fi
113 Here, the type of the initial value of X must be a FIXNUM or an error will
114 be signalled.
115 .TP 3
116 \--
117 Precise in the sense that the exact type specified is checked. For
118 example, if a variable is declared to be of type (integer 3 7), then the
119 value must always be an integer between 3 and 7.
120 .PP
121
122 Since Python does more type checking, programs that work fine when compiled
123 with other compilers may get type errors when compiled with Python. It is
124 important to initially compile programs with the default (safe) policy, and
125 then test this version. If a program with an erroneous declaration is compiled
126 with type checking suppressed (due to the SAFETY optimize quality being
127 reduced), then the type error may cause obscure errors or infinite looping.
128 See the section `Getting Existing Programs to Run' (6.6) in the compiler
129 chapter of the user manual.
130
131 CMU CL adheres to the X3J13 function type cleanup, which means that quoted
132 lambda-lists are not of type FUNCTION, and are no longer directly callable.
133 Use COERCE with the FUNCTION result type.
134
135 .SH OPTIMIZATION
136
137 Python does many optimizations that are absent or less general in other
138 Common Lisp compilers:
139 Proper tail recursion, lightweight function call, block compilation,
140 inter-procedural type inference, global flow analysis, dynamic type
141 inference, global register allocation, stack number allocation, control
142 optimization, integer range analysis, enhanced inline expansion, multiple
143 value optimization and source-to-source transforms.
144
145 Optimization and type-checking are controlled by the OPTIMIZE declaration. The
146 default compilation policy is type-safe.
147
148 .SH NUMERIC SUPPORT
149
150 Python is particular good at number crunching:
151 .TP 3
152 \--
153 Good inline coding of float and 32 bit integer operations, with no
154 number consing. This includes all the hardware primitives ROUND,
155 TRUNCATE, COERCE, as well as important library routines such as
156 SCALE-FLOAT and DECODE-FLOAT. Results that don't fit in registers go
157 on a special number stack.
158 .TP 3
159 \--
160 Full support for IEEE single and double (denorms, +-0, etc.)
161 .TP 3
162 \--
163 In block compiled code, numbers are passed as function arguments and
164 return values in registers (and without number consing.)
165 .TP 3
166 \--
167 Calls to library functions (SIN, ...) are optimized to a direct call to
168 the C library routine (with no number consing.) On hardware with
169 direct support for such functions, these operations can easily be
170 open-coded.
171 .TP 3
172 \--
173
174 Substantially better bignum performance than commercial implementations
175 (2x-4x). Bignums implemented in lisp using word integers, so you can roll your
176 own.
177 .PP
178
179 Python's compiler warnings and efficiency notes are especially valuable in
180 numeric code. 50+ pages in the user manual describe Python's capabilities in
181 more detail.
182
183
184 .SH THE DEBUGGER
185
186 In addition to a Motif-based windowing interface and a basic command-line
187 interface, the debugger also has several powerful new features:
188 .TP 3
189 \--
190 The "source" and "vsource" commands print the *precise* original source
191 form responsible for the error or pending function call. It is no longer
192 necessary to guess which call to CAR caused some "not a list" error.
193 .TP 3
194 \--
195 Variables in compiled code can be accessed by name, so the debugger always
196 evaluates forms in the lexical environment of the current frame. This
197 variable access is robust in the presence of compiler optimization ---
198 although higher levels of optimization may make variable values unavailable
199 at some locations in the variable's scope, the debugger always errs on the
200 side of discretion, refusing to display possibly incorrect values.
201 .TP 3
202 \--
203 Compiled code can be stepped, stopping at each control transfer.
204 .TP 3
205 \--
206 Integration with the Hemlock editor. In a slave, the "edit" command causes the
207 editor edit the source for the current code location. The editor can also send
208 non-line-mode input to the debugger using C-M-H bindings. Try apropos "debug"
209 in Hemlock.
210 .PP
211 See the debugger chapter in the user manual for more details. We are working
212 on integrating the debugger with Hemlock and X windows.
213
214 .SH THE GRAPHICAL INTERFACE
215
216 CMU Common Lisp has an interface to Motif which is functionally similar to
217 CLM, but works better in CMU CL. See:
218 .IP "" .2i
219 .br
220 doc/motif-toolkit.doc
221 .br
222 doc/motif-internals.doc
223 .PP
224
225 This motif interface has been used to write the inspector and graphical
226 debugger. There is also a Lisp control panel with a simple file management
227 facility, apropos and inspector dialogs, and controls for setting global
228 options.
229
230 Call INTERFACE:LISP-CONTROL-PANEL to create the control panel. When
231 INTERFACE:*INTERFACE-STYLE* is :GRAPHICS (the default) and the DISPLAY
232 environment variable is defined, the graphical inspector and debugger will be
233 invoked by INSPECT or when an error is signalled. Possible values are
234 :GRAPHICS and :TTY. If the value is :GRAPHICS, but there is no X display,
235 then we quietly use the TTY interface.
236
237 .SH THE INTERPRETER
238
239 As far as Common Lisp semantics are concerned, there is no interpreter; this is
240 effectively a compile-only implementation. Forms typed to the read-eval-print
241 loop or passed to EVAL are in effect compiled before being run. In
242 implementation, there is an interpreter, but it operates on the internal
243 representation produced by the compiler's font-end.
244
245 It is not recommended that programs be debugged by running the whole program
246 interpreted, since Python and the debugger eliminate the main reasons for
247 debugging using the interpreter:
248 .TP 3
249 \--
250 Compiled code does much more error checking than interpreted code.
251 .TP 3
252 \--
253 It is as easy to debug compiled code as interpreted code.
254 .PP
255
256 Note that the debugger does not currently support single-stepping. Also, the
257 interpreter's pre-processing freezes in the macro definitions in effect at the
258 time an interpreted function is defined. Until we implement automatic
259 reprocessing when macros are redefined, it is necessary to re-evaluate the
260 definition of an interpreted function to cause new macro definitions to be
261 noticed.
262
263 .SH DOCUMENTATION
264
265 The CMU CL documentation is printed as tech reports, and is available (at CMU)
266 in the document room:
267 .IP "" .2i
268 .br
269 CMU Common Lisp User's Manual
270 .br
271 Hemlock User's Manual
272 .br
273 Hemlock Command Implementor's Manual
274 .PP
275
276 Non-CMU users may get documentation from the doc/ directory in the binary
277 distribution:
278 .TP 10n
279 .BR cmu-user.info
280 CMU CL User's Manual in Gnu Info format. The ``cmu-user.info-<N>'' files
281 are subfiles. You can either have your EMACS
282 maintainer install this in the info root, or you can use the info
283 ``g(...whatever.../doc/cmu-user.info)'' command.
284 .TP
285 .BR cmu-user.ps
286 The CMU CL User's Manual (148 pages) in postscript format. LaTeX source and
287 DVI versions are also available.
288 .TP
289 .BR release-notes.txt
290 Information on the changes between releases.
291 .TP
292 .BR hemlock-user.ps
293 Postscript version of the Hemlock User's Manual (124 pages.)
294 .TP
295 .BR hemlock-cim.ps
296 Postscript version of the Hemlock Command Implementor's Manual (96 pages).
297 .PP
298 \
299
300 .SH SUPPORT
301
302 Bug reports should be sent to cmucl-bugs@cs.cmu.edu. Please consult
303 your local CMU CL maintainer or Common Lisp expert to verify that
304 the problem really is a bug before sending to this list.
305
306 The CMU Common Lisp project is no longer funded, so only minimal support is
307 being done at CMU. There is a net community of \cmucl{} users and maintainers
308 who communicate via comp.lang.lisp and the cmucl-bugs@cs.cmu.edu mailing list.
309
310 .SH DISTRIBUTION
311
312 CMU Common Lisp is a public domain implementation of Common Lisp. Both sources
313 and executables are freely available via anonymous FTP; this software is
314 "as is", and has no warranty of any kind. CMU and the authors assume no
315 responsibility for the consequences of any use of this software. See the
316 README file in the distribution for FTP instructions.
317
318 .SH ABOUT THE CMU COMMON LISP PROJECT
319
320 Organizationally, CMU Common Lisp was a small, mostly autonomous part within
321 the Mach operating system project. The CMU CL project was more of a tool
322 development effort than a research project. The project started out as Spice
323 Lisp, which provided a modern Lisp implementation for use in the CMU community.
324 CMU CL has been under continuous development since the early 1980's (concurrent
325 with the Common Lisp standardization effort.) Most of the CMU Common Lisp
326 implementors are now working on the Gwydion environment for Dylan (see
327 http://legend.gwydion.cs.cmu.edu:8001/gwydion/.)
328
329 CMU CL was funded by DARPA under CMU's "Research on Parallel Computing"
330 contract. Rather than doing pure research on programming languages and
331 environments, the emphasis was on developing practical programming tools.
332 Sometimes this required new technology, but much of the work was in creating a
333 Common Lisp environment that incorporates state-of-the-art features from
334 existing systems (both Lisp and non-Lisp.)
335
336 Because sources are freely available, CMU Common Lisp has been ported to
337 experimental hardware, and used as a basis for research in programming language
338 and environment construction.
339
340 .SH SEE ALSO
341 lisp(1), README
342 .br
343 The ``CMU Common Lisp User's Manual'',
344 .br
345 the ``Hemlock User's Manual'', and
346 .br
347 the ``Hemlock Command Implementor's Manual''

  ViewVC Help
Powered by ViewVC 1.1.5