From: mkant+@cs.cmu.edu (Mark Kantrowitz)
Newsgroups: comp.lang.lisp,news.answers
Subject: FAQ: Lisp Frequently Asked Questions 2/5 [Monthly posting]
Summary: Frequently asked questions about Lisp -- General Questions
Date: 14 Aug 92 00:38:07 GMT
Article-I.D.: cs.lisp-faq-2.text_713752657
Expires: Sun, 27 Sep 1992 00:37:37 GMT
Reply-To: lisp-faq@think.com
Followup-To: poster
Organization: School of Computer Science, Carnegie Mellon
Supersedes: <lisp-faq-2.text_711014487@cs.cmu.edu>

Archive-name: lisp-faq/part2
Last-Modified: Thu Aug  6 11:54:55 1992 by Mark Kantrowitz
Version: 1.23

;;; ****************************************************************
;;; Answers to Frequently Asked Questions about Lisp ***************
;;; ****************************************************************
;;; Written by Mark Kantrowitz and Barry Margolin
;;; lisp-faq-2.text -- 63485 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 lisp-faq@think.com.

Topics Covered (Part 2):

  [2-0]   What FTP resources are available?
  [2-1]   Is there a GNU-Emacs interface to Lisp?
  [2-2]   How can I use the X Window System or other GUIs from Lisp?
  [2-3]   When is it right to use EVAL?
  [2-4]   What is the equivalent of EXPLODE and IMPLODE in Common Lisp?
  [2-5]   Is Lisp inherently slower than more conventional languages such as C?
  [2-6]   Why does my program's behavior change each time I use it?
  [2-7]   Why does Common Lisp have "#'"?
  [2-8]   How do I call non-Lisp functions from Lisp?
  [2-9]   Can I call Lisp functions from other languages?
  [2-10]  I want to call a function in a package that might not exist at
          compile time. How do I do this?  
  [2-11]  What is CDR-coding?
  [2-12]  What is garbage collection?
  [2-13]  How do I save an executable image of my loaded Lisp system?
          How do I run a Unix command in my Lisp?
          How do I get the current directory name from within a Lisp program?
  [2-14]  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?  
  [2-15]  History: Where did Lisp come from?
  [2-16]  How do I find the argument list of a function?
  [2-17]  How can I have two Lisp processes communicate via unix sockets?
  [2-18]  When producing formatted output in Lisp, where should you put the
          newlines (e.g., before or after the line, FRESH-LINE vs TERPRI,
          ~& vs ~% in FORMAT)?

