Archive-name: lisp-faq/part2
Last-Modified: Tue Feb 11 16:22:48 1992 by Mark Kantrowitz
Version: 1.12
;;; ****************************************************************
;;; Answers to Frequently Asked Questions about Lisp ***************
;;; ****************************************************************
;;; Written by Mark Kantrowitz and Barry Margolin
;;; lisp-faq-2.text -- 63961 bytes
This post contains Part 2 of the Lisp FAQ.
If you think of questions that are appropriate for this FAQ, or would
like to improve an answer, please send email to us at ········@think.com.
Topics Covered (Part 2):
[9] What FTP resources are available?
[10] Is there a GNU-Emacs interface to Lisp?
[11] How can I use the X Window System from Lisp?
[12] What does CLOS, PCL, X3J13, CAR, CDR, ... mean?
What is CLOS (PCL) and where can I get it?
How do you pronounce CLOS?
[14] Why does (READ-FROM-STRING "foobar" :START 3) return FOOBAR
instead of BAR?
[15] Why can't it deduce from (READ-FROM-STRING "foobar" :START 3)
that the intent is to specify the START keyword parameter
rather than the EOF-ERROR-P and EOF-VALUE optional parameters?
[16] How I write a function that can access defstruct slots by
name? I would like to write something like
(STRUCTURE-SLOT <object> '<slot-name>).
[17] Why can't I apply #'AND and #'OR?
[18] When is it right to use EVAL?
[19] I used a destructive function (e.g. DELETE, SORT), but it
didn't seem to work. Why?
[20] After I NREVERSE a list, it's only one element long. After I
SORT a list, it's missing things. What happened?
[21] What is the equivalent of EXPLODE and IMPLODE in Common Lisp?
[22] Is Lisp inherently slower than more conventional languages such as C?
[23] Why does my program's behavior change each time I use it?
[24] Why does Common Lisp have "#'"?
[25] How can I list all the CLOS instances in a class?
[26] How do I call non-Lisp functions from Lisp?
[27] Can I call Lisp functions from other languages?
[28] Why does (READ-LINE) return "" immediately instead of waiting
for me to type a line?
[29] I typed a form to the read-eval-print loop, but nothing happened. Why?
[30] I want to call a function in a package that might not exist at
compile time. How do I do this?
[31] What is CDR-coding?
[32] What is garbage collection?
[33] How do I save an executable image of my loaded Lisp system?
[34] I'm porting some code from a Symbolics Lisp machine to some
other platform, and there are strange characters in the code.
What do they mean?
[35] History: Where did Lisp come from?
Search for [#] to get to question number # quickly.
----------------------------------------------------------------
[9] What FTP resources are available?
There are several repositories of publicly redistributable and
public domain Lisp and Scheme code.
The Lisp Utilities collection is accessible by anonymous ftp
to any CMU CS machine (e.g., a.gp.cs.cmu.edu, b.gp.cs.cmu.edu)
or through AFS in the directory
/afs/cs.cmu.edu/user/mkant/Public/Lisp-Utilities/
If accessing this directory through anonymous ftp, it is
important to cd to the directory using one command, as
intermediate directories are protected during an anonymous ftp.
Files included in the repository include:
extensions.lisp A collection of extensions to Common Lisp.
initializations.lisp Brad Miller's initializations packaged
for Allegro CL 4.0.
xref.lisp Portable cross referencing tool for Lisp.
Similar to the Symbolics Who-Calls and
the Xerox MasterScope programs.
defsystem.lisp Portable system definition facility (a
"Make" for lisp). More featureful than
other defsystem implementations.
logical-pathnames.lisp Portable implementation of the X3J13
June 1989 specification for logical pathnames.
metering.lisp Portable code time/space profiling tool.
source-compare.lisp A portable "diff" utility for Lisp.
user-manual.lisp Program which helps with documenting Lisp code.
psgraph.lisp Joe Bates' PostScript DAG grapher.
matcher.lisp A regexp-like matcher for Lisp.
framework.lisp A portable generic frame system.
date-formatter.lisp Simple code for formatting a date.
save-object.lisp Kerry Koitzsch's package to save ASCII
representations of Lisp objects to a file.
defpackage.lisp Stephen Nicoud's semi-portable
CLtL2 version of defpackage.
johnson-yacc.lisp Mark Johnson's lisp YACC.
ops5.tar.Z Public domain Common Lisp implementation
of the OPS5 production system interpreter.
"Expert System Shell".
Written by Charles Forgy and ported by
George Wood and Jim Kowalski.
cmu-loop.lisp Implements the CLtL2 Loop Macro.
mit-loop.lisp Implements the CLtL1 Loop Macro.
sloop.lisp William Schelter's loop macro, not CLtL.
yloop.lisp Frank Ritter and Jim Panagos' implementation
of the Yale loop macro described in
McDermont, Charniak and Riesbeck's
AI programming book. Not CLtL.
ew/ Express Windows distribution.
iterate/ The Iterate Macro.
series/ Waters' Series Macro package.
The Lisp Utilities repository is maintained by Mark
Kantrowitz, ····················@cs.cmu.edu.
The Scheme Repository contains a Scheme bibliography, copies
of the R4RS report, sample Scheme code for a variety of
purposes, several utilities, and some implementations. The
repository is maintained by Ozan S. Yigit, ······@nexus.yorku.ca.
The repository is accessible by anonymous ftp at
nexus.yorku.ca [130.63.9.66] in the directory pub/scheme/.
Scheme Implementations may also be found at altdorf.ai.mit.edu:/archive/
The Macintosh Common Lisp repository contains Lisp code for
MCL contributed by MCL users. It is available by anonymous ftp from
cambridge.apple.com:pub/MACL/CONTRIB [134.149.2.3]
and also contains the Info-MCL mailing list archives.
MIT AI Lab -- ftp.ai.mit.edu:pub/
loop-macro.tar [LOOP from CLtL]
series/ [SERIES from CLtL2]
Iterate/ [Alternative to series and loop.]
clmath.tar [Numeric math 1984]
xp/ [Waters' XP Lisp Pretty Printer]
The LispUsers Archives, a collection of programs for Medley, can be
found on nervous.cis.ohio-state.edu:pub/lispusers/medley. Also on
nervous.cis.ohio-state.edu is GTT, an implementation of Chandrasekaran's
Generic Tasks Toolset, in directory pub/lispusers/toolset.
There's a repository of Amiga LISP (and Lisp-like language)
implementations on gatekeeper.pa.dec.com:pub/micro/amiga/lisp/.
Common Lisp versions of the mini programs from "Inside Computer
Understanding" by Schank and Riesbeck, 1981, are available by anonymous ftp
from cs.umd.edu in the directory pub/schank. Contact Bill Andersen
(·······@cs.umd.edu) for more information. The directory pub/schank/icbr
contains the complete code for "Inside Case-Based Reasoning" by Riesbeck
and Schank, 1989.
Norvig:
The software from Peter Norvig's book "Paradigms of AI Programming" is
available by anonymous ftp from unix.sri.com:pub/norvig and on disk in
Macintosh or DOS format from the publisher, Morgan Kaufmann.
|
Software includes Common Lisp implementations of:
Eliza and pattern matchers, Emycin, Othello, Parsers,
Scheme interpreters and compilers, Unification and a prolog
interpreter and compiler, Waltz line-labelling,
implementation of GPS, macsyma, and random number generators.
|
For more information, contact:
Morgan Kaufmann, Dept. P1, 2929 Campus Drive, Suite 260
San Mateo CA 94403, (800) 745-7323; FAX: (415) 578-0672
A catalog of free and commercial natural language software
is available from the Natural Language Software Registry,
by anonymous ftp from tira.uchicago.edu [128.135.96.31] in
the directory /registry, or by email to ········@tira.uchicago.edu.
Other sites contain specific programs:
PCL -- parcftp.xerox.com:pcl/ [13.1.100.206]
Portable Common Loops (PCL) is a portable implementation of
the Common Lisp Object System (CLOS).
Gabriel Lisp Benchmarks are available by anonymous ftp as
ai.toronto.edu:/pub/gabriel-lisp-benchmarks.tar.Z.
GLisp -- apple.com:/pub/dts/mac/lisp/glisp.tar.Z
OBVIUS -- whitechapel.media.mit.edu:/pub/ [18.85.0.125]
Object-Based Vision and Image Understanding System (OBVIUS), is a Common
Lisp image processing package. Provides a library of image processing
routines (e.g., convolutions, fourier transforms, statistical
computations, etc.) on gray or binary images and image-sequences (no
color support yet), an X windows display interface, postscript printer
output, etc. It uses a homebrew interface to X11 (i.e., it does not use
clx or clue). However, they eventually hope to port Obvius to a clx/clue
platform. Written by David Heeger <······@white.stanford.edu> and Eero
Simoncelli <····@whitechapel.media.mit.edu>. Runs in Lucid-4.0. Includes
LaTeX documentation and User's Guide.
Scheme Utilities -- brokaw.lcs.mit.edu:/pub/scmutils.tar 18.30.0.33
GNU-Emacs -- prep.ai.mit.edu:
StarLisp Simulator -- think.com:/cm/starlisp/starsim-f19-sharfile
Simulates *Lisp, one of the programming langauges used to program
the Connection Machine. Runs under Symbolics, Lucid, Allegro, and Franz.
InterLisp->Common-Lisp Translator -- ai.sri.com:pub/pkarp/lisp/
MCS (Meta Class System) -- gmdzi.gmd.de:/pub/lisp/mcs/ [129.26.1.90]
Portable object-oriented extension to Common Lisp. Integrates the
functionality of CLOS (the Common Lisp Object System), and TELOS, (the
object system of LeLisp Version 16 and EULISP). MCS provides a metaobject
protocol which the user can specialize. MCS is claimed to be more
efficient in time and space than comparable systems we know, including
commercial CLOS implementations. Runs in any valid Common Lisp.
Contact: Harry Bretthauer and Juergen Kopp, German National Research
Center for Computer Science (GMD), Expert System Research Group,
P.O. Box 1240, D-5205 Sankt Augustin 1, FRG, email: ····@gmdzi.gmd.de
LMath -- ucbarpa.berkeley.edu:pub/fateman/lmath.* [128.32.130.11]
A Mathematica-style parser written in Common Lisp. Written by Richard
Fateman; ·······@renoir.Berkeley.EDU. Runs in any valid Common Lisp.
CLOS-on-KEE -- zaphod.lanl.gov:/pub/
A subset of CLOS that is implemented on top of KEE. Contact
·············@LANL.GOV (Skip Egdorf) for more info.
ftp.csrl.aoyama.ac.jp:
YY/ YY window toolkit sources
Lisp/ several common lisp sources, including MIT's FRL.
RRL (Rewrite Rule Laboratory) -- herky.cs.uiowa.edu [128.255.28.100]
TMYCIN -- sumex-aix.stanford.edu:/tmycin The TMYCIN rule based system.
NONLIN -- cs.umd.edu:/pub/nonlin (128.8.128.8)
Common Lisp implementation of the NONLIN planning system originally
designed and implemented by Austin Tate. Bugs can be reported to
···········@cs.umd.edu. User's group is ············@cs.umd.edu.
rascal.ics.utexas.edu:/pub/ 128.83.138.20
Maxima for Common Lisp (License required from National
Energy Software Center at Argonne.) Ported by Bill Schelter.
nqthm/ Boyer and Moore's theorem prover.
Also available from cli.com:/pub/nqthm.
proof-checker/ Matt Kaufmann's proof checking
enhancements to nqthm.
Eliza and similar programs. Besides Norvig's book, see:
o The doctor.el is an implementation of Eliza for
GNU-Emacs emacs-lisp. Invoke it with "Meta-X doctor"
o Source code for ELIZA in Prolog (implemented by Viren
Patel) is available by ftp from aisun1.ai.uga.edu.
o muLISP-87 (a MSDOS Lisp sold by Soft Warehouse) includes
a Lisp implementation of Eliza.
o Compute!'s Gazette, June 1984, includes source for a
BASIC implementation of Eliza. You can also find it
in 101 more computer games, edited by David Ahl,
published by Creative Computing (alas, they're defunct,
and the book is out of print).
o Herbert Schildt "Artificial Intelligence using C",
McGraw-Hill, 1987, ISBN 0-07-881255-0, pp315-338,
includes a simple version of DOCTOR.
BELIEF is a Common Lisp implementation of the Dempster and
Kong fusion and propagation algorithm for Graphical Belief
Function Models and the Lauritzen and Spiegelhalter algorithm
for Graphical Probabilistic Models. It is available by
anonymous ftp from hustat.harvard.edu and beligica.stat.washington.edu,
and by email from the author, Russell Almond <······@stat.washington.edu>.
A Common Lisp implementation of an ABTWEAK-like hierarchical
nonlinear planner may be obtained by anonymous ftp from
csis.dit.csiro.au in the directory pub/steve. A user's manual
and a copy of the associated masters thesis by Steve Woods
are also contained in that directory. Send mail to
············@csis.dit.csiro.au for more information.
Frame Languages:
o FrameWork is available in the Lisp Utilities Repository
described above.
o Theo (learning frame system) is available free from CMU, after
signing a license agreement. Send mail to ············@cs.cmu.edu.
o FrameKit is available free from CMU, after signing a
license agreement. Send mail to ···········@cs.cmu.edu
o KR. Send mail to ··········@cs.cmu.edu for more info.
o PARMENIDES (Frulekit) is available free, after signing
a license agreement. Send mail to ···········@cs.cmu.edu
o FROBS is available free by anonymous ftp from
cs.utah.edu:/pub/frobs.tar.Z
Contact Robert Kessler <·······@cs.utah.edu> for more info.
o PFC is a simple frame system written by Tim Finin
available free by anonymous ftp from linc.cis.upenn.edu.
The UMass GBB system (V1.2) is available by anonymous ftp from
dime.cs.umass.edu:/gbb. The commercial GBB product is not.
Work on the UMass GBB project (and funding) ended over 2 years ago.
Many researchers using it have opted for the commercial
release. The UMass research system remains available, but the
two should not be confused as the commercial system is
substantially improved and extended.
MVL (Multi-Valued Logic) is a theorem proving system written
in Common Lisp, and is available from t.stanford.edu:/mvl/mvl.tar.Z
A user's manual may be found in /mvl/manual.tex. Send mail
to ········@t.stanford.edu.
Postgres is an object-oriented database, and is available
from postgres.berkeley.edu:/pub/postgres*
It runs on DecStation 3100s, Sun3 (SunOs), Sun4 (Sparc),
and Sequent Symmetry.
CL-Protos is a Common Lisp implementation of the case-based
reasoning system developed by E. Ray Bareiss and Bruce W.
Porter of the University of Texas/Austin AI Lab. It runs
on Sun3, TI Explorer, HP 9000, and Symbolics, and gobbles a
huge amount of memory. Common Lisp implementation by
Rita Duran, Dan Dvorak, Jim Kroger, Hilel Swerdlin, and Ben Tso.
For more information, bug reports, or comments, contact
either Dan Dvorak <······@cs.utexas.edu> or Ray Bareiss
<·······@ils.nwu.edu> or Erik Eilerts <·······@cs.utexas.edu>
Available by anonymous ftp from cs.utexas.edu:/pub/porter
QSIM is a qualitative reasoning system implemented in Common
Lisp. It is available by anonymous ftp from cs.utexas.edu:/pub/qsim
RHETORICAL is a planning and knowledge tool available by
anonymous ftp from cs.rochester.edu:/pub/knowledge-tools
in the files rhet-19-40.tar.Z and cl-lib-3-11.tar.Z. The files
tempos-3-6.tar.Z and timelogic-5-0.tar.Z add James Allen's
interval logic to Rhet. It runs on Symbolics Genera and
Allegro Common Lisp. Written by Brad Miller <······@cs.rochester.edu>.
KNOWBEL is an implementation of Telos (a sorted/temporal logic
system) by Bryan M. Kramer, <······@ai.toronto.edu>. It is
available by anonymous ftp from ai.toronto.edu:/pub/kr/ as the
files knowbel.tar.Z and manual.txt.tar.Z
Runs in Allegro CL on Sparcstations and Silicon Graphics 4d
and in MCL on Apple Macintoshes.
SNePS is a semantic net implementation, available free after
signing a license agreement. Contact ·······@cs.buffalo.edu
for more information.
PRODIGY is an integrated planning and learning system,
available free after signing a license agreement. Contact
·······@cs.cmu.edu for more information.
SOAR is an integrated intelligent agent architecture. It is
available free after signing a license agreement. Contact
············@cs.cmu.edu for more information.
RegExp is an extension to Allegro Common Lisp which adds
regular expression string matching, using the foreign
function interface. Available by anonymous ftp from
ai.sri.com:/pub/pkarp/regexp/. Contact ·····@ai.sri.com
for more information.
SNLP is a domain independent systematic nonlinear planner,
available by anonymous ftp from cs.washington.edu:/pub/snlp.tar.Z
Contact ····@cs.washington.edu for more information.
TILEWORLD is a planning testbed/simulator developed at SRI
International by Martha Pollack, Michael Frank and Marc
Ringuette. TILEWORLD originally ran under Lucid CL, but was
later extended and ported to Allegro CL by Badr H. Al-Badr
and Steve Hanks. The new tileworld is available by anonymous
ftp from cs.washington.edu as the file new-tileworld.tar.Z
It includes an X interface.
TRUCKWORLD is a simulated world intended to provide a
testbed for AI planning programs, where the planning agent
is a truck that roams around the simulated world. It is
available by anonymous ftp from cs.washington.edu in the
file simulator.tar.Z. It includes an X interface. Contact
Steve Hanks <·····@cs.washington.edu> for more information.
COBWEB/3 is a concept formation system available free after
signing a license agreement. Contact ······@ptolemy.arc.nasa.gov
for more information.
----------------------------------------------------------------
[10] Is there a GNU-Emacs interface to Lisp?
ILISP is a powerful GNU-Emacs interface to many dialects of
Lisp, including Lucid, Allegro, {A}KCL, IBCL, and CMU. Written by
Chris McConnell <····@cs.cmu.edu>. It is available by anonymous
ftp from atmandu.mt.cs.cmu.edu [128.2.250.68] in the directory
pub/ilisp as the file ilisp.tar.Z. If you start using it, send
Chris mail, as he maintains a mailing list of users.
Franz Inc.'s GNU-Emacs/Lisp interface includes an online Common
Lisp manual. It is available by anonymous ftp from
uunet.uu.net:/lisp/emacs-lisp-1.5.2.tar.Z
ucbvax.berkeley.edu:/pub/franzinc/emacs-lisp-interface/1.5.2.tar.Z
Send bug reports to ····@franz.com. To be added to the mailing
list, send mail to ························@ucbarpa.berkeley.edu.
Lucid includes some other Emacs-Lisp interfaces in its goodies directory.
----------------------------------------------------------------
[11] How can I use the X Window System from Lisp?
There are several GUI's and Lisp interfaces to the X Window System. Mailing
lists for these systems are listed in the answer to question [8].
Various vendors also offer their own interface-building packages.
CLX provides basic Common Lisp/X functionality. It is a de facto standard
low-level interface to X, providing equivalent functionality to XLib, but
in Lisp. It is also a good source for comparing the foreign function calls
in various Lisps. Does *not* depend on CLOS. Available free as part of the
X release in the contrib directory. Also available form
export.lcs.mit.edu:/contrib as the files CLX.Manual.tar.Z, CLX.R4.5.tar.Z
and CLX.R5.tar.Z Primary Interface Author: Robert W. Scheifler
<···@zermatt.lcs.mit.edu> Send bug reports to ·······@expo.lcs.mit.edu.
CLIM (Common Lisp Interface Manager) is a GUI originally developed by
Symbolics and International Lisp Associates, and now under joint
development by several Lisp vendors, including Symbolics, Franz, and Lucid.
It is intended to be a portable analogue of Symbolics UIMS (Dynamic
Windows, Presentations Types). It runs on Symbolics Lisp Machines; Allegro
and Lucid on several Unix platforms; Symbolics CLOE on 386/486 IBM
PCs running Windows; and MCL on Apple Macintoshes. It is *not*
free, and with the exception of Macintoshes, if it is available it
can be purchased from the vendor of the Lisp system you are using.
For the Macintosh version write to the ILA:
International Lisp Associates, 114 Mt. Auburn St.,
Cambridge, MA 02138, 617-576-1151
Contact: Dennis Doughty - ·······@ILA.com
International Lisp Associates, 898 Windmill Park Road,
Mountain View, CA 94043, 1-800-477-CLIM
Contact: Bill York - ····@ILA.com
CLUE (Common Lisp User-Interface Environment) is from TI, and extends CLX
to provide a simple, object-oriented toolkit (like Xt) library that uses
CLOS. Provides basic window classes, some stream I/O facilities, and a few
other utilities. Still pretty low level (it's a toolkit, not widget
library). Available free by anonymous ftp from csc.ti.com:pub/clue.tar.Z
Written by Kerry Kimbrough. Send bug reports to ·········@dsg.csc.ti.com.
CLIO (Common Lisp Interactive Objects) is a GUI from the people who created
CLUE. It provides a set of CLOS classes that represent the standard
components of an object-oriented user interface -- such as text, menus,
buttons, scroller, and dialogs. It is included as part of the CLUE
distribution, along with some packages that use it, both sample and real.
Allegro Common Windows provides a front end to CLX. Uses CLOS.
It is *not* free. Contact ····@franz.com for more information.
The LispWorks Toolkit is an extensible CLOS-based widget set that uses
CLX and CLUE. The LispWorks programming environment has been written
using the toolkit and includes: an Emacs-like editor, listener,
debugger, profiler, and operating system shell; browsers/graphers for
classes, generic functions, processes, windows, files, compilation
errors, source code systems, and setting LispWorks parameters; and an
interactive interface builder and complete online hypertext
documentation. Contact: ·················@harlqn.co.uk
CLM (Common Lisp Motif) and GINA (Generic Interactive Application) and IB
(Interface Builder). CLM runs Motif widgets in a separate C process, with
minimal work on the Lisp side and communicates between C and Lisp using TCP
sockets. Runs in Allegro CL, Sun CL, and Symbolics Genera. GINA uses CLOS.
Available free in the X contrib directory or by anonymous ftp from either
export.lcs.mit.edu:/contrib or ftp.gmd.de:/gmd/gina [129.26.8.90] as the
files CLM+GINA.README, CLM2.1.tar.Z and GINA2.1.tar.Z. CLM was written by
Andreas Baecker <·······@gmdzi.gmd.de>, GINA by Mike Spenke
<······@gmdzi.gmd.de>, and IB by Thomas Berlage <·······@gmdzi.gmd.de>.
Contact Mike Spenke for more info.
EW (Express Windows) is intended to mimic Symbolics' Dynamic Windows user
and programmer interfaces. It is available free in the ew/ subdirectory of
the Lisp Utilities repository. It is no longer under active development.
Runs on Sun/Lucid, Franz Allegro, and Symbolics. Should port easily to
other Lisps with CLX.
Written by Andrew L. Ressler <········@oiscola.columbia.ncr.com>.
Garnet is a large and flexible GUI. Lots of high-level features. Does
*not* depend on CLOS, but does depend on CLX. Available free, after signing
a license agreement. Contact Brad Myers (···@a.gp.cs.cmu.edu) for more
information. Bug reports: ······@cs.cmu.edu.
LispView is a GUI written at Sun that does not use CLX. Instead it
converts Xlib.h directly into Lucid foreign function calls. It is intended
to be fast and tight. Uses CLOS. Available for anonymous ftp from
export.lcs.mit.edu:contrib/lispview1.1 and
xview.ucdavis.edu:pub/XView/LispView1.1
Written by Hans Muller (·······@sun.com). Runs in Sun CL and Lucid CL.
Direct questions about the source provision to ········@Eng.Sun.Com.
WINTERP (Widget Interpreter) was developed at HP and uses the Xtoolkit and
Motif widget set. It is based on David Betz's XLISP interpreter, which is a
small subset of Common Lisp that runs on IBM PCs. Runs on DecStation 3100,
HP9000s, Sun3, Sparcs. It is a free-standing Lisp-based tool for setting
up window applications. Available free in X contrib directory, or by
anonymous ftp from export.lcs.mit.edu:contrib/winterp-???.tar.Z where ???
is the version number. If you do not have Internet access you may request
the source code to be mailed to you by sending a message to
·····················@hplabs.hp.com or hplabs!hplnpm!winterp-source.
Contact Niels Mayer ·····@hplabs.hp.com for more information.
YYonX is a port of the YY system to X windows. Runs in Lucid CL, Allegro
CL, and Symbolics Genera. Supports kanjii. Developed at Aoyama Gakuin
University. Available free by anonymous ftp from ftp.csrl.aoyama.ac.jp:YY/
Written by Masayuki Ida <···@cc.aoyama.ac.jp>
Picasso is a CLOS based GUI, and is available from
postgres.berkeley.edu:/pub/Picasso-2.0 It runs on DecStation 3100s, Sun3
(SunOs), Sun4 (Sparc), and Sequent Symmetry in Allegro CL. The file
pub/xcl.tar.Z contains X-Common Lisp interface routines. Send mail to
·······@postgres.berkeley.edu for more information.
----------------------------------------------------------------
[12] What does CLOS, PCL, X3J13, CAR, CDR, ... mean?
What is CLOS (PCL) and where can I get it?
How do you pronounce CLOS?
Glossary of acronyms:
CAR Originally meant "Contents of Address portion of Register",
which is what CAR actually did on the IBM 704.
CDR Origianlly meant "Contents of Decrement portion of
Register", which is what CDR actually did
on the IBM 704. Pronounced "Cudder".
LISP Originally from "LISt Processing"
GUI Graphical User Interface
CLOS Common Lisp Object System. The object oriented
programming standard for Common Lisp. Based on
Symbolics FLAVORS and Xerox LOOPS, among others.
Pronounced either as "See-Loss" or "Closs".
PCL Portable Common Loops. A portable CLOS implementation.
Available by anonymous ftp from parcftp.xerox.com:pcl/.
LOOPS Lisp Object Oriented Programming System. A predecessor
to CLOS on Xerox Lisp machines.
X3J13 Subcommittee of the ANSI committee X3 which is
working on the ANSI Standardization of Common Lisp.
ANSI American National Standards Institute
CL Common Lisp
SC22/WG16 The full name is ISO/IEC JTC 1/SC 22/WG 16. It stands
for International Organization for
Standardization/International Electronics(?)
Congress(?) Joint Technical Committee 1, Subcommittee 22,
Working Group 16. This long-winded name is the ISO
working group working on an international Lisp standard,
(i.e., the ISO analogue to X3J13).
CLtL1 First edition of Guy Steele's book,
"Common Lisp the Language".
CLtL2 Second edition of Guy Steele's book,
"Common Lisp the Language".
SICP Abelson and Sussman's book "Structure and
Interpretation of Computer Programs".
SCOOPS An experimental object-oriented programming
language for Scheme.
R3RS Revised^3 Report on the Algorithmic Language Scheme.
R4RS Revised^4 Report on the Algorithmic Language Scheme.
----------------------------------------------------------------
[14] Why does (READ-FROM-STRING "foobar" :START 3) return FOOBAR instead
of BAR?
READ-FROM-STRING is one of the rare functions that takes both &OPTIONAL and
&KEY arguments. When a function takes both types of arguments, all the
optional arguments must be specified explicitly before any of the keyword
arguments may be specified. In the example above, :START becomes the value
of the optional EOF-ERROR-P parameter and 3 is the value of the optional
EOF-VALUE parameter.
----------------------------------------------------------------
[15] Why can't it deduce from (READ-FROM-STRING "foobar" :START 3) that
the intent is to specify the START keyword parameter rather than
the EOF-ERROR-P and EOF-VALUE optional parameters?
In Common Lisp, keyword symbols are first-class data objects. Therefore,
they are perfectly valid values for optional parameters to functions.
There are only four functions in Common Lisp that have both optional and
keyword parameters (they are PARSE-NAMESTRING, READ-FROM-STRING,
WRITE-LINE, and WRITE-STRING), so it's probably not worth adding a
nonorthogonal kludge to the language just to make these functions slightly
less confusing; unfortunately, it's also not worth an incompatible change
to the language to redefine those functions to use only keyword arguments.
----------------------------------------------------------------
[16] How can I write a function that can access defstruct slots by name? I
would like to write something like (STRUCTURE-SLOT <object>
'<slot-name>).
There is currently no portable, built-in way to access structure slots
given only the name. If your Common Lisp includes an implementation of
CLOS that supports the meta-object protocol specified in the original X3J13
draft spec (document X3J13/88-003), then it should allow (SLOT-VALUE
<object> '<slot-name>); however, not all implementations of CLOS currently
provide this. Lacking this, some implementations may provide
implementation-dependent functions that allow access to structure slots by
name; note that this may cause saved images to be larger, as some
implementations normally open-code structure accessors and discard slot
name information.
While it is not possible to write a fully general STRUCTURE-SLOT function,
it is not very difficult to write version that handles specific structure
types. For instance, after defining:
(defstruct spaceship name captain position velocity)
one may then define:
(defun spaceship-slot (spaceship slot-name)
(ecase slot-name
(name (spaceship-name spaceship))
(captain (spaceship-captain spaceship))
(position (spaceship-position spaceship))
(velocity (spaceship-velocity spaceship))))
Another popular way to define this is:
(defun spaceship-slot (spaceship slot-name)
(funcall (symbol-function
(find-symbol (format nil "SPACESHIP-~A" slot-name)
#.(package-name *package*)))
spaceship))
I personally recommend the first version. It is likely to be much faster
and more memory efficient than the second version. It's also easy to get
the second one wrong; many people forget to specify the package argument to
FIND-SYMBOL, which can cause incorrect results when the package at run time
is different from the one at compile time. Even my version assumes that
SPACESHIP-SLOT is being defined in a file that is in the same package as
the one containing the structure definition; if this isn't the case,
#.(PACKAGE-NAME *PACKAGE*) should be replaced by a string naming the
correct package.
Another workaround is to define a MY-DEFSTRUCT macro that parses the
defstruct arguments and expands into a call to DEFSTRUCT along with a
definition of the runtime slot-accessor function.
Some non-portable techniques include the use of LCL:STRUCTURE-REF
in Lucid and EXCL:STRUCTURE-REF in Allegro.
----------------------------------------------------------------
[17] Why can't I apply #'AND and #'OR?
Here's the simple, but not necessarily satisfying, answer: AND and OR are
macros, not functions; APPLY and FUNCALL can only be used to invoke
functions, not macros and special operators.
OK, so what's the *real* reason? The reason that AND and OR are macros
rather than functions is because they implement control structure in
addition to computing a boolean value. They evaluate their subforms
sequentially from left/top to right/bottom, and stop evaluating subforms as
soon as the result can be determined (in the case of AND, as soon as a
subform returns NIL; in the case of OR, as soon as one returns non-NIL);
this is referred to as "short circuiting" in computer language parlance.
APPLY and FUNCALL, however, are ordinary functions; therefore, their
arguments are evaluated automatically, before they are called. Thus, were
APPLY able to be used with #'AND, the short-circuiting would be defeated.
Perhaps you don't really care about the short-circuiting, and simply want
the functional, boolean interpretation. While this may be a reasonable
interpretation of trying to apply AND or OR, it doesn't generalize to other
macros well, so there's no obvious way to have the Lisp system "do the
right thing" when trying to apply macros. The only function associated
with a macro is its expander function; this function accepts and returns
and form, so it cannot be used to compute the value.
The Common Lisp functions EVERY and SOME can be used to get the
functionality you intend when trying to apply #'AND and #'OR. For
instance, the erroneous form:
(apply #'and *list*)
can be translated to the correct form:
(every #'identity *list*)
----------------------------------------------------------------
[18] When is it right to use EVAL?
Hardly ever. Any time you think you need to use EVAL, think hard about it.
EVAL is useful when implementing a facility that provides an external
interface to the Lisp interpreter. For instance, many Lisp-based editors
provide a command that prompts for a form and displays its value.
Inexperienced macro writers often assume that they must explicitly EVAL the
subforms that are supposed to be evaluated, but this is not so; the correct
way to write such a macro is to have it expand into another form that has
these subforms in places that will be evaluated by the normal evaluation
rules. Explicit use of EVAL in a macro is likely to result in one of two
problems: the dreaded "double evaluation" problem, which may not show up
during testing if the values of the expressions are self-evaluating
constants (such as numbers); or evaluation at compile time rather than
runtime. For instance, if Lisp didn't have IF and one desired to write it,
the following would be wrong:
(defmacro if (test then-form &optional else-form)
;; this evaluates all the subforms at compile time, and at runtime
;; evaluates the results again.
`(cond (,(eval test) ,(eval then-form))
(t ,(eval else-form))))
(defmacro if (test then-form &optional else-form)
;; this double-evaluates at run time
`(cond ((eval ,test) (eval ,then-form))
(t (eval ,else-form)))
This is correct:
(defmacro if (test then-form &optional else-form)
`(cond (,test ,then-form)
(t ,else-form)))
----------------------------------------------------------------
[19] I used a destructive function (e.g. DELETE, SORT), but it didn't seem to
work. Why?
I assume you mean that it didn't seem to modify the original list. There
are several possible reasons for this. First, many destructive functions
are not *required* to modify their input argument, merely *allowed* to; in
some cases, the implementation may determine that it is more efficient to
construct a new result than to modify the original (this may happen in Lisp
systems that use "CDR coding", where RPLACD may have to turn a CDR-NEXT or
CDR-NIL cell into a CDR-NORMAL cell), or the implementor may simply not
have gotten around to implementing the destructive version in a truly
destructive manner. Another possibility is that the nature of the change
that was made involves removing elements from the front of a list; in this
case, the function can simply return the appropriate tail of the list,
without actually modifying the list. And example of this is:
(setq *a* (list 3 2 1))
(delete 3 *a*) => (2 1)
*a* => (3 2 1)
Similarly, when one sorts a list, SORT may destructively rearrange the
pointers (cons cells) that make up the list. SORT then returns the cons
cell that now heads the list; the original cons cell could be anywhere in
the list. The value of any variable that contained the original head of the
list hasn't changed, but the contents of that cons cell have changed
because SORT is a destructive function:
(setq *a* (list 2 1 3))
(sort *a* #'<) => (1 2 3)
*a* => (2 3)
In both cases, the remedy is the same: store the result of the
function back into the place whence the original value came, e.g.
(setq *a* (delete 3 *a*))
*a* => (2 1)
Why don't the destructive functions do this automatically? Recall that
they are just ordinary functions, and all Lisp functions are called by
value. Therefore, these functions do not know where the lists they are
given came from; they are simply passed the cons cell that represents the
head of the list. Their only obligation is to return the new cons cell that
represents the head of the list.
One thing to be careful about when doing this is that the original list
might be referenced from multiple places, and all of these places may need
to be updated. For instance:
(setq *a* (list 3 2 1))
(setq *b* *a*)
(setq *a* (delete 3 *a*))
*a* => (2 1)
*b* => (3 2 1) ; *B* doesn't "see" the change
(setq *a* (delete 1 *a*))
*a* => (2)
*b* => (3 2) ; *B* sees the change this time, though
One may argue that destructive functions could do what you expect by
rearranging the CARs of the list, shifting things up if the first element
is being deleted, as they are likely to do if the argument is a vector
rather than a list. In many cases they could do this, although it would
clearly be slower. However, there is one case where this is not possible:
when the argument or value is NIL, and the value or argument, respectively,
is not. It's not possible to transform the object referenced from the
original cell from one data type to another, so the result must be stored
back. Here are some examples:
(setq *a* (list 3 2 1))
(delete-if #'numberp *a) => NIL
*a* => (3 2 1)
(setq *a* nil *b* '(1 2 3))
(nconc *a* *b*) => (1 2 3)
*a* => NIL
The names of most destructure functions (except for sort, delete,
rplaca, rplacd, and setf of accessor functions) have the prefix N.
In summary, the two common problems to watch out for when using
destructive functions are:
1. Forgetting to store the result back. Even though the list
is modified in place, it is still necessary to store the
result back into the original location, e.g.,
(setq foo (delete 'x foo))
If the original list was stored in multiple places, you may
need to store it back in all of them, e.g.
(setq bar foo)
...
(setq foo (delete 'x foo))
(setq bar foo)
2. Sharing structure that gets modified. If it is important
to preserve the shared structure, then you should either
use a nondestructive operation or copy the structure first
using COPY-LIST or COPY-TREE.
(setq bar (cdr foo))
...
(setq foo (sort foo #'<))
;;; now it's not safe to use BAR
Note that even nondestructive functions, such as REMOVE and UNION, can
return a result which shares structure with an argument.
Nondestructive functions don't necessarily copy their arguments; they
just don't modify them.
----------------------------------------------------------------
[20] After I NREVERSE a list, it's only one element long. After I SORT
a list, it's missing things. What happened?
These are particular cases of the previous question. Many NREVERSE and
SORT implementations operate by rechaining all the CDR links in the list's
backbone, rather than by replacing the CARs. In the case of NREVERSE, this
means that the cons cell that was originally first in the list becomes the
last one. As in the last question, the solution is to store the result
back into the original location.
----------------------------------------------------------------
[21] What is the equivalent of EXPLODE and IMPLODE in Common Lisp?
Hopefully, the only reason you need to do this is as part of trying to port
some old MacLisp code to Common Lisp. These functions predated the
inclusion of strings as a first-class data type in Lisp; symbols were used
as strings, and they ere EXPLODEd to allow the individual characters to be
manipulated in a list.
Probably the best approximations of these are:
(defun explode (object)
(loop for char across (prin1-to-string object)
collect (intern (string char))))
(defun implode (list)
(read-from-string (coerce (mapcar #'character list) 'string)))
An alternate definition of EXPLODE which uses MAP instead of LOOP is:
(defun explode (object)
(map 'list #'(lambda (char)
(intern (string char)))
(prin1-to-string 'foo)))
The creation of N conses of garbage to process a string of N
characters is a hideously inefficient way of doing the job. Rewrite
EXPLODE code with PRIN1-TO-STRING, or better STRING if the arguments
are symbols without funny characters. For IMPLODE, try to make its
caller use strings and try to make the result usable as a string to
avoid having to call INTERN or READ-FROM-STRING.
----------------------------------------------------------------
[22] Is Lisp inherently slower than more conventional languages such as C?
This is a tough question to answer, as I'm sure you expected. In many
cases, it appears to be. Lisp does not require the programmer to specify
the data type of variables, so generic arithmetic operators may have to
perform type checking at runtime in order to determine how to proceed.
However, Lisp code can also be dense (i.e. there is more expressed in a
single line) than many other languages: the Lisp expression (+ A B) is more
powerful than the C expression A+B (the Lisp version supports bignums,
rationals, and complex numbers, while the C version only supports
limited-size integers and floating point); therefore, one may claim that it
is reasonable that the Lisp version take longer than the C version (but
don't expect everyone to accept this rationalization). Solutions to this
include hardware support (e.g. processors that support type tags in data,
such as SPARC and Symbolics Lisp Machines), declarations, and specialized
variants of functions (e.g. in MacLisp, + accepts and returns only fixnums,
+$ accepts and returns only flonums, and PLUS is generic).
At one time, the MIT PDP-10 MacLisp compiler was compared to DEC's PDP-10
Fortran compiler. When appropriate declarations were supplied in the Lisp
code, the performance of compiled Lisp arithmetic rivaled that of the
Fortran code. It would hardly be fair to compare Lisp without declarations
to Fortran, since the Fortran compiler would have more information upon
which it could base its optimizations.
Since Lisp is a good language for rapid prototyping, it is easy for a
mediocre programmer (or even a good programmer, who isn't being careful) to
generate a large amount of inefficient Lisp code. A good example is the use
of APPEND to link successive lists together, instead of keeping a pointer
to the tail of the list. Often a programmer can obtain significant
speed increases by using a time/space profiler to identify the
functions which waste time (often small functions which are called
frequently) and rewriting those functions.
----------------------------------------------------------------
[23] Why does my program's behavior change each time I use it?
Most likely your program is altering itself, and the most common way this
may happen is by performing destructive operations on embedded constant
data structures. For instance, consider the following:
(defun one-to-ten-except (n)
(delete n '(1 2 3 4 5 6 7 8 9 10)))
(one-to-ten-except 3) => (1 2 4 5 6 7 8 9 10)
(one-to-ten-except 5) => (1 2 4 6 7 8 9 10) ; 3 is missing
The DELETE function destructively modified the list that is actually a part
of the lambda expression that is in ONE-TO-TEN-EXCEPT's function cell. The
next time that the function is called, this modified list is used.
In some implementations the result of calling ONE-TO-TEN-EXCEPT may even be
that an error is signalled or the Lisp process aborts completely. Some
Lisp implementations put self-evaluating and quoted constants onto memory
pages that are marked read-only, in order to catch bugs such as this.
All of these behaviors are allowed by the draft ANSI Common Lisp
specification, which specifically states that the consequences of modifying
a constant are undefined.
----------------------------------------------------------------
[24] Why does Common Lisp have "#'"?
#' is a macro-character which expands #'FOO to (FUNCTION FOO). Symbols in
Lisp have two bindings, one for values and one for functions, allowing them
to represent both variables and functions, depending on context. #'FOO
accesses FOO's lexical function binding in a context where the value
interpretation would normally occur. #' is also used to create lexical
closures for lambda expressions. A lexical closure is a function which when
invoked executes the body of the lambda-expression in the lexical
environment within which the closure was created. See pp. 115-117 of CLtL2
for more details.
----------------------------------------------------------------
[25] How can I list all the CLOS instances in a class?
There is no built-in way to enumerate the instances of a class. If you are
only interested in listing the instances of classes that you have defined,
it is not very difficult to implement it as part of your class definition.
Add a shared slot, e.g. ALL-INSTANCES, with an initial value of NIL, to the
class definition. Then write an after-method on INITIALIZE-INSTANCE for
this class, which pushes the instance being initialized onto ALL-INSTANCES.
Note that this must done separately for each class that wants to maintain
such a list; it can't be encapsulated in a mixin class, because all its
dependent classes would share the same ALL-INSTANCES slot. A compromise
would be to use a mixin to define the INITIALIZE-INSTANCE after-method (and
any other general-purpose methods that use the slot), but not the shared
slot; it would be up to the descendent classes to define the slot at the
level of the class hierarchy that is appropriate.
----------------------------------------------------------------
[26] How do I call non-Lisp functions from Lisp?
Most Lisp implementations for systems where Lisp is not the most common
language provide a "foreign function" interface. As of now there has been
no significant standardization effort in this area. They tend to be
similar, but there are enough differences that it would be inappropriate to
try to describe them all here. In general, one uses an
implementation-dependent macro that defines a Lisp function, but instead of
supplying a body for the function supplies the name of a function written
in another language; the argument list portion of the definition is
generally augmented with the data types the foreign function expects and
the data type of the foreign function's return value, and the Lisp
interface function arranges to do any necessary conversions. There is also
generally a function to "load" an object file or library compiled in a
foreign language, which dynamically links the functions in the file being
loaded into the address space of the Lisp process, and connects the
interface functions to the corresponding foreign functions.
IF you need to do this, see the manual for your language implementation for
full details. In particular, be on the lookout for restrictions on the
data types that may be passed. You may also need to know details about the
linkage conventions that are used on your system; for instance, many C
implementations prepend an underscore onto the names of C functions when
generating the assembler output (this allows them to use names without
initial underscores internally as labels without worrying about conflicts),
and the foreign function interface may require you to specify this form
explicitly.
----------------------------------------------------------------
[27] Can I call Lisp functions from other languages?
In implementations that provide a foreign function interface as described
above, there is also usually a "callback" mechanism. The programmer may
associate a foreign language function name with a Lisp function. When a
foreign object file or library is loaded into the Lisp address space, it is
linked with these callback functions. As with foreign functions, the
programmer must supply the argument and result data types so that Lisp may
perform conversions at the interface.
----------------------------------------------------------------
[28] Why does (READ-LINE) return "" immediately instead of waiting for
me to type a line?
Many Lisp implementations on line-buffered systems do not discard the
newline that the user must type after the last right parenthesis in order
for the line to be transmitted from the OS to Lisp. Lisp's READ function
returns immediately after seeing the matching ")" in the stream. When
READLINE is called, it sees the next character in the stream, which is a
newline, so it returns an empty line. If you were to type "(read-line)This
is a test" the result would be "This is a test".
The simplest solution is to use (PROGN (CLEAR-INPUT) (READ-LINE)). This
discards the buffered newline before reading the input. However, it would
also discard any other buffered input, as in the "This is a test" example
above; some implementation also flush the OS's input buffers, so typeahead
might be thrown away.
----------------------------------------------------------------
[29] I typed a form to the read-eval-print loop, but nothing happened. Why?
There's not much to go on here, but a common reason is that you haven't
actually typed a complete form. You may have typed a doublequote, vertical
bar, "#|" comment beginning, or left parenthesis that you never matched
with another doublequote, vertical bar, "|#", or right parenthesis,
respectively. Try typing a few right parentheses followed by Return.
----------------------------------------------------------------
[30] I want to call a function in a package that might not exist at
compile time. How do I do this?
Use (funcall (find-symbol :symbol-name :pkg-name) ...).
----------------------------------------------------------------
[31] What is CDR-coding?
CDR-coding is a space-saving way to store lists in memory. It is normally
only used in Lisp implementations that run on processors that are
specialized for Lisp, as it is difficult to implement efficiently
in software. In normal list structure, each element of the
list is represented as a CONS cell, which is basically two pointers (the
CAR and CDR); the CAR points to the element of the list, while the CDR
points to the next CONS cell in the list or NIL. CDR-coding takes
advantage of the fact that most CDR cells point to another CONS, and
further that the entire list is often allocated at once (e.g. by a call to
LIST). Instead of using two pointers to implement each CONS cell, the CAR
cell contains a pointer and a two-bit "CDR code". The CDR code may contain
one of three values: CDR-NORMAL, CDR-NEXT, and CDR-NIL. If the code is
CDR-NORMAL, this cell is the first half of an ordinary CONS cell pair, and
the next cell in memory contains the CDR pointer as described above. If
the CDR code is CDR-NEXT, the next cell in memory contains the next CAR
cell; in other words, the CDR pointer is implicitly thisaddress+1, where
thisaddress is the memory address of the CAR cell. If the CDR code is
CDR-NIL, then this cell is the last element of the list; the CDR pointer is
implicitly a reference to the object NIL. When a list is constructed
incrementally using CONS, a chain of ordinary pairs is created; however,
when a list is constructed in one step using LIST or MAKE-LIST, a block of
memory can be allocated for all the CAR cells, and their CDR codes all set
to CDR-NEXT (except the last, which is CDR-NIL), and the list will only
take half as much storage (because all the CDR pointers are implicit).
If this were all there were to it, it would not be difficult to implement
in software on ordinary processors; it would add a small amount of overhead
to the CDR function, but the reduction in paging might make up for it. The
problem arises when a program uses RPLACD on a CONS cell that has a CDR
code of CDR-NEXT or CDR-NIL. Normally RPLACD simply stores into the CDR
cell of a CONS, but in this case there is no CDR cell -- its contents are
implicitly specified by the CDR code, and the word that would normally
contain the CDR pointer contains the next CONS cell (in the CDR-NEXT case)
to which other data structures may have pointers, or the first word of some
other object (in the CDR-NIL case). When CDR-coding is used, the
implementation must also provide automatic "forwarding pointers"; an
ordinary CONS cell is allocated, the CAR of the original cell is copied
into its CAR, the value being RPLACD'ed is stored into its CDR, and the old
CAR cell is replaced with a forwarding pointer to the new CONS cell.
Whenever CAR or CDR is performed on a CONS, it must check whether the
location contains a forwarding pointer. This overhead on both CAR and CDR,
coupled with the overhead on CDR to check for CDR codes, is generally
enough that using CDR codes on conventional hardware is infeasible.
There is some evidence that CDR-coding doesn't really save very much
memory, because most lists aren't constructed at once, or RPLACD is done on
them enough that they don't stay contiguous. At best this technique can
save 50% of the space occupied by CONS cells. However, the savings probably
depends to some extent upon the amount of support the implementation
provides for creating CDR-coded lists. For instance, many system functions
on Symbolics Lisp Machines that operate on lists have a :LOCALIZE option;
when :LOCALIZE T is specified, the list is first modified and then copied
to a new, CDR-coded block, with all the old cells replaced with forwarding
pointers. The next time the garbage collector runs, all the forwarding
pointers will be spliced out. Thus, at a cost of a temporary increase in
memory usage, overall memory usage is generally reduced because more lists
may be CDR-coded. Nevertheless, modern Lisps tend to use lists much less
frequently, with a much heavier reliance upon code, strings, and vectors
(structures).
----------------------------------------------------------------
[32] What is garbage collection?
Garbage Collection (GC) refers to the automatic storage allocation
mechanisms present in many Lisps. There are several kinds of storage
allocation algorithms, but most fall within two main classes:
1. Stop and Copy. Systems which copy active objects from "old"
storage to "new" storage and then recycle the old storage.
2. Mark and Sweep. Systems which link together storage
used by discarded objects.
Generational scavenging garbage collection is a variation on the first
type, in which memory is allocated in layers, with tenured (long-lived)
objects in the older layers. Rather than doing a full GC of all of memory
every time more room is needed, only the last few layers are GCed during an
ephemeral GC, taking much less time. Short-lived objects are quickly
recycled, and full GCs are then much less frequent. (Actually, it is
possible to implement ephemeral GC in mark and sweep systems, just much
more difficult).
Stop and copy garbage collection provides simpler storage allocation,
avoids fragmentation of memory (intermixing of free storage with used
storage). Copying, however, consumes more of the address space, since up to
half the space must be kept available for copying all the active objects.
This makes stop and copy GC impractical for systems with a small address
space or without virtual memory. Also, copying an object requires that you
track down all the pointers to an object and update them to reflect the new
address, while in a non-copying system you need only keep one pointer to an
object, since its location will not change. It is also more difficult to
explicitly return storage to free space in a copying system.
Garbage collection is not part of the Common Lisp standard. Most Lisps
provide a function ROOM which provides human-readable information about the
state of storage usage. In many Lisps, (gc) invokes an ephemeral garbage
collection, and (gc t) a full garbage collection.
----------------------------------------------------------------
[33] How do I save an executable image of my loaded Lisp system?
There is no standard for dumping a Lisp image. Here are the
commands from some lisp implementations:
Lucid: DISKSAVE
Symbolics: Save World [CP command]
CMU CL: SAVE-LISP
Franz Allegro: EXCL:DUMPLISP (documented)
SAVE-IMAGE (undocumented)
Medley: IL:SYSOUT or IL:MAKESYS
----------------------------------------------------------------
[34] I'm porting some code from a Symbolics Lisp machine to some
other platform, and there are strange characters in the code.
What do they mean?
The Symbolics Zetalisp character set includes the following
characters not present in other Lisps:
^] >= greater than or equal to
^\ <= less than or equal to
^Z != not equal to
^^ == equivalent to
^E not
^G pi
^L +/- plus/minus
^H lambda
^F epsilon
^W <--> left/right arrow
^X <-- left arrow
^Y --> right arrow
Other special characters to look out for are the font-change characters,
which are represented as a ^F followed by a digit or asterisk. A digit
means to push font #N onto the stack; an asterisk means to pop the most
recent font from the stack. You can clean up the code by replacing "\^F."
with "".
----------------------------------------------------------------
[35] History: Where did Lisp come from?
John McCarthy developed the basics behind Lisp during the 1956 Dartmouth
Summer Research Project on Artificial Intelligence. He intended it as an
algebraic LISt Processing (hence the name) language for artificial
intelligence work. Early implementations included the IBM 704, the IBM
7090, the DEC PDP-1, the DEC PDP-6 and the DEC PDP-10. The PDP-6 and
PDP-10 had 18-bit addresses and 36-bit words, allowing a CONS cell to
be stored in one word, with single instructions to extract the CAR and
CDR parts. The early PDP machines had a small address space, which
limited the size of Lisp programs.
Milestones in the development of Lisp:
1956 Dartmouth Summer Research Project on AI.
1960-65 Lisp1.5 is the primary dialect of Lisp.
1964- Development of BBNLisp at BBN.
late 60s Lisp1.5 diverges into two main dialects:
Interlisp (originally BBNLisp) and MacLisp.
early 70s Development of special-purpose computers known as Lisp
Machines, designed specificly to run Lisp programs.
Xerox D-series Lisp Machines run Interlisp-D.
Early MIT Lisp Machines run Lisp Machine Lisp
(an extension of MacLisp).
1969 Anthony Hearn and Martin Griss define Standard Lisp to
port REDUCE, a symbolic algebra system, to a variety
of architectures.
late 70s Macsyma group at MIT developed NIL (New Implementation
of Lisp), a Lisp for the VAX.
Stanford and Lawrence Livermore National Laboratory
develop S-1 Lisp for the Mark IIA supercomputer.
Franz Lisp (dialect of MacLisp) runs on stock-hardware
Unix machines.
Gerald J. Sussman and Guy L. Steele developed Scheme,
a simple dialect of Lisp with lexical scoping and
lexical closures, continuations as first-class objects,
and a simplified syntax (i.e., only one binding per symbol).
Advent of object-oriented programming concepts in Lisp.
Flavors was developed at MIT for the Lisp machine,
and LOOPS (Lisp Object Oriented Programming System) was
developed at Xerox.
early 80s Development of SPICE-Lisp at CMU, a dialect of MacLisp
designed to run on the Scientific Personal Integrated
Computing Environment (SPICE) workstation.
1981 PSL (Portable Standard Lisp) runs on a variety of platforms.
1981+ Lisp Machines from Xerox, LMI (Lisp Machines Inc)
and Symbolics available commercially.
April 1981 Grass roots definition of Common Lisp as a description
of the common aspects of the family of languages (Lisp
Machine Lisp, MacLisp, NIL, S-1 Lisp, Spice Lisp, Scheme).
1984 Publication of CLtL1. Common Lisp becomes a de facto
standard.
1986 X3J13 forms to produce a draft for an ANSI Common Lisp
standard. Addition of CLOS, conditions, pretty printing
and iteration facilities to the standard.
1990 Publication of CLtL2.
[Note: This summary is based primarily upon the History section of the
draft ANSI specification. More detail and references can be obtained from
that document when it becomes generally available.]
----------------------------------------------------------------
;;; *EOF*