Search for [#] to get to question number # quickly.

----------------------------------------------------------------
[2-0] What FTP resources are available?

There are several repositories of publicly redistributable and
public domain Lisp and Scheme code. 

FTP sites for Lisp/Scheme interpreters and compilers are discussed in
the answer to question [4-0]. See the entry on Macintosh Common Lisp
in question [4-0] for information on the CD-ROM of Lisp code that
Apple distributes with MCL 2.0.

   The Lisp Utilities collection is accessible by anonymous ftp
   to any CMU CS machine (e.g., ftp.cs.cmu.edu [128.2.206.173])
   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 atomic operation, as
   some of the superior directories on the path are protected from
   access by 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.
      simplex.lisp            Bruno Haible's implementation of the Simplex
                              algorithm.
      mapforms.tar.Z	      Moon's code walker.
      resources.lisp	      Brad Miller's resources package.
      nregex.lisp	      Lawrence Freil's regular expression matching code
   The Lisp Utilities repository is maintained by Mark Kantrowitz,
   cl-utilities-request@cs.cmu.edu.

   The Scheme Repository contains a Scheme bibliography, copies
   of the R4RS report and other papers, sample Scheme code for a variety of
   purposes, several utilities, and some implementations. The
   repository is maintained by Ozan S. Yigit, scheme@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 R4RS reports is available in altdorf.ai.mit.edu:/archive/scheme-reports/
   or as MIT AI Memo 848b (email publications@ai.mit.edu for more information).

   PSD (Portable Scheme Debugger) is available by anonymous ftp
   from Tampere University of Technology, Finland,
      cs.tut.fi:/pub/src/languages/schemes/psd.tar.Z
   With PSD, you can run a Scheme program in an Emacs buffer, set
   breakpoints, single step evaluation and access and modify the
   program's variables. It works by instrumenting the original source
   code, so it should run with any R4RS compliant Scheme. It has been
   tested with SCM and Elk 1.5, but should work with other Schemes with a
   minimal amount of porting, if at all. Includes documentation and
   user's manual. Written by Pertti Kellom\"aki, pk@cs.tut.fi

   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]
      ontic/			   [ONTIC Knowledge Rep. for Mathematics]
      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
   (waander@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. This includes code for an instructional version
   of CHEF by Kristian Hammond.

   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 registry@tira.uchicago.edu.

 Other sites contain specific programs:

   PCL -- parcftp.xerox.com:pcl/ [13.1.64.94]
   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
   See also ftp.apple.com
   
   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 <heeger@white.stanford.edu> and Eero
   Simoncelli <eero@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:

   TI Explorer Lisp Code -- sumex-aim.stanford.edu:pub/exp/
   The Knowledge Systems Lab's set of Explorer patches and tools. It
   includes in the jwz subdirectory a set of tools written and collected
   by Jamie Zawinski. Send questions to acuff@sumex-aim.stanford.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/ilisp/

   MCS (Meta Class System) -- ftp.gmd.de:/pub/lisp/mcs/ [129.26.8.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 1316, D-5205 Sankt Augustin 1, FRG, email: kopp@gmdzi.gmd.de

   LMath -- peoplesparc.berkeley.edu:pub/mma.tar.Z       [128.32.131.14]
   A Mathematica-style parser written in Common Lisp. Written by Richard
   Fateman; 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
   egdorf%zaphod@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:public/rrl
   [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
   nonlin-bugs@cs.umd.edu. User's group is nonlin-users@cs.umd.edu.
   The authors request that anybody ftping the code send a message to
   nonlin-users-request@cs.umd.edu, letting them know you have a copy
   and also letting them know if you wish to subscribe to the users group.
   More information can also be obtained from Jim Hendler, hendler@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. 
      o  ucsd.edu:pub/pc-ai contains implementations of Eliza 
         for the IBM PC.

   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 ftp.stat.washington.edu (128.95.17.34),
   and by email from the author, Russell Almond <almond@stat.washington.edu>.

   A Common Lisp implementation of ABTWEAK, a hierarchical nonlinear 
   planner extending David Chapman's (MIT) TWEAK, may be obtained by
   anonymous ftp from csis.dit.csiro.au in the directory pub/steve. A
   user's manual, a copy of the associated masters thesis by Steve
   Woods, and an extended Journal paper are also contained in that
   directory. Send mail to Steven.Woods@csis.dit.csiro.au for more
   information.  

   PLisp - A Common Lisp front end to Postscript. This translates many
   Common Lisp functions to postscript as well as manage the environment
   and many lispisms (&optional and &rest arguments, multiple values,
   macros, ...).  Available via anonymous ftp in pub/plisp/plisp.tar.Z on
   nebula.cs.yale.edu (128.36.13.1). Written by John Peterson,
   peterson-john@cs.yale.edu.

   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 Tom.Mitchell@cs.cmu.edu.
      o  FrameKit is available free from CMU, after signing a
         license agreement. Send mail to Eric.Nyberg@cs.cmu.edu
      o  KR. Send mail to Brad.Myers@cs.cmu.edu for more info.
      o  PARMENIDES (Frulekit) is available free, after signing
         a license agreement. Send mail to peter.shell@cs.cmu.edu 
      o  FROBS is available free by anonymous ftp from
         cs.utah.edu:/pub/frobs.tar.Z
         Contact Robert Kessler <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.
      o  YAK is a hybrid knowledge-representation system of the
	 KL-ONE family. Includes an optional graphical interface
	 depending on the Lisp. Available free after signing a license 
	 agreement. Contact Enrico Franconi <franconi@irst.it>.

   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. The commercial system is available
   from Blackboard Technology Group, PO Box 44, 401 Main Street,
   Amherst, Massachusetts 01002, 413-256-4240.

   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 ginsberg@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 <dvorak@cs.utexas.edu> or Ray Bareiss
   <bareiss@ils.nwu.edu> or Erik Eilerts <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

   ID3. A Lisp implementation of ID3 and other machine learning
   algorithms is available by anonymous ftp from the machine learning
   group at the University of Texas as cs.utexas.edu:pub/mooney

   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 <miller@cs.rochester.edu>.

   KNOWBEL is an implementation of Telos (a sorted/temporal logic
   system) by Bryan M. Kramer, <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 shapiro@cs.buffalo.edu
   for more information.

   PRODIGY is an integrated planning and learning system,
   available free after signing a license agreement. Contact
   prodigy@cs.cmu.edu for more information.

   SOAR is an integrated intelligent agent architecture currently
   being developed at Carnegie Mellon University, the University of
   Michigan, and the Information Sciences Institute of the University of
   Souther California. Soar, and its companion systems, CParaOPS5 and
   TAQL, have been placed in the public domain. The system may be
   retrieved by anonymous ftp to ftp.cs.cmu.edu (or any other CMU CS
   machine) in the directory /afs/cs.cmu.edu/project/soar/5.2/2/public/.
   [Note: You must cd to this directory in one atomic operation, as
   superior directories may be protected during an anonymous ftp.]  For
   more information, send email to soar-request@cs.cmu.edu or write to
   The Soar Group, School of Computer Science, Carnegie Mellon
   University, Pittsburgh, PA 15213.  Finally, though the software is in
   the public domain, the manual remains under copyright. To obtain one
   (at no charge) send a request (including your physical mail address)
   to soar-doc@cs.cmu.edu or to the physical address above.

   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 pkarp@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 weld@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 <hanks@cs.washington.edu> for more information.

   COBWEB/3 is a concept formation system available free after
   signing a license agreement. Contact cobweb@ptolemy.arc.nasa.gov
   for more information.

   VEOS (Virtual Environment Operating Shell) is an extendible environment
   for prototyping distributed applications for Unix. The programmer's
   interface uses XLISP 2.1. Although intended for distributed
   Virtual Reality applications at The Human Interface Technology Lab
   in Seattle, it should be appropriate for other applications.  VEOS
   uses heavyweight sequential processes, corresponding roughly to
   unix processes. VEOS runs on DEC/5000, Sun4, and Silicon Graphics
   VGX and Indigo. VEOS is available by anonymous ftp from
   milton.u.washington.edu (128.95.136.1) in the directory ~ftp/public/veos
   as veos.tar.Z. If you use the software, the authors ask that you send
   them mail to veos-support@hitl.washington.edu.

   PAIL (Portable AI Lab) is a computing environment containing a
   collection of state-of-the-art AI tools, examples, and documentation.
   It is aimed at those involved in teaching AI courses at university
   level or equivalent. The system has enough built-in functionality to
   enable its users to get practical experience with a broad range of AI
   problems without having to build all the supporting tools from
   scratch. It is implemented in Common Lisp and uses CLOS and Allegro
   Common Windows (i.e., in Allegro CL 4.1). It is available by anonymous
   ftp from pobox.cscs.ch:/pub/ai/pail-2.1/. Written by Mike Rosner and
   Dean Allemang {dean,mike}@idsia.ch.

   XSTAT is a statistics package which runs in XLISP. It has recently been
   ported to Common Lisp, and is available as
      umnstat.stat.umn.edu:/pub/xlispstat/CL/CLS1.0A1.tar.Z
   The CL port does not yet include the lisp-stat dynamic graphics 
   package, only the numerics.

   IDM is a Common Lisp implementation of both a classical and extended
   version of the STRIPS planner. It is available by anonymous ftp from 
   sauquoit.gsfc.nasa.gov (128.183.101.29). Questions, comments and bug
   reports may be sent to idm-users@chelmsford.gsfc.nasa.gov.             

----------------------------------------------------------------
[2-1] 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 <ccm+@cs.cmu.edu>. It is available by anonymous
ftp from katmandu.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 license from Franz Inc. Contact
info@franz.com for more information. There is also a mailing list, 
lisp-emacs-forum-request@ucbarpa.berkeley.edu.

The cl-shell package provides a major mode (cl-shell-mode) for running
Common Lisp (CL) as an Emacs subprocess.  It provides a general
mechanism for communication between CL and Emacs which does not rely
on extra processes, and should therefore be easily portable to any
version of CL.  Features include direct (i.e., not through a temp file)
evaluation and in-package compilation of forms from lisp-mode buffers,
type-ahead and a history mechanism for the cl-shell buffer, and pop-up
help facilities for the CL functions documentation, macroexpand and
describe.  Extensions for Lucid Common Lisp provide pop-up arglists
and source file editing.  Other extensions are provided to allow
editing source files of CLOS or Flavors methods.  Cl-shell is
available on the Lucid tape (in the goodies directory) or via
anonymous ftp from whitechapel.media.mit.edu (18.85.0.125).

Lucid includes some other Emacs-Lisp interfaces in its goodies directory.

Harlequin's LispWorks includes an Emacs-Lisp interface.

Venue's Medley has an optional EMACS Interface.

----------------------------------------------------------------
[2-2] How can I use the X Window System or other GUIs 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 [4-2].
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
   <rws@zermatt.lcs.mit.edu> Send bug reports to bug-clx@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, Apple, Franz, 
   Harlequin 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 - Doughty@ILA.com

        International Lisp Associates, 898 Windmill Park Road,
        Mountain View, CA 94043, 1-800-477-CLIM
        Contact: Bill York - York@ILA.com
   The CLIM 2.0 SPECIFICATION is available by anonymous ftp from
   ftp.uunet.net:vendor/franz/clim.ps.Z.

   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 clue-bugs@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 info@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: lispworks-request@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 <baecker@gmdzi.gmd.de>, GINA by Mike Spenke
   <spenke@gmdzi.gmd.de>, and IB by Thomas Berlage <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 <aressler@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. Garnet (version 2.0 and
   after) is now in the public domain, and has no licensing restrictions,
   so it is available to all foreign sites and for commercial uses.
   Detailed instructions for obtaining it by anonymous ftp are available
   by anonymous ftp from a.gp.cs.cmu.edu [128.2.242.7] as the file
   /usr/garnet/garnet/README.  Garnet includes the Lapidiary interactive
   design tool, Gilt Interface Builder, automatic display management, two
   widget sets (Motif look-and-feel and Garnet look-and-feel), support for
   gesture recognition, and automatic constraint maintenance, application
   data layout and PostScript generation. Runs in virtually any Common
   Lisp environment, including Allegro, Lucid, CMU, and Harlequin Common
   Lisps on Sun, DEC, HP, Apollo, IBM 6000, and many other machines.
   Garnet helps implement highly-interactive, graphical, direct
   manipulation programs for X/11 in Common Lisp.  Typical applications
   include: drawing programs similar to Macintosh MacDraw, user interfaces
   for expert systems and other AI applications, box and arrow diagram
   editors, graphical programming languages, game user interfaces,
   simulation and process monitoring programs, user interface construction
   tools, CAD/CAM programs, etc. Contact Brad Myers (bam@a.gp.cs.cmu.edu)
   for more information. Bug reports and administrative questions:
   garnet@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 
   Includes a general-purpose 2D grapher library.
   Written by Hans Muller (hmuller@sun.com). Runs in Sun CL and Lucid CL.
   Direct questions about the source provision to lispview@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
   winterp-source%hplnpm@hplabs.hp.com or hplabs!hplnpm!winterp-source.
   Contact Niels Mayer 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 <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
   picasso@postgres.berkeley.edu for more information.

   XIT (X User Interface Toolkit) is an object-oriented user interface
   toolkit for the X Window System based on Common Lisp, CLOS, CLX, and
   CLUE. It has been developed by the Research Group DRUID at the
   Department of Computer Science of the University of Stuttgart as a
   framework for Common Lisp/CLOS applications with graphical user
   interfaces for the X Window System.  The work is based on the USIT
   system developed by the Research Group INFORM at the University of
   Stuttgart. Although the system kernel is quite stable, XIT is still
   under active development. XIT can be obtained free by anonymous ftp
   from ifi.informatik.uni-stuttgart.de (129.69.211.1) in the directory
   /pub/xit/.


----------------------------------------------------------------
[2-3] 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)))

On the other hand, EVAL can sometimes be necessary when the only portable
interface to an operation is a macro. 

----------------------------------------------------------------
[2-4] 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 object)))

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.

----------------------------------------------------------------
[2-5] 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.
     
----------------------------------------------------------------
[2-6] 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 basic problem is that QUOTE returns its argument, *not* a copy of
it. The list is actually a part of the lambda expression that is in
ONE-TO-TEN-EXCEPT's function cell, and any modifications to it (e.g., by
DELETE) are modifications to the actual object in the function definition.
The next time that the function is called, this modified list is used.

In some implementations calling ONE-TO-TEN-EXCEPT may even result in
the signalling of an error or the complete aborting of the Lisp process.  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.
Details of this behavior may vary even within an implementation,
depending on whether the code is interpreted or compiled (perhaps due to
inlined DEFCONSTANT objects).

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 (X3J13 vote CONSTANT-MODIFICATION:DISALLOW).

To avoid these problems, use LIST to introduce a list, not QUOTE. QUOTE
should be used only when the list is intended to be a constant which
will not be modified.  If QUOTE is used to introduce a list which will
later be modified, use COPY-LIST to provide a fresh copy.

For example, the following should all work correctly:

   o  (remove 4 (list 1 2 3 4 1 3 4 5))
   o  (remove 4 '(1 2 3 4 1 3 4 5))   ;; Remove is non-destructive.
   o  (delete 4 (list 1 2 3 4 1 3 4 5))
   o  (let ((x (list 1 2 4 1 3 4 5)))
	(delete 4 x))
   o  (defvar *foo* '(1 2 3 4 1 3 4 5))
      (delete 4 (copy-list *foo*))
      (remove 4 *foo*)
      (let ((x (copy-list *foo*)))
	 (delete 4 x))

The following, however, may not work as expected:

   o  (delete 4 '(1 2 3 4 1 3 4 5))
     
----------------------------------------------------------------
[2-7] 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.

----------------------------------------------------------------
[2-8] 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.

Franz Allegro Common Lisp's "Foreign Function Call Facility" is
described in chapter 10 of the documentation. Calling Lisp Functions
from C is treated in section 10.8.2. The foreign function interface in
Macintosh Common Lisp is similar. The foreign function interface for
KCL is described in chapter 10 of the KCL Report. The foreign function
interfaces for Lucid on the Vax and Lucid on the Sun4 are
incompatible. Lucid's interface is described in chapter 5 of the
Advanced User's Guide.

----------------------------------------------------------------
[2-9] 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.
     
----------------------------------------------------------------

[2-10] 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) ...).

----------------------------------------------------------------
[2-11] 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. There may also be some benefit in improved paging
performance due to increased locality as well (putting a list into
CDR-coded form makes all the "cells" contiguous). Nevertheless, modern
Lisps tend to use lists much less frequently, with a much heavier
reliance upon code, strings, and vectors (structures).

----------------------------------------------------------------
[2-12] 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 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. It is most often
used to improve the performance of stop and copy garbage collectors.
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.

----------------------------------------------------------------
[2-13] How do I save an executable image of my loaded Lisp system?
       How do I run a Unix command in my Lisp?
       How do I get the current directory name from within a Lisp program?

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
   MCL:		        SAVE-APPLICATION <pathname>
			  &key :toplevel-function  :creator :excise-compiler
			  :size :resources :init-file :clear-clos-caches
   KCL:                 (si:save-system "saved_kcl")

There is no standard for running a Unix shell command from Lisp,
especially since not all Lisps run on top of Unix. Here are the
commands from some Lisp implementations:
   Allegro:		EXCL:RUN-SHELL-COMMAND
   Lucid:		RUN-PROGRAM (name 
				     &key input output
				          error-output (wait t) arguments
					  (if-input-does-not-exist :error)
					  (if-output-exists :error)
					  (if-error-output-exists :error))
   KCL:                 SYSTEM 
			For example, (system "ls -l").

There's no standard function for finding the current directory from
within a Lisp program, since not all Lisp environments have the
concept of a current directory. Here are the commands from some Lisp
implementations:
   Lucid:		working-directory (which is also SETFable)
			pwd and cd also work
   Allegro:		current-directory (use excl:chdir to change it)
   CMU CL:              default-directory

Allegro also uses the variable *default-pathname-defaults* to resolve
relative pathnames, maintaining it as the current working directory.
So evaluating (truename "./") in Allegro (and on certain other
systems) will return a pathname for the current directory. Likewise,
in some VMS systems evaluating (truename "[]") will return a pathname
for the current directory.

----------------------------------------------------------------
[2-14] 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 "".
     
----------------------------------------------------------------
[2-15] 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.

   1980            First biannual ACM Lisp and Functional Programming Conf.

   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. 

   1987            Lisp Pointers commences publication.

   1990            Publication of CLtL2. Includes X3J13's additions of
		   CLOS, conditions, pretty printing and iteration facilities.

[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.]
----------------------------------------------------------------
[2-16]  How do I find the argument list of a function?

There is no standard way to find the argument list of a function,
since implementations are not required to save this information.
However, many implementations do remember argument information, and
usually have a function that returns the lambda list. Here are the
commands from some Lisp implementations:

   Lucid:				arglist
   Allegro:        			excl::arglist
   Symbolics:				arglist

CMU Common Lisp, new compiler:
   #+(and :CMU :new-compiler)
   (defun arglist (name)
     (let* ((function (symbol-function name))
	    (stype (system:%primitive get-vector-subtype function)))
       (when (eql stype system:%function-entry-subtype)
	 (cadr (system:%primitive header-ref function
				  system:%function-entry-type-slot)))))

If you're interested in the number of required arguments you could use

   (defun required-arguments (name)
     (or (position-if #'(lambda (x) (member x lambda-list-keywords))
		      (arglist name))
	 (length (arglist name))))

----------------------------------------------------------------
[2-17]  How can I have two Lisp processes communicate via unix sockets?

CLX uses Unix sockets to communicate with the X window server. Look at
the following files from the CLX distribution for a good example of
using Unix sockets from Lisp:
	defsystem.lisp		Lucid, AKCL, IBCL, CMU.
	socket.c, sockcl.lisp	AKCL, IBCL
	excldep.lisp		Franz Allegro CL
You will need the "socket.o" files which come with Lucid and Allegro.
To obtain CLX, see the entry for CLX in the answer to question [2-2].

See the file lisp-sockets.text in the Lisp Utilities repository
described in the answer to question [2-0].

----------------------------------------------------------------
[2-18]  When producing formatted output in Lisp, where should you put the
        newlines (e.g., before or after the line, FRESH-LINE vs TERPRI,
        ~& vs ~% in FORMAT)?


Where possible, it is desirable to write functions that produce output
as building blocks. In contrast with other languages, which either
conservatively force a newline at various times or require the program
to keep track of whether it needs to force a newline, the Lisp I/O
system keeps track of whether the most recently printed character was
a newline or not. The function FRESH-LINE outputs a newline only if
the stream is not already at the beginning of a line.  TERPRI forces a
newline irrespective of the current state of the stream. These
correspond to the ~& and ~% FORMAT directives, respectively. (If the
Lisp I/O system can't determine whether it's physically at the
beginning of a line, it assumes that a newline is needed, just in case.)

Thus, if you want formatted output to be on a line of its own, start
it with ~& and end it with ~%. (Some people will use a ~& also at the
end, but this isn't necessary, since we know a priori that we're not
at the beginning of a line. The only exception is when ~& follows a
~A, to prevent a double newline when the argument to the ~A is a
formatted string with a newline at the end.) For example, the
following routine prints the elements of a list, N elements per line,
and then prints the total number of elements on a new line:

   (defun print-list (list &optional (elements-per-line 10))
     (fresh-line)
     (loop for i upfrom 1
           for element in list do
       (format t "~A ~:[~;~%~]" element (zerop (mod i elements-per-line))))
     (format t "~&~D~%" (length list)))

----------------------------------------------------------------

;;; *EOF*