Amiga Plus 1995 #2/Amiga Plus CD - 1995 - No. 2.iso/internet/faq/englisch/lisp

Text File | 1995-04-11 | 341.0 KB | 6,938 lines

Archive-name: lisp-faq/part1
Last-Modified: Fri Mar 10 17:06:50 1995 by Mark Kantrowitz
Version: 1.54
Maintainer: Mark Kantrowitz and Barry Margolin <[e-mail]>
URL: http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/lisp/top.html
Size: 79107 bytes, 1627 lines

;;; ****************************************************************
;;; Answers to Frequently Asked Questions about Lisp ***************
;;; ****************************************************************
;;; Written by Mark Kantrowitz and Barry Margolin
;;; lisp_1.faq

This post contains Part 1 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 [e-mail].

Note that the lisp-faq mailing list is for discussion of the content
of the FAQ posting only.  It is not the place to ask questions about Lisp;
use either the [e-mail] mailing list or the
comp.lang.lisp newsgroup for that.  If a question appears frequently
in one of those forums, it will get added to the FAQ list.

*** Copyright:

Copyright (c) 1992-94 by Mark Kantrowitz and Barry Margolin.
All rights reserved.

This FAQ may be freely redistributed in its entirety without
modification provided that this copyright notice is not removed.  It
may not be sold for profit or incorporated in commercial documents
(e.g., published for sale on CD-ROM, floppy disks, books, magazines,
or other print form) without the prior written permission of the
copyright holder.  Permission is expressly granted for this document
to be made available for file transfer from installations offering
unrestricted anonymous file transfer on the Internet.

If this FAQ is reproduced in offline media (e.g., CD-ROM, print form,
etc.), a complimentary copy should be sent to Mark Kantrowitz, School
of Computer Science, Carnegie Mellon University, 5000 Forbes Avenue,
Pittsburgh, PA 15213-3891 USA.

This article is provided AS IS without any express or implied warranty.

*** Recent Changes:

;;; 1.51:
;;; 13-OCT-94 mk    Added [2-21] How do I tell if a symbol names a function
;;;                 and not a macro?
;;; 20-OCT-94 mk    Added [5-7] Common CLOS Blunders by Marty Hall.
;;;  3-NOV-94 mk    Added Christian Queinnec's Lisp book to [1-4].
;;;  4-NOV-94 mk    Updated CMU CL entry. 17f w/ Solaris, SGI MIPS, and DEC
;;;                 Alpha released.
;;; 10-NOV-94 mk    Digitool to produce PowerPC version of MCL.
;;; 11-NOV-94 mk    Updated ISO Lisp paragraph in [4-10].
;;; 11-NOV-94 mk    Updated LispWorks for Harlequin entry in part 4.
;;;
;;; 1.52:
;;; 14-NOV-94 mk    Corrected ftp location of GBB, part 6.
;;;  1-DEC-94 mk    Updated AKCL entry (beta DOS implementation) thanks to Ken
;;;                 Nakata.
;;;  1-DEC-94 mk    HTML version of CLtL2 in [1-2].
;;; 12-DEC-94 mk    Miscellaneous small fixes to mentions of LispWorks in
;;;                 [2-11], [2-14], [4-1], and so on.
;;; 12-DEC-94 mk    Updated Lisp & Symbolic Computation's editors.
;;;
;;; 1.53:
;;; 16-JAN-95 mk    Removed prices from Lucid entry.
;;; 17-JAN-95 mk    Expanded Hasemer and Domingue entry, thanks to Andrew
;;;                 Knight.
;;; 19-JAN-95 mk    Common Lisp now an ANSI standard [4-10].
;;; 24-JAN-95 mk    Updated Xerox Tagger info in part 6.
;;; 31-JAN-95 mk    Updated Poplog Common Lisp entry in [4-1].
;;;
;;; 1.54:
;;;  8-MAR-95 mk    Removed the CORBA entry from part 5 of the FAQ, since
;;;                 Donald Vines is no longer at NEC. Thus there's nobody at
;;;                 NEC to provide support for the CLOS binding.
;;; 10-MAR-95 mk    Added Xgcl entry to part 7.

*** Topics Covered:

There are currently seven parts to the Lisp FAQ:

   1. Introductory Matter and Bibliography of Introductions and References
   2. General Questions
   3. Common Programming Pitfalls
   4. Lisp Implementations and Mailing Lists
   5. Object-oriented Programming in Lisp
   6. FTP Archives and Resources
   7. Lisp Window Systems and GUIs

All parts are posted to comp.lang.lisp. Part 5 is cross-posted to the
comp.lang.clos newsgroup.

Topics Covered (Part 1):

  [1-0]   What is the purpose of this newsgroup?
  [1-1]   What is the difference between Scheme and Common Lisp?
  [1-2]   Lisp books, introductions, documentation, periodicals,
          journals, and conference proceedings.
  [1-3]   How can I improve my Lisp programming style and coding efficiency?
  [1-4]   Where can I learn about implementing Lisp interpreters and compilers?
  [1-5]   What is the "minimal" set of primitives needed for a Lisp
          interpreter?
  [1-6]   What does CLOS, PCL, X3J13, CAR, CDR, ... mean?
  [1-7]   Lisp Job Postings

Topics Covered (Part 2):

  [2-1]   Is there a GNU-Emacs interface to Lisp?
  [2-2]   When should I use a hash table instead of an association list?
  [2-3]   What is the equivalent of EXPLODE and IMPLODE in Common Lisp?
  [2-4]   Is Lisp inherently slower than more conventional languages such as C?
  [2-5]   Why does Common Lisp have "#'"?
  [2-6]   How do I call non-Lisp functions from Lisp?
  [2-7]   Can I call Lisp functions from other languages?
  [2-8]   I want to call a function in a package that might not exist at
          compile time. How do I do this?
  [2-9]   What is CDR-coding?
  [2-10]  What is garbage collection?
  [2-11]  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 exit Lisp?
  [2-12]  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-13]  History: Where did Lisp come from?
  [2-14]  How do I find the argument list of a function?
          How do I get the function name from a function object?
  [2-15]  How can I have two Lisp processes communicate via unix sockets?
  [2-16]  How can I create a stream that acts like UNIX's /dev/null
          (i.e., gobbles any output and immediately signals EOF on
          input operations)?
  [2-17]  Read-time conditionalization of code (#+ #- and *features*)
  [2-18]  What reader macro characters are used in major Lisp systems?
  [2-19]  How do I determine if a file is a directory or not?
          How do I get the current directory name from within a Lisp
          program? Is there any way to create a directory?
  [2-20]  What is a "Lisp Machine" (LISPM)?
  [2-21]  How do I tell if a symbol names a function and not a macro?

Common Pitfalls (Part 3):

  [3-0]  Why does (READ-FROM-STRING "foobar" :START 3) return FOOBAR
         instead of BAR?
  [3-1]  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?
  [3-2]  Why can't I apply #'AND and #'OR?
  [3-3]  I used a destructive function (e.g. DELETE, SORT), but it
         didn't seem to work.  Why?
  [3-4]  After I NREVERSE a list, it's only one element long.  After I
         SORT a list, it's missing things.  What happened?
  [3-5]  Why does (READ-LINE) return "" immediately instead of waiting
         for me to type a line?
  [3-6]  I typed a form to the read-eval-print loop, but nothing happened. Why?
  [3-7]  DEFMACRO doesn't seem to work.
         When I compile my file, LISP warns me that my macros are undefined
         functions, or complains "Attempt to call <function> which is
         defined as a macro.
  [3-8]  Name conflict errors are driving me crazy! (EXPORT, packages)
  [3-9]  Closures don't seem to work properly when referring to the
         iteration variable in DOLIST, DOTIMES, DO and LOOP.
  [3-10] What is the difference between FUNCALL and APPLY?
  [3-11] Miscellaneous things to consider when debugging code.
  [3-12] When is it right to use EVAL?
  [3-13] Why does my program's behavior change each time I use it?
  [3-14] 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)?
  [3-15] I'm using DO to do some iteration, but it doesn't terminate.
  [3-16] My program works when interpreted but not when compiled!

Lisp Implementations and Mailing Lists (Part 4):

  [4-0]   Free Common Lisp implementations.
  [4-1]   Commercial Common Lisp implementations.
  [4-1a]  Lisp-to-C translators
  [4-2]   Scheme Implementations
  [4-4]   Free Implementations of Other Lisp Dialects
  [4-5]   Commercial Implementations of Other Lisp Dialects
  [4-6]   What is Dylan?
  [4-7]   What is Pearl Common Lisp?
  [4-9]   What Lisp-related discussion groups and mailing lists exist?
  [4-10]  Where can I get a copy of the ANSI Common Lisp standard?
          What is ISO Lisp?

Object-oriented Programming in Lisp (Part 5):

  [5-0]   What is CLOS (PCL) and where can I get it?
          How do you pronounce CLOS? What is the Meta-Object Protocol (MOP)?
  [5-1]   What documentation is available about object-oriented
          programming in Lisp?
  [5-2]   How do I write a function that can access defstruct slots by
          name?  I would like to write something like
          (STRUCTURE-SLOT <object> '<slot-name>).
  [5-3]   How can I list all the CLOS instances in a class?
  [5-4]   How can I store data and CLOS instances (with possibly circular
          references) on disk so that they may be retrieved at some later
          time? (Persistent Object Storage)
  [5-5]   Given the name of a class, how can I get the names of its slots?
  [5-6]   Free CLOS software.
  [5-7]   Common CLOS Blunders

FTP Resources (Part 6):

  [6-0] General information about FTP Resources for Lisp
  [6-1] Repositories of Lisp Software
  [6-3] Publicly Redistributable Lisp Software
  [6-6] Formatting code in LaTeX (WEB and other literate programming tools)
  [6-7] Where can I get an implementation of Prolog in Lisp?
  [6-8] World-Wide Web (WWW) Resources

Lisp Window Systems and GUIs (Part 7):
  [7-1] How can I use the X Window System or other GUIs from Lisp?
  [7-2] What Graphers/Browsers are available?

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

*** Introduction:

Certain questions and topics come up frequently in the various network
discussion groups devoted to and related to Lisp.  This file/article is
an attempt to gather these questions and their answers into a convenient
reference for Lisp programmers.  It (or a reference to it) is posted
periodically.  The hope is that this will cut down on the user time and
network bandwidth used to post, read and respond to the same questions
over and over, as well as providing education by answering questions
some readers may not even have thought to ask.

This is not a Lisp tutorial, nor is it an exhaustive list of all Lisp
intricacies.  Lisp is a very powerful and expressive language, but with
that power comes many complexities.  This list attempts to address the
ones that average Lisp programmers are likely to encounter.  If you are
new to Lisp, see the answer to the question "How can I learn Lisp?".

The latest version of this FAQ is available via anonymous FTP from CMU:

   To obtain the files from CMU, connect by anonymous FTP to
      ftp.cs.cmu.edu:/user/ai/pubs/faqs/lisp/  [128.2.206.173]
   using username "anonymous" and password "name@host" (substitute your
   email address) or via AFS in the Andrew File System directory
      /afs/cs.cmu.edu/project/ai-repository/ai/pubs/faqs/lisp/
   and get the files lisp_1.faq, lisp_2.faq, lisp_3.faq, lisp_4.faq,
   lisp_5.faq, lisp_6.faq and lisp_7.faq.

You can also obtain a copy of the FAQ by sending a message to
[e-mail] with
   Send Lisp FAQ
in the message body.

The FAQ postings are also archived in the periodic posting archive on
   rtfm.mit.edu:/pub/usenet/news.answers/lisp-faq/ [18.181.0.24]
If you do not have anonymous ftp access, you can access the archive by
mail server as well.  Send an E-mail message to
[e-mail] with "help" and "index" in the body on
separate lines for more information.

An automatically generated HTML version of the Lisp FAQ is accessible by
WWW as part of the AI-related FAQs Mosaic page. The URL for this
resource is
   http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/top.html
The direct URL for the Lisp FAQ is
   http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/lisp/top.html

Unless otherwise specified, the Lisp dialect referred to is Common Lisp,
as defined by "Common Lisp: the Language" (aka "CLtL1") as well as
corrections (but not enhancements) from "Common Lisp: the Language, 2nd
Edition" (aka "CLtL2"), both by Guy L. Steele, Jr. and published by
Digital Press. Note that CLtL2 is NOT an official specification for
the language; ANSI Committee X3J13 is preparing such a specification.
See question [4-10] for information on the status of the ANSI
specification for Common Lisp. Enhancements such as CLOS, conditions,
and the LOOP macro will be referred to separately.

If you need to cite the FAQ for some reason, use the following format:
   Mark Kantrowitz and Barry Margolin, "Answers to Frequently Asked
   Questions about Lisp", comp.lang.lisp, <month>, <year>,
   ftp.cs.cmu.edu:/user/ai/pubs/faqs/lisp/lisp_?.faq, [e-mail].

----------------------------------------------------------------
Subject: [1-0] What is the purpose of this newsgroup?

The newsgroup comp.lang.lisp exists for general discussion of
topics related to the programming language Lisp. For example, possible
topics can include (but are not necessarily limited to):
   announcements of Lisp books and products
   discussion of programs and utilities written in Lisp
   discussion of portability issues
   questions about possible bugs in Lisp implementations
   problems porting an implementation to some architecture
Postings should be of general interest to the Lisp community. See also
question [4-9]. Postings asking for solutions to homework problems are
inappropriate.

Every so often, somebody posts an inflammatory message, such as
   My programming language is better than yours (Lisp vs. C/Prolog/Scheme).
   Loop (or Series) should/shouldn't be part of the language.
These "religious" issues serve no real purpose other than to waste
bandwidth. If you feel the urge to respond to such a post, please do
so through a private e-mail message.

Questions about object oriented programming in Lisp should be directed
to the newsgroup comp.lang.clos. Similarly, questions about the
programming language Scheme should be directed to the newsgroup
comp.lang.scheme. Discussion of functional programming language issues
should be directed to the newsgroup comp.lang.functional. Discussion
of AI programs implemented in Lisp should sometimes be cross-posted to
the newsgroup comp.ai.

----------------------------------------------------------------
Subject: [1-1] What is the difference between Scheme and Common Lisp?

Scheme is a dialect of Lisp that stresses conceptual elegance and
simplicity. It is specified in R4RS and IEEE standard P1178. (See
the Scheme FAQ for details on standards for Scheme.) Scheme is much
smaller than Common Lisp; the specification is about 50 pages,
compared to Common Lisp's 1300 page draft standard. (See question
[4-10] for details on standards for Common Lisp.) Advocates of Scheme
often find it amusing that the Scheme standard is shorter than the
index to CLtL2.

Scheme is often used in computer science curricula and programming
language research, due to its ability to represent many programming
abstractions with its simple primitives. Common Lisp is often used for
real world programming because of its large library of utility
functions, a standard object-oriented programming facility (CLOS), and
a sophisticated condition handling system.

See the Scheme FAQ for information about object-oriented programming
in Scheme.

In Common Lisp, a simple program would look something like the
following:

   (defun fact (n)
     (if (< n 2)
         1
         (* n (fact (1- n)))))

In Scheme, the equivalent program would like like this:

   (define fact
     (lambda (n)
       (if (< n 2)
           1
         (* n (fact (- n 1))))))

Experienced Lisp programmers might write this program as follows in order
to allow it to run in constant space:

   (defun fact (n)
     (labels ((tail-recursive-fact (counter accumulator)
                (if (> counter n)
                    accumulator
                    (tail-recursive-fact (1+ counter)
                                         (* counter accumulator)))))
       (tail-recursive-fact 1 1)))

Whereas in Scheme the same computation could be written as follows:

   (define fact
     (lambda (n)
       (letrec ((tail-recursive-fact
                 (lambda (counter accumulator)
                   (if (> counter n)
                       accumulator
                     (tail-recursive-fact (+ counter 1)
                                          (* counter accumulator))))))
               (tail-recursive-fact 1 1))))

or perhaps (using IEEE named LETs):

   (define fact
     (lambda (n)
       (let loop ((counter n)
                  (accumulator 1))
            (if (< counter 2)
                accumulator
              (loop (- counter 1)
                    (* accumulator counter))))))

Some Schemes allow one to use the syntax (define (fact n) ...) instead
of (define fact (lambda (n) ...)).

----------------------------------------------------------------
Subject: [1-2] Lisp books, introductions, documentation, periodicals,
               journals, and conference proceedings.

There are several good Lisp introductions and tutorials:

   1. David S. Touretzky
      "Common Lisp: A Gentle Introduction to Symbolic Computation"
      Benjamin/Cummings Publishers, Redwood City, CA, 1990. 592 pages.
      ISBN 0-8053-0492-4 ($42.95).
           Perhaps the best tutorial introduction to the language. It has
           clear and correct explanations, and covers some fairly advanced
           topics. The book is an updated Common Lisp version of the 1984
           edition published by Harper and Row Publishers.

           Three free Lisp educational tools which were used in the book --
           Evaltrace, DTRACE and SDRAW -- are available by anonymous ftp from
              b.gp.cs.cmu.edu:/usr/dst/public/lisp/
              b.gp.cs.cmu.edu:/usr/dst/public/evaltrace/
       Evaltrace is a graphical notation for explaining how evaluation
       works and is described in "Visualizing Evaluation in
       Applicative Languages" by David S. Touretzky and Peter Lee,
       CACM 45-59, October 1992. DTRACE is a "detailed trace" which
       provides more information than the tracing tools provided with
       most Common Lisp implementations. SDRAW is a read-eval-draw
       loop that evaluates Lisp expressions and draws the result as a
       cons cell diagram (for both X11 and ascii terminals). Also
       available is PPMX, a tool for pretty printing macro expansions.

   2. Robert Wilensky.
      "Common LISPcraft"
      W. W. Norton, New York, 1986. 500 pages. ISBN 0-393-95544-3.

   3. Wade L. Hennessey.
      "Common Lisp"
      McGraw-Hill, New York, 1989. 395 pages. ISBN 0-07-028177-7, $26.95.
           Fairly good, but jumps back and forth from the simple to the
           complex rather quickly, with no clear progression in difficulty.

   4. Laurent Siklossy.
      "Let's Talk LISP"
      Prentice-Hall, NJ, 1976. 237 pages, ISBN 0-13-53276-2-8.
           Good introduction, but quite out of date.

   5. Stuart C. Shapiro.
      "Common Lisp: An Interactive Approach"
      Computer Science Press/W.H. Freeman, New York, 1992.
      358 pages, ISBN 0-7167-8218-9.
         The errata for the book may be obtained by anonymous ftp from
         ftp.cs.buffalo.edu:/users/shapiro/clerrata.ps

Other introductions to Lisp include:

   1. A. A. Berk.
      "LISP, The Language of Artificial Intelligence"
      Van Nostrand Reinhold, 1985. 160 pages, ISBN 0-44-22097-4-6.

   2. Paul Y. Gloess.
      "An Alfred handy guide to Understanding LISP"
      Alfred Publishers (Sherman Oaks, CA), 1982.
      64 pages, ISBN 0-88-28421-9-6, $2.95.

   3. Ward D. Maurer.
      "The Programmer's Introduction to LISP"
      American Elsevier, New York, 1972. 112 pages, ISBN 0-44-41957-2-6.

   4. Hank Bromley and Richard Lamson.
      "LISP Lore: A Guide to Programming the LISP Machine", 2nd edition
      Kluwer Academic, Boston, 1987. 337 pages, ISBN 0-89-83822-8-9, $49.95.

   5. Sharam Hekmatpour.
      "Introduction to LISP and Symbol Manipulation"
      Prentice Hall, New York, 1989. 303 pages, ISBN 0-13-53749-0-1, $40.

   6. Deborah G. Tatar
      "A programmer's guide to Common Lisp"
      Digital Press, 1987. 327 pages. ISBN 0-932376-87-8.
           Good introduction on Common Lisp for programmers familiar
           with other programming languages, such as FORTRAN, PASCAL, or C.

   7. Timothy Koschmann
      "The Common Lisp Companion"
      John Wiley & Sons, 1990. 459 pages, ISBN 0-471-503-8-8.
           Targeted for those with some programming experience who wish to
           learn draft-ANSI Common Lisp, including CLOS and the CL condition
           system. Examples progress incrementally from simple numerical
           calculation all the way to a logic-programming extension to CL.

More advanced introductions to Lisp and its use in Artificial
Intelligence include:

   1. Peter Norvig.
      "Paradigms of AI Programming: Case Studies in Common Lisp"
      Morgan Kaufmann, 1992. 946 pages. ISBN 1-55860-191-0 ($49.95).

        Provides an in-depth exposition of advanced AI programming techniques
        and includes large-scale detailed examples. The book is the most
        advanced AI/Common-Lisp programming text and reference currently
        available, and hence is not for the complete novice.  It focuses on the
        programming techniques necessary for building large AI systems,
        including object-oriented programming, and has a strong performance
        orientation.

        The text is marked by its use of "non-toy" examples to illustrate the
        techniques. All of the examples are written in Common Lisp, and copies
        of the source code are available by anonymous ftp from
        unix.sri.com:/pub/norvig and on disk in Macintosh or DOS format from
        the publisher. Some of the techniques described include rule-based
        pattern matching (GPS, Eliza, a subset of Macsyma, the Emycin expert
        system shell), constraint propagation and backtracking (Waltz
        line-labelling), alpha-beta search (Othello), natural language
        processing (top-down, bottom-up and chart parsing), logic-programming
        (unification and Prolog), interpreters and compilers for Scheme, and
        object-oriented programming (CLOS).

        The examples are also used to illustrate good programming style and
        efficiency. There is a guide to trouble-shooting and debugging Lisp
        programs, a style guide, and a discussion of portability problems.
        Some of the efficiency techniques described include memoization,
        data indexing, compilation, delaying computation, proper use of
        declarations, avoiding garbage collection, and choosing and using the
        correct data structure.

        The book also serves as an advanced introduction to Common Lisp, with
        sections on the Loop macro, CLOS and sequences, and some coverage of
        error handling, series, and the package facility.

   2. Eugene Charniak, Christopher K. Riesbeck, Drew V. McDermott
      and James R. Meehan.
      "Artificial Intelligence Programming", 2nd edition.
      Lawrence Erlbaum Associates (Hillsdale, NJ), 1987.
      533 pages, ISBN 0-89-85960-9-2, $29.95.

           Provides many nice code fragments, all of which are written
           in Common Lisp. The first half of the book covers topics
           like macros, the reader, data structures, control structures,
           and defstructs. The second half of the book describes
           programming techniques specific to AI, such as
           discrimination nets, production systems, deductive database
           retrieval, logic programming, and truth maintenance.

   3. Patrick H. Winston and Berthold K. P. Horn.
      "LISP", 3rd edition.
      Addison-Wesley (Reading, MA), 1989. 611 pages. ISBN 0-201-08319-1
           Covers the basic concepts of the language, but also gives a lot
           of detail about programming AI topics such as rule-based expert
           systems, forward chaining, interpreting transition trees,
           compiling transition trees, object oriented programming,
           and finding patterns in images. Not a tutorial. Has many
           good examples. Source code for the examples is available by
           anonymous ftp from ftp.ai.mit.edu:/pub/lisp3/. (The code runs in
           Lucid, Allegro, KCL, GCLisp, MCL, Symbolics Genera. Send mail
           with subject line "help" to [e-mail] for more information.)

   4. John R. Anderson, Albert T. Corbett, and Brian J. Reiser.
      "Essential LISP"
      Addison-Wesley (Reading, MA), 1987.
      352 pages, ISBN 0-20-11114-8-9, $23.95.
           Concentrates on how to use Lisp with iteration and recursion.

   5. Robert D. Cameron and Anthony H. Dixon
      "Symbolic Computing with Lisp"
      Prentice-Hall, 1992, 326 pages. ISBN 0-13-877846-9.
           The book is intended primarily as a third-year computer science
           text. In terms of programming techniques, it emphasizes recursion
           and induction, data abstraction, grammar-based definition of Lisp
           data structures and functional programming style. It uses
           two Lisp languages:
                (1) a purely functional subset of Lisp called Small Lisp and
                (2) Common Lisp.
           An MS-DOS interpreter for Small Lisp (including source) is
           provided with the book.  It considers applications of Lisp
           to formal symbolic data domains: algebraic expressions,
           logical formulas, grammars and programming languages.

   6. Tony Hasemer and John Domingue.
      "Common Lisp Programming for Artificial Intelligence"
      Addison-Wesley, Reading, MA, 1989. 444 pages, ISBN 0-20-11757-9-7.

     This book presents an introduction to Artificial Intelligence
     with an emphasis on the role of knowledge representation. Three
     chapters focus on object-oriented programming, including the
     construction and use of a subset of CLOS.

     The authors' research into the problems faced by novice Lisp
     users influenced the content and style of the book. (The authors
     are members of the Human Cognition Research Laboratory at the
     Open University in the United Kingdom.) The book employs a
     tutorial approach, especially in areas that students often find
     difficult, such as recursion.  Early and progressive treatment of
     the evaluator promotes understanding of program execution.
     Hands-on exercises are used to reinforce basic concepts.

     The book assumes no prior knowledge of Lisp or AI and is a
     suitable textbook for students in Cognitive Science, Computer
     Science and other disciplines taking courses in Lisp or AI
     programming as well as being invaluable for professional
     programmers who are learning Lisp for developing AI applications.

   7. Steven Tanimoto
      "The Elements of Artificial Intelligence Using Common Lisp", 2nd edition
      Computer Science Press, New York, 1995.
      562 pages, ISBN 0-71-67826-9-3, (ISBN 0-71-67823-0-8, 1990, $48).

   8. Patrick R. Harrison
      "Common Lisp and Artificial Intelligence"
      Prentice Hall, Englewood Clifs, NJ, 1990.
      244 pages, ISBN 0-13-1552430, $22.50.

   9. Paul Graham
      "On Lisp: Advanced Techniques for Common Lisp"
      Prentice Hall, Englewood Clifs, NJ, 1994. 413 pages, ISBN 0-13-030552-9.
         Emphasizes a bottom-up style of writing programs, which he
         claims is natural in Lisp and has advantages over the
         traditional way of writing programs in C and Pascal.
         Also has in-depth sections on writing macros with several
         nice examples. Source code is available by anonymous ftp from
            ftp.das.harvard.edu:/pub/onlisp/
         as a single 56kb file.

  10. John A. Moyne
      "Lisp: A first language for computing"
       Van Nostrand Reinhold, New York, 1991. 278 pages, ISBN 0442004265.

General Lisp reference books include:

   1. Guy L. Steele
      "Common Lisp: The Language" [CLtL1]
      Digital Press, 1984. 465 pages. ISBN 0-932376-41-X.

   2. Guy L. Steele
      "Common Lisp: The Language, 2nd Edition" [CLtL2]
      Digital Press, 1990. 1029 pages, ISBN 1-55558-041-6 paperbound ($39.95).

      [Butterworth-Heinemann, the owners of Digital Press, have made
       the LaTeX sources to this book available by anonymous FTP from
          cambridge.apple.com:/pub/CLTL/
       A copy of the distribution is also available from
          ftp.cs.cmu.edu:/user/ai/lang/lisp/doc/cltl/
       The paperbound version of the book is, of course, available at
       fine bookstores, or contact them directly at Digital Press,
       225 Wildwood Street, Woburn, MA 01801, call 800-366-2665
       (617-928-2527), or fax [phone] (617-933-6333). A copy of
       the Digital Press book catalog is available from the same FTP location.]

       A html version, produced using latex2html on the latex sources,
       is accessible via the URL:
           http://www.cs.cmu.edu:8001/Web/Groups/AI/html/cltl/cltl2.html

   3. Franz Inc.
      "Common Lisp: The Reference"
      Addison-Wesley, Reading, MA 1988. ISBN 0-201-11458-5
           Entries on Lisp (CLtL1) functions in alphabetical order.

   4. Rosemary Simpson
      "Common Lisp, the Index"
      Franz Inc., Berkeley, CA, 1987. 71 pages, $4.95.
           A cross-referenced index to Steele's book, 1st edition.

Lisp periodicals include:

   1. LISP Pointers.
      Published by ACM SIGPLAN six times a year. Volume 1, Number 1
      was April-May 1987.
      Subscriptions: ACM Members $12; ACM Student Members $7; Non-ACM
      members $25. Mail checks payable to the ACM to ACM Inc., PO Box
      12115, Church Street Station, New York, NY 10249.

   2. LISP and Symbolic Computation, Kluwer Academic Press. Volume 1
      was published in 1989. (Robert Kessler <[e-mail]>
      and Carolyn Talcott <[e-mail]> are the editors).
      ISSN 0892-4635.
      Subscriptions: Institutions $169; Individuals $80. Add $8 for
      air mail. Kluwer Academic Publishers, PO Box 322, 3300 AH Dordrecht,
      The Netherlands, or Kluwer Academic Publishers, PO Box 358, Accord
      Station, Hingham, MA 02018-0358.

      A full table of contents of all published issues, aims and scope, and
      instructions for authors are available by anonymous ftp from
         ftp.std.com:/Kluwer/journals/
      as the files lisp.toc and lisp.inf.

   3. Proceedings of the biannual ACM Lisp and Functional Programming
      Conference. (First one was in 1980.)

   4. Proceedings of the annual Lisp Users and Vendors Conference.

Implementation-specific questions:

   1. Lucid. See the wizards.doc file that comes with the Lucid
      release. It describes functions, macros, variables and constants that
      are not official parts of the product and are not supported.
      Constructs described in this file include: the interrupt facility, the
      source file recording facility, the resource facility, multitasking,
      writing your own streams, lisp pipes, i/o buffers, the compiler,
      floating-point functions, memory management, debugger information, the
      window tool kit, extensions to the editor, the foreign function
      interface, clos information, delivery toolkit information, and Lucid
      lisp training classes. The wizards.doc file also covers i/o
      constructs, functions for dealing with DEFSTRUCT, functions and
      constants for dealing with procedure objects, functions and constants
      for dealing with code objects, function for mapping objects,
      additional keyword argument to DISKSAVE, function used in the
      implementation of arrays, function for monitor-specific behavior for a
      process, additional keyword argument to RUN-PROGRAM, and load-time
      evaluation.

Many books on Scheme are worth reading even if you use Common Lisp,
because many of the issues are similar. Scheme is a simpler language
to learn, so it is often used in introductory computer science
classes.  See the Scheme FAQ for a list of introductions and
references for Scheme. The two key introductions are Abelson and
Sussman's "Structure and Interpretation of Computer Programs" and
Friedman and Felleisen's "The Little LISPer".

Special Topics:

   Garbage Collection:

      Wilson, Paul R., "Uniprocessor Garbage Collection Techniques"
      Proceedings of the 1992 International Workshop on Memory Management.
      Springer Lecture Notes #637. Surveys garbage collection techniques.
      Includes an excellent bibliography. Available by anonymous ftp from
         cs.utexas.edu:/pub/garbage/gcsurvey.ps.
      The BibTeX format of the bibliography is also available in this
      directory, along with several other papers. Contact [e-mail]
      for more info.

----------------------------------------------------------------
Subject: [1-3] How can I improve my Lisp programming style and
               coding efficiency?

There are several books about Lisp programming style, including:

   1. Molly M. Miller and Eric Benson
      "Lisp Style and Design"
      Digital Press, 1990. 214 pages, ISBN 1-55558-044-0, $26.95.
           How to write large Lisp programs and improve Lisp programming
           style. Uses the development of Lucid CL as an example.

   2. Robin Jones, Clive Maynard, and Ian Stewart.
      "The Art of Lisp Programming"
      Springer-Verlag, 1989. 169 pages, ISBN 0-387-19568-8 ($33).

   3. W. Richard Stark.
      "LISP, Lore, and Logic: An Algebraic View of LISP
       Programming, Foundations, and Applications"
      Springer-Verlag, 1990. 278 pages. ISBN 0-387-97072-X paper ($42).
           Self-modifying code, self-reproducing programs, etc.

   4. CMU CL User's Manual, Chapter 7, (talks about writing
      efficient code). It is available by anonymous ftp from any CMU CS
      machine (e.g., ftp.cs.cmu.edu [128.2.206.173]) as the file
        /afs/cs.cmu.edu/project/clisp/docs/cmu-user/cmu-user.ps
      [when getting this file by anonymous ftp, one must cd to
      the directory in one atomic operation, as some of the superior
      directories on the path are protected from access by anonymous ftp.]

   5. See also Norvig's book, SICP (Abelson & Sussman), SAP
      (Springer and Friedman).

   6. Hallvard Tretteberg's Lisp Style Guide is available by anonymous
      ftp in ftp.think.com:/public/think/lisp/style-guide.text. There is
      a fair bit of overlap between Hallvard's style guide and the notes
      below and in part 3 of this FAQ.

   7. Rajeev Sangal
      "Programming Paradigms in Lisp"
      McGraw-Hill, 1991. ISBN 0-07-054666-5.

   8. Rodney A. Brooks.
      "Programming in Common Lisp"
      John Wiley & Sons, New York, 1985. 303 pages. ISBN 0-471-81888-7.
      Chapter 5 discusses Lisp programming style.

Here are some general suggestions/notes about improving Lisp
programming style, readability, correctness and efficiency:

   General Programming Style Rules:

      - Write short functions, where each function provides a single,
        well-defined operation. Small functions are easier to
        read, write, test, debug, and understand.

      - Use descriptive variable and function names. If it isn't clear
        from the name of a function or variable what its purpose is,
        document it with a documentation string and a comment. In fact,
        even if the purpose is evident from the name, it is still worth
        documenting your code.

      - Don't write Pascal (or C) code in Lisp. Use the appropriate
        predefined functions -- look in the index to CLtL2, or use the
        APROPOS and DESCRIBE functions. Don't put a close parenthesis
        on a line by itself -- this can really irritate programmers
        who grew up on Lisp. Lisp-oriented text editors include tools
        for ensuring balanced parentheses and for moving across
        pairs of balanced parentheses. You don't need to stick
        comments on close parentheses to mark which expression they close.

      - Use proper indentation -- you should be able to understand
        the structure of your definitions without noticing the parentheses.
        In general, the way one indents a form is controlled by the
        first symbol of the form. In DEFUNs, for example, one puts the
        symbol DEFUN, the function name, and the argument list all on
        the same line. If the argument list is too long, one can break
        it at one of the lambda keywords. Following the argument list,
        one inserts a carriage return and lists the expressions in the
        body of the definition, with each form starting on its own
        line indented three spaces relative to the open parenthesis of
        the parent (in this case the DEFUN). This general style -- of
        putting all the significant elements of a form on a single
        line, followed by a carriage return and the indented body --
        holds for many Lisp constructs. There are, of course, variations,
        such as keeping the first clause on the same line as the COND
        or CASE symbol, and the rules are relaxed in different ways to
        keep line lengths to a manageable size. If you find yourself having
        trouble fitting everything in even with line breaking and
        relaxing the rules, either your function names are too long or your
        code isn't very modular. You should perceive this as a signal that
        you need to break up your big definitions into smaller chunks, each
        with a clearly defined purpose, and possibly replace long function
        names with concise but apt shorter ones.

      - Use whitespace appropriately. Use whitespace to separate
        semantically distinct code segments, but don't use too much
        whitespace. For example,
           GOOD:
              (defun foo (x y)
                (let ((z (+ x y 10)))
                  (* z z)))

           BAD:
              (defun foo(x y)(let((z(+ x y 10)))(* z z)))

              (defun foo ( x  y )
                (let ( ( z (+ x y 10) ) )
                  ( * z z )
                  )
                )
         Although the Lisp reader and compiler don't care which you
         use, most experienced Lisp programmers find the first example
         much easier to read than the last two.

       - Don't use line lengths greater than 80 characters. People who
         write code using Zmacs on Symbolics Lisp Machines are notoriously
         guilty of violating this rule, because the CPT6 font allows
         one to squeeze a tremendous amount of code on the display,
         especially if one spreads the code out horizontally. This
         makes it more difficult to read when printed out or read on
         an 80x24 xterm window. In fact, use a line length of 72 characters
         because it leaves a strip of white space at the edge of the window.

   The following functions often abused or misunderstood by novices.
   Think twice before using any of these functions.

      - EVAL. Novices almost always misuse EVAL. When experts use
        EVAL, they often would be better off using APPLY, FUNCALL, or
        SYMBOL-VALUE. Use of EVAL when defining a macro should set off
        a warning bell -- macro definitions are already evaluated
        during expansion. See also the answer to question 3-12.
        The general rule of thumb about EVAL is: if you think you need
        to use EVAL, you're probably wrong.

      - PROGV. PROGV binds dynamic variables and is often misused in
        conjunction with EVAL, which uses the dynamic environment.
        In general, avoid unnecessary use of special variables.
        PROGV is mainly for writing interpreters for languages embedded
        in Lisp. If you want to bind a list of values to a list of
        lexical variables, use
            (MULTIPLE-VALUE-BIND (..) (VALUES-LIST ..) ..)
        or
            (MULTIPLE-VALUE-SETQ (..) (VALUES-LIST ..))
        instead. Most decent compilers can optimize this expression.
        However, use of this idiom is not to be encouraged unless absolutely
        necessary.

      - CATCH and THROW. Often a named BLOCK and RETURN-FROM are
        more appropriate. Use UNWIND-PROTECT when necessary.

      - Destructive operations, such as NCONC, SORT, DELETE,
        RPLACA, and RPLACD, should be used carefully and sparingly.
        In general, trust the garbage collector: allocate new
        data structures when you need them.

   To improve the readability of your code,

      - Don't use any C{A,D}R functions with more than two
        letters between the C and the R. When nested, they become
        hard to read. If you have complex data structures, you
        are often better off describing them with a DEFSTRUCT,
        even if the type is LIST. The data abstraction afforded by
        DEFSTRUCT makes the code much more readable and its purpose
        clearer. If you must use C{A,D}R, try to use
        DESTRUCTURING-BIND instead, or at least SECOND, THIRD,
        NTH, NTHCDR, etc.

      - Use COND instead of IF and PROGN. In general, don't use PROGN if
        there is a way to write the code within an implicit
        PROGN. For example,
           (IF (FOO X)
               (PROGN (PRINT "hi there") 23)
               34)
        should be written using COND instead.

      - Never use a 2-argument IF or a 3-argument IF with a second
        argument of NIL unless you want to emphasize the return value;
        use WHEN and UNLESS instead. You will want to emphasize the
        return value when the IF clause is embedded within a SETQ,
        such as (SETQ X (IF (EQ Y Z) 2 NIL)). If the second argument
        to IF is the same as the first, use OR instead: (OR P Q) rather
        than (IF P P Q). Use UNLESS instead of (WHEN (NOT ..) ..)
        but not instead of (WHEN (NULL ..) ..).

      - Use COND instead of nested IF statements. Be sure to check for
        unreachable cases, and eliminate those cond-clauses.

      - Use backquote, rather than explicit calls to LIST, CONS, and
        APPEND, whenever writing a form which produces a Lisp form, but
        not as a general substitute for LIST, CONS and APPEND. LIST,
        CONS and APPEND usually allocate new storage, but lists produced
        by backquote may involve destructive modification (e.g., ,.).

      - Make the names of special (global) variables begin and end
        with an asterisk (*): (DEFVAR *GLOBAL-VARIABLE*)
        Some programmers will mark the beginning and end of an internal
        global variable with a percent (%) or a period (.).
        Make the names of constants begin and end with a plus (+):
        (DEFCONSTANT +E+ 2.7182818)
        This helps distinguish them from lexical variables. Some people
        prefer to use macros to define constants, since this avoids
        the problem of accidentally trying to bind a symbol declared
        with defconstant.

      - If your program is built upon an underlying substrate which is
        implementation-dependent, consider naming those functions and
        macros in a way that visually identifies them, either by placing
        them in their own package, or prepending a character like a %, .,
        or ! to the function name. Note that many programmers use the
        $ as a macro character for slot access, so it should be avoided
        unless you're using it for that purpose.

      - Don't use property lists. Instead, use an explicit hash table.
        This helps avoid problems caused by the symbol being in the wrong
        package, accidental reuse of property keys from other
        programs, and allows you to customize the structure of the table.

      - Use the most specific construct that does the job. This lets
        readers of the code see what you intended when writing the code.
        For example, don't use SETF if SETQ will do (e.g., for lexical
        variables). Using SETQ will tell readers of your code that you
        aren't doing anything fancy. Likewise, don't use EQUAL where EQ
        will do. Use the most specific predicate to test your conditions.

      - If you intend for a function to be a predicate, have it return T
        for true, not just non-NIL. If there is nothing worth returning
        from a function, returning T is conventional. But if a function
        is intended to be more than just a predicate, it is better to
        return a useful value. (For example, this is one of the differences
        between MEMBER and FIND.)

      - When NIL is used as an empty list, use () in your code. When NIL
        is used as a boolean, use NIL. Similarly, use NULL to test for an
        empty list, NOT to test a logical value. Use ENDP to test for the
        end of a list, not NULL.

      - Don't use the &AUX lambda-list keyword. It is always clearer to
        define local variables using LET or LET*.

      - When using RETURN and RETURN-FROM to exit from a block, don't
        use (VALUES ..) when returning only one value, except if you
        are using it to suppress extra multiple values from the first
        argument.

      - If you want a function to return no values (i.e., equivalent to
        VOID in C), use (VALUES) to return zero values. This signals
        to the reader that the function is used mainly for side-effects.

      - (VALUES (VALUES 1 2 3)) returns only the first value, 1.
        You can use (VALUES (some-multiple-value-function ..)) to suppress
        the extra multiple values from the function. Use MULTIPLE-VALUE-PROG1
        instead of PROG1 when the multiple values are significant.

      - When using MULTIPLE-VALUE-BIND and DESTRUCTURING-BIND, don't rely
        on the fact that NIL is used when values are missing. This is
        an error in some implementations of DESTRUCTURING-BIND. Instead,
        make sure that your function always returns the proper number of
        values.

      - Type the name of external symbols, functions, and variables
        from the COMMON-LISP package in uppercase. This will allow your
        code to work properly in a case-sensitive version of Common Lisp,
        since the print-names of symbols in the COMMON-LISP package
        are uppercase internally. (However, not everybody feels that
        being nice to case-sensitive Lisps is a requirement, so this
        isn't an absolute style rule, just a suggestion.)

    Lisp Idioms:

      - MAPCAN is used with a function to return a variable number of
        items to be included in an output list. When the function returns zero
        or one items, the function serves as a filter. For example,
           (mapcan #'(lambda (x) (when (and (numberp x) (evenp x)) (list x)))
                   '(1 2 3 4 x 5 y 6 z 7))

    Documentation:

      - Comment your code. Use three semicolons in the left margin before
        the definition for major explanations. Use two semicolons that
        float with the code to explain the routine that follows. Two
        semicolons may also be used to explain the following line when the
        comment is too long for the single semicolon treatment. Use
        a single semicolon to the right of the code to explain a particular
        line with a short comment. The number of semicolons used roughly
        corresponds with the length of the comment. Put at least one blank
        line before and after top-level expressions.

      - Include documentation strings in your code. This lets users
        get help while running your program without having to resort to
        the source code or printed documentation.

   Issues related to macros:

      - Never use a macro instead of a function for efficiency reasons.
        Declaim the function as inline -- for example,
          (DECLAIM (INLINE ..))
        This is *not* a magic bullet -- be forewarned that inline
        expansions can often increase the code size dramatically. INLINE
        should be used only for short functions where the tradeoff is
        likely to be worthwhile: inner loops, types that the compiler
        might do something smart with, and so on.

      - When defining a macro that provides an implicit PROGN, use the
        &BODY lambda-list keyword instead of &REST.

      - Use gensyms for bindings within a macro, unless the macro lets
        the user explicitly specify the variable. For example:
            (defmacro foo ((iter-var list) body-form &body body)
              (let ((result (gensym "RESULT")))
                `(let ((,result nil))
                   (dolist (,iter-var ,list ,result)
                     (setq ,result ,body-form)
                     (when ,result
                        ,@body)))))
        This avoids errors caused by collisions during macro expansion
        between variable names used in the macro definition and in the
        supplied body.

      - Use a DO- prefix in the name of a macro that does some kind of
        iteration, WITH- when the macro establishes bindings, and
        DEFINE- or DEF- when the macro creates some definitions. Don't
        use the prefix MAP- in macro names, only in function names.

      - Don't create a new iteration macro when an existing function
        or macro will do.

      - Don't define a macro where a function definition will work just
        as well -- remember, you can FUNCALL or MAPCAR a function but
        not a macro.

      - The LOOP and SERIES macros generate efficient code. If you're
        writing a new iteration macro, consider learning to use one
        of them instead.

   File Modularization:

      - If your program involves macros that are used in more than one
        file, it is generally a good idea to put such macros in a separate
        file that gets loaded before the other files. The same things applies
        to primitive functions. If a macro is complicated, the code that
        defines the macro should be put into a file by itself. In general, if
        a set of definitions form a cohesive and "independent" whole, they
        should be put in a file by themselves, and maybe even in their own
        package. It isn't unusual for a large Lisp program to have files named
        "site-dependent-code", "primitives.lisp", and "macros.lisp". If a file
        contains primarily macros, put "-macros" in the name of the file.

   Stylistic preferences:

      - Use (SETF (CAR ..) ..) and (SETF (CDR ..) ..) in preference to
        RPLACA and RPLACD. Likewise (SETF (GET ..) ..) instead of PUT.

      - Use INCF, DECF, PUSH and POP instead instead of the corresponding
        SETF forms.

      - Many programmers religiously avoid using CATCH, THROW, BLOCK,
        PROG, GO and TAGBODY.  Tags and go-forms should only be necessary
        to create extremely unusual and complicated iteration constructs. In
        almost every circumstance, a ready-made iteration construct or
        recursive implementation is more appropriate.

      - Don't use LET* where LET will do. Don't use LABELS where FLET
        will do. Don't use DO* where DO will do.

      - Don't use DO where DOTIMES or DOLIST will do.

      - If you like using MAPCAR instead of DO/DOLIST, use MAPC when
        no result is needed -- it's more efficient, since it doesn't
        cons up a list. If a single cumulative value is required, use
        REDUCE. If you are seeking a particular element, use FIND,
        POSITION, or MEMBER.

      - If using REMOVE and DELETE to filter a sequence, don't use the
        :test-not keyword or the REMOVE-IF-NOT or DELETE-IF-NOT functions.
        Use COMPLEMENT to complement the predicate and the REMOVE-IF
        or DELETE-IF functions instead.

      - Use complex numbers to represent points in a plane.

      - Don't use lists where vectors are more appropriate. Accessing the
        nth element of a vector is faster than finding the nth element
        of a list, since the latter requires pointer chasing while the
        former requires simple addition. Vectors also take up less space
        than lists. Use adjustable vectors with fill-pointers to
        implement a stack, instead of a list -- using a list continually
        conses and then throws away the conses.

      - When adding an entry to an association list, use ACONS, not
        two calls to CONS. This makes it clear that you're using an alist.

      - If your association list has more than about 10 entries in it,
        consider using a hash table. Hash tables are often more efficient.
        (See also [2-2].)

      - When you don't need the full power of CLOS, consider using
        structures instead. They are often faster, take up less space, and
        easier to use.

      - Use PRINT-UNREADABLE-OBJECT when writing a print-function.

      - Use WITH-OPEN-FILE instead of OPEN and CLOSE.

      - When a HANDLER-CASE clause is executed, the stack has already
        unwound, so dynamic bindings that existed when the error
        occured may no longer exist when the handler is run. Use
        HANDLER-BIND if you need this.

      - When using CASE and TYPECASE forms, if you intend for the form
        to return NIL when all cases fail, include an explicit OTHERWISE
        clause. If it would be an error to return NIL when all cases
        fail, use ECASE, CCASE, ETYPECASE or CTYPECASE instead.

      - Use local variables in preference to global variables whenever
        possible. Do not use global variables in lieu of parameter passing.
        Global variables can be used in the following circumstances:
          *  When one function needs to affect the operation of
             another, but the second function isn't called by the first.
             (For example, *load-pathname* and *break-on-warnings*.)
          *  When a called function needs to affect the current or future
             operation of the caller, but it doesn't make sense to accomplish
             this by returning multiple values.
          *  To provide hooks into the mechanisms of the program.
             (For example, *evalhook*, *, /, and +.)
          *  Parameters which, when their value is changed, represent a
             major change to the program.
             (For example, *print-level* and *print-readably*.)
          *  For state that persists between invocations of the program.
             Also, for state which is used by more than one major program.
             (For example, *package*, *readtable*, *gensym-counter*.)
          *  To provide convenient information to the user.
             (For example, *version* and *features*.)
          *  To provide customizable defaults.
             (For example, *default-pathname-defaults*.)
          *  When a value affects major portions of a program, and passing
             this value around would be extremely awkward. (The example
             here is output and input streams for a program. Even when
             the program passes the stream around as an argument, if you
             want to redirect all output from the program to a different
             stream, it is much easier to just rebind the global variable.)

      - Beginning students, especially ones accustomed to programming
        in C, Pascal, or Fortran, tend to use global variables to hold or pass
        information in their programs. This style is considered ugly by
        experienced Lisp programmers. Although assignment statements can't
        always be avoided in production code, good programmers take advantage
        of Lisp's functional programming style before resorting to SETF and
        SETQ. For example, they will nest function calls instead of using a
        temporary variable and use the stack to pass multiple values. When
        first learning to program in Lisp, try to avoid SETF/SETQ and their
        cousins as much as possible. And if a temporary variable is necessary,
        bind it to its first value in a LET statement, instead of letting it
        become a global variable by default. (If you see lots of compiler
        warnings about declaring variables to be special, you're probably
        making this mistake. If you intend a variable to be global, it should
        be defined with a DEFVAR or DEFPARAMETER statement, not left to the
        compiler to fix.)

   Correctness and efficiency issues:

      - In CLtL2, IN-PACKAGE does not evaluate its argument. Use defpackage
        to define a package and declare the external (exported)
        symbols from the package.

      - The ARRAY-TOTAL-SIZE-LIMIT may be as small as 1024, and the
        CALL-ARGUMENTS-LIMIT may be as small as 50.

      - Novices often mistakenly quote the conditions of a CASE form.
        For example, (case x ('a 3) ..) is incorrect. It would return
        3 if x were the symbol QUOTE. Use (case x (a 3) ..) instead.

      - Avoid using APPLY to flatten lists. Although
           (apply #'append list-of-lists)
        may look like a call with only two arguments, it becomes a
        function call to APPEND, with the LIST-OF-LISTS spread into actual
        arguments. As a result it will have as many arguments as there are
        elements in LIST-OF-LISTS, and hence may run into problems with the
        CALL-ARGUMENTS-LIMIT. Use REDUCE or MAPCAN instead:
           (reduce #'append list-of-lists :from-end t)
           (mapcan #'copy-list list-of-lists)
        The second will often be more efficient (see note below about choosing
        the right algorithm). Beware of calls like (apply f (mapcar ..)).

      - NTH must cdr down the list to reach the elements you are
        interested in. If you don't need the structural flexibility of
        lists, try using vectors and the ELT function instead.

      - CASE statements can be vectorized if the keys are consecutive
        numbers. Such CASE statements can still have OTHERWISE clauses.
        To take advantage of this without losing readability, use #. with
        symbolic constants:

            (eval-when (compile load eval)
               (defconstant RED 1)
               (defconstant GREEN 2)
               (defconstant BLUE 3))

            (case color
              (#.RED   ...)
              (#.GREEN ...)
              (#.BLUE  ...)
              ...)

      - Don't use quoted constants where you might later destructively
        modify them. For example, instead of writing '(c d) in
           (defun foo ()
             (let ((var '(c d)))
               ..))
        write (list 'c 'd) instead. Using a quote here can lead to
        unexpected results later. If you later destructively modify the
        value of var, this is self-modifying code! Some Lisp compilers
        will complain about this, since they like to make constants
        read-only. Modifying constants has undefined results in ANSI CL.
        See also the answer to question [3-13].

        Similarly, beware of shared list structure arising from the use
        of backquote. Any sublist in a backquoted expression that doesn't
        contain any commas can share with the original source structure.

      - Don't proclaim unsafe optimizations, such as
           (proclaim '(optimize (safety 0) (speed 3) (space 1)))
        since this yields a global effect. Instead, add the
        optimizations as local declarations to small pieces of
        well-tested, performance-critical code:
           (defun well-tested-function ()
              (declare (optimize (safety 0) (speed 3) (space 1)))
             ..)
        Such optimizations can remove run-time type-checking; type-checking
        is necessary unless you've very carefully checked your code
        and added all the appropriate type declarations.

      - Some programmers feel that you shouldn't add declarations to
        code until it is fully debugged, because incorrect
        declarations can be an annoying source of errors. They recommend
        using CHECK-TYPE liberally instead while you are developing the code.
        On the other hand, if you add declarations to tell the
        compiler what you think your code is doing, the compiler can
        then tell you when your assumptions are incorrect.
        Declarations also make it easier for another programmer to read
        your code.

      - Declaring the type of variables to be FIXNUM does not
        necessarily mean that the results of arithmetic involving the
        fixnums will be a fixnum; it could be a BIGNUM. For example,
           (declare (type fixnum x y))
           (setq z (+ (* x x) (* y y)))
        could result in z being a BIGNUM. If you know the limits of your
        numbers, use a declaration like
           (declare (type (integer 0 100) x y))
        instead, since most compilers can then do the appropriate type
        inference, leading to much faster code.

      - Don't change the compiler optimization with an OPTIMIZE
        proclamation or declaration until the code is fully debugged
        and profiled.  When first writing code you should say
        (declare (optimize (safety 3))) regardless of the speed setting.

      - Depending on the optimization level of the compiler, type
        declarations are interpreted either as (1) a guarantee from
        you that the variable is always bound to values of that type,
        or (2) a desire that the compiler check that the variable is
        always bound to values of that type. Use CHECK-TYPE if (2) is
        your intention.

      - If you get warnings about unused variables, add IGNORE
        declarations if appropriate or fix the problem. Letting such
        warnings stand is a sloppy coding practice.

   To produce efficient code,

      - choose the right algorithm. For example, consider seven possible
        implementations of COPY-LIST:

           (defun copy-list (list)
             (let ((result nil))
               (dolist (item list result)
                 (setf result (append result (list item))))))

           (defun copy-list (list)
             (let ((result nil))
               (dolist (item list (nreverse result))
                 (push item result))))

           (defun copy-list (list)
             (mapcar #'identity list))

           (defun copy-list (list)
             (let ((result (make-list (length list))))
               (do ((original list (cdr original))
                    (new result (cdr new)))
                   ((null original) result)
                 (setf (car new) (car original)))))

           (defun copy-list (list)
             (when list
               (let* ((result (list (car list)))
                      (tail-ptr result))
                 (dolist (item (cdr list) result)
                   (setf (cdr tail-ptr) (list item))
                   (setf tail-ptr (cdr tail-ptr))))))

            (defun copy-list (list)
              (loop for item in list collect item))

            (defun copy-list (list)
              (if (consp list)
                  (cons (car list)
                        (copy-list (cdr list)))
                  list))

        The first uses APPEND to tack the elements onto the end of the list.
        Since APPEND must traverse the entire partial list at each step, this
        yields a quadratic running time for the algorithm.  The second
        implementation improves on this by iterating down the list twice; once
        to build up the list in reverse order, and the second time to reverse
        it. The efficiency of the third depends on the Lisp implementation,
        but it is usually similar to the second, as is the fourth.  The fifth
        algorithm, however, iterates down the list only once. It avoids the
        extra work by keeping a pointer (reference) to the last cons of the
        list and RPLACDing onto the end of that. Use of the fifth algorithm
        may yield a speedup. Note that this contradicts the earlier dictum to
        avoid destructive functions. To make more efficient code one might
        selectively introduce destructive operations in critical sections of
        code. Nevertheless, the fifth implementation may be less efficient in
        Lisps with cdr-coding, since it is more expensive to RPLACD cdr-coded
        lists. Depending on the implementation of nreverse, however,
        the fifth and second implementations may be doing the same
        amount of work. The sixth example uses the Loop macro, which usually
        expands into code similar to the third. The seventh example copies
        dotted lists, and runs in linear time, but isn't tail-recursive.

        There is a long-running discussion of whether pushing items
    onto a list and then applying NREVERSE to the result is faster or
    slower than the alternatives. According to Richard C. Waters (Lisp
    Pointers VI(4):27-34, October-December 1993), the NREVERSE strategy is
    slightly faster in most Lisp implementations. But the speed difference
    either way isn't much, so he argues that one should pursue the option
    that yields the clearest and simplest code, namely using NREVERSE.

        Here's code for a possible implementation of NREVERSE. As is
        evident, most of the alternatives to using NREVERSE involve
        essentially the same code, just reorganized.

       (defun nreverse (list)
         ;; REVERSED is the partially reversed list,
         ;; CURRENT is the current cons cell, which will be reused, and
         ;; REMAINING are the cons cells which have not yet been reversed.
         (do* ((reversed nil)
           (current list remaining)
           (remaining (cdr current) (cdr current)))
         ((null current)
          reversed)
           ;; Reuse the cons cell at the head of the list:
           ;;    reversed := ((car remaining) . reversed)
           (setf (cdr current) reversed)
           (setf reversed current)))

      - use type declarations liberally in time-critical code, but
        only if you are a seasoned Lisp programmer. Appropriate type
        declarations help the compiler generate more specific and
        optimized code. It also lets the reader know what assumptions
        were made. For example, if you only use fixnum arithmetic,
        adding declarations can lead to a significant speedup. If you
        are a novice Lisp programmer, you should use type declarations
        sparingly, as there may be no checking to see if the
        declarations are correct, and optimized code can be harder to
        debug. Wrong declarations can lead to errors in otherwise
        correct code, and can limit the reuse of code in other
        contexts. Depending on the Lisp compiler, it may also
        be necessary to declare the type of results using THE, since
        some compilers don't deduce the result type from the inputs.

      - check the code produced by the compiler by using the
        disassemble function

----------------------------------------------------------------
Subject: [1-4] Where can I learn about implementing Lisp interpreters
               and compilers?

Books about Lisp implementation include:

   1. John Allen
      "Anatomy of Lisp"
      McGraw-Hill, 1978. 446 pages. ISBN 0-07-001115-X
           Discusses some of the fundamental issues involved in
           the implemention of Lisp.

   2. Samuel Kamin
      "Programming Languages, An Interpreter-Based Approach"
      Addison-Wesley, Reading, Mass., 1990. ISBN 0-201-06824-9
           Includes sources to several interpreters for Lisp-like languages.
           The source for the interpreters in the book is available
           by anonymous FTP from
              a.cs.uiuc.edu:/pub/kamin/kamin.distr/
          Tim Budd reimplemented the interpreters in C++, and has made
          them available by anonymous ftp from
              cs.orst.edu:/pub/budd/kamin/

   3. Sharam Hekmatpour
      "Lisp: A Portable Implementation"
      Prentice Hall, 1985. ISBN 0-13-537490-X.
           Describes a portable implementation of a small dynamic
           Lisp interpreter (including C source code).

   4. Peter Henderson
      "Functional Programming: Application and Implementation"
      Prentice-Hall (Englewood Cliffs, NJ), 1980. 355 pages.

   5. Peter M. Kogge
      "The Architecture of Symbolic Computers"
      McGraw-Hill, 1991. ISBN 0-07-035596-7.
           Includes sections on memory management, the SECD and
           Warren Abstract Machines, and overviews of the various
           Lisp Machine architectures.

   6. Daniel P. Friedman, Mitchell Wand, and Christopher T. Haynes
      "Essentials of Programming Languages"
      MIT Press, 1992, 536 pages. ISBN 0-262-06145-7.
           Teaches fundamental concepts of programming language
           design by using small interpreters as examples. Covers
           most of the features of Scheme. Includes a discussion
           of parameter passing techniques, object oriented languages,
           and techniques for transforming interpreters to allow
           their implementation in terms of any low-level language.
           Also discusses scanners, parsers, and the derivation of
           a compiler and virtual machine from an interpreter.
           Includes a few chapters on converting code into a
           continuation passing style.
           Source files available by anonymous ftp from
              cs.indiana.edu:/pub/eopl/ [129.79.254.191].

   7. Peter Lee, editor, "Topics in Advanced Language Implementation",
      The MIT Press, Cambridge, Mass., 1991.
           Articles relevant to the implementation of functional
           programming languages.

   8. Also see the proceedings of the biannual ACM Lisp and Functional
      Programming conferences, the implementation notes for CMU Common Lisp,
      Norvig's book, and SICP (Abelson & Sussman).

   9. Christian Queinnec
      "Les Langages Lisp"
      InterEditions (in French), 1994. 500 pages.
      ISBN 2-7296-0549-5, 61-2448-1. (?)

      The book covers Lisp, Scheme and other related dialects,
      their interpretation, semantics and compilation.

      All of the programs described in the book are available by
      anonymous ftp from
         ftp.inria.fr:/INRIA/Projects/icsla/Books/LiSP94Sep05.tar.gz
      For more information, see the book's URL
         file://ftp.inria.fr/INRIA/Projects/icsla/WWW/LiSP.html
      or contact the author at [e-mail]

----------------------------------------------------------------
Subject: [1-5] What is the "minimal" set of primitives needed for a Lisp
               interpreter?

Many Lisp functions can be defined in terms of other Lisp functions.
For example, CAAR can be defined in terms of CAR as
   (defun caar (list) (car (car list)))
It is then natural to ask whether there is a "minimal" or smallest set
of primitives necessary to implement the language.

There is no single "best" minimal set of primitives; it all depends on
the implementation. For example, even something as basic as numbers
need not be primitive, and can be represented as lists. One possible
set of primitives might include CAR, CDR, and CONS for manipulation of
S-expressions, READ and PRINT for the input/output of S-expressions
and APPLY and EVAL for the guts of an interpreter.  But then you might
want to add LAMBDA for functions, EQ for equality, COND for
conditionals, SET for assignment, and DEFUN for definitions. QUOTE
might come in handy as well. If you add more specialized datatypes,
such as integers, floats, arrays, characters, and structures, you'll
need to add primitives to construct and access each.

AWKLisp is a Lisp interpreter written in awk, available by anonymous
ftp from ftp.cs.cmu.edu:/user/ai/lang/lisp/impl/awk/. It has thirteen
built-in functions: CAR, CDR, CONS, EQ, ATOM, SET, EVAL, ERROR, QUOTE,
COND, AND, OR, LIST.

A more practical notion of a "minimal" set of primitives might be to
look at the implementation of Scheme. While many Scheme functions can
be derived from others, the language is much smaller than Common Lisp.
See Dybvig's PhD thesis,
   R. Kent Dybvig, "Three Implementation Models for Scheme", Department
   of Computer Science Technical Report #87-011, University of North
   Carolina at Chapel Hill, Chapel Hill, North Carolina, April 1987.
for a justification of a particularly practical minimal set of
primitives for Scheme.

In a language like Common Lisp, however, there are a lot of low-level
primitive functions that cannot be written in terms of the others,
such as GET-UNIVERSAL-TIME, READ-CHAR, WRITE-CHAR, OPEN, and CLOSE,
for starters.  Moreover, real Common Lisp implementations are often
built upon primitives that aren't part of the language, per se, and
certainly not intended to be user-accessible, such as SYS:%POINTER-REF.

Beside the references listed in [1-4], some other relevant references
include:

    McCarthy, John, "Recursive Functions of Symbolic Expressions and
    their Computation by Machine, Part I", CACM 3(4):185-195, April 1960.
       [Defines five elementary functions on s-expressions.]

    McCarthy, John, "A Micro-Manual for Lisp -- not the whole Truth",
    ACM SIGPLAN Notices, 13(8):215-216, August 1978.
       [Defines the Lisp programming language in 10 rules and gives
        a small interpreter (eval) written in this Lisp.]

    McCarthy, John, et al., "LISP 1.5 Programmer's Manual", 2nd edition,
    MIT Press, 1965, ISBN 0-262-13011-4 (paperback).
       [Gives five basic functions, CAR, CDR, CONS, EQ, and ATOM.
        Using composition, conditional expressions (COND), and
        recursion, LAMBDA, and QUOTE, these basic functions may be used
        to construct the entire class of computable functions of
        S-expressions. Gives the functions EVAL and APPLY in
        M-expression syntax.]

    Abelson and Sussman's SICP, especially chapters 4 and 5 on the
    implementation of meta-circular and explicit-control evaluators.

    Steele and Gabriel's "The Evolution of LISP".

----------------------------------------------------------------
Subject: [1-6]  What does CLOS, PCL, X3J13, CAR, CDR, ... mean?

Glossary of acronyms:
   CAR             Originally meant "Contents of Address portion of Register",
                   which is what CAR actually did on the IBM 704.
   CDR             Originally meant "Contents of Decrement portion of
                   Register", which is what CDR actually did
                   on the IBM 704. Pronounced "Cudder" /kUdd@r/ (as in "a cow
                   chews its cdr"). The first syllable is pronounced
                   like "could".
   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". See also PCL.
   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
   dpANS           draft proposed American National Standard (what an ANS
                   is called while it's in the public review stage of
                   standardization).
   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 Electrotechnical Commission, Joint
                   Technical Committee 1 Subcommittee 22 (full name
                   "Information Technology -- Programming Languages
                   and their Environments"), 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".

----------------------------------------------------------------
Subject: [1-7] Lisp Job Postings

The LISP-JOBS mailing list exists to help programmers find Lisp
programming positions, and to help companies with Lisp programming
positions find capable Lisp programmers. (Lisp here means Lisp-like
languages, including Scheme.)

Material appropriate for the list includes Lisp job announcements and
should be sent to [e-mail]. Resumes should NOT be sent to
the list.

[Note: The 'ai+' part of the mailing list name is used for directing
submissions to the appropriate mail-server. The list is NOT restricted
to AI-related Lisp jobs -- all Lisp job announcements are welcome.]

As a matter of policy, the contents of this mailing list is
considered confidential and will not be disclosed to anybody.

To subscribe, send a message to [e-mail] with
   subscribe lisp-jobs <First Name> <Last Name>, <Affiliation/Organization>
in the message body.

(If your mailer objects to the "+", send subscription requests to
"ai+query"@cs.cmu.edu, job announcements to "ai+lisp-jobs"@cs.cmu.edu, etc.)

For help on using the query server, send mail to [e-mail] with
   help
in the message body.

Job postings sent to the list are automatically archived in
   ftp.cs.cmu.edu:/user/ai/jobs/lisp/

If you have any other questions, please send them to [e-mail]

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

;;; *EOF*
Archive-name: lisp-faq/part2
Last-Modified: Wed Mar  8 20:37:22 1995 by Mark Kantrowitz
Version: 1.53
Maintainer: Mark Kantrowitz and Barry Margolin <[e-mail]>
URL: http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/lisp/top.html
Size: 49042 bytes, 988 lines

;;; ****************************************************************
;;; Answers to Frequently Asked Questions about Lisp ***************
;;; ****************************************************************
;;; Written by Mark Kantrowitz and Barry Margolin
;;; lisp_2.faq

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 [e-mail].

Topics Covered (Part 2):

  [2-1]   Is there a GNU-Emacs interface to Lisp?
  [2-2]   When should I use a hash table instead of an association list?
  [2-3]   What is the equivalent of EXPLODE and IMPLODE in Common Lisp?
  [2-4]   Is Lisp inherently slower than more conventional languages such as C?
  [2-5]   Why does Common Lisp have "#'"?
  [2-6]   How do I call non-Lisp functions from Lisp?
  [2-7]   Can I call Lisp functions from other languages?
  [2-8]   I want to call a function in a package that might not exist at
          compile time. How do I do this?
  [2-9]   What is CDR-coding?
  [2-10]  What is garbage collection?
  [2-11]  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 exit Lisp?
  [2-12]  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-13]  History: Where did Lisp come from?
  [2-14]  How do I find the argument list of a function?
          How do I get the function name from a function object?
  [2-15]  How can I have two Lisp processes communicate via unix sockets?
  [2-16]  How can I create a stream that acts like UNIX's /dev/null
          (i.e., gobbles any output and immediately signals EOF on
          input operations)?
  [2-17]  Read-time conditionalization of code (#+ #- and *features*)
  [2-18]  What reader macro characters are used in major Lisp systems?
  [2-19]  How do I determine if a file is a directory or not?
          How do I get the current directory name from within a Lisp
          program? Is there any way to create a directory?
  [2-20]  What is a "Lisp Machine" (LISPM)?
  [2-21]  How do I tell if a symbol names a function and not a macro?

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

----------------------------------------------------------------
Subject: [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 <[e-mail]> and now maintained by Marco Antoniotti
<[e-mail]> and Rick Busdiecker <[e-mail]>.  It is
available by anonymous ftp from
   h.gp.cs.cmu.edu:/usr/rfb/ilisp/ [128.2.254.156]
as the file ilisp-5.6.tar.gz.  It is also available in the CMU AI
Repository in
   ftp.cs.cmu.edu:/user/ai/lang/lisp/util/emacs/ilisp/
If you want to be on the ilisp mailing list, to hear about new
releases and patches, send mail to [e-mail].  Please
send any comments, code, or bug reports to [e-mail].

Franz Inc.'s GNU-Emacs/Lisp interface includes an online Common Lisp
manual. (The manual is available by license from Franz Inc. Contact
[e-mail] for more information.) The Emacs-Lisp interface
(without the online Common Lisp reference manual and some
Allegro-specific code) is available free from
   ftp.uu.net:/vendor/franz/emacs/eli-2.0.11.tar.gz
and takes advantage of GNU-Emacs 19.X's newest features, including
support for mouse input, pulldown menus, and multifont text. The
interface also supports Epoch 3.2 and 4.2, and LEmacs 19.6 and 19.8.
For discussion of the Franz lisp-emacs interface, join the
[e-mail] mailing list.
(See also [1-2] for a hardcopy version of the Common Lisp reference manual.)

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.

GNU-Emacs itself is available by anonymous ftp from prep.ai.mit.edu.

Edebug, a debugger for Emacs Lisp, and some utilities for Common Lisp
debugging (Dave Gillespie's version of cl.el) are available by
anonymous ftp from
   a.cs.uiuc.edu:/pub/edebug/
To join the Edebug mailing list [e-mail] send mail to
[e-mail]. For more information, write to Daniel
LaLiberte <[e-mail]>.

----------------------------------------------------------------
Subject: [2-2] When should I use a hash table instead of an association list?

Both association lists (alists) and hash tables may be used to
represent tabular data. Hash tables have an O(1) running time and
alists an O(n) running time, so hash tables are ultimately more
efficient than alists. However, if the alists are small, they can be
more efficient than hash tables, which have a large initial overhead.

Alists can sometimes be more efficient if the keys are sorted
according to frequency, with the most heavily accessed keys appearing
at the front of the list. But one doesn't always know this kind of
information, and even then the frequency distribution may be flat.

In Allegro CL 4.1 [SPARC; R1], the rule of thumb is that for less than
24 elements, linear search using alists beats hashing.  In Lucid CL
4.0.1 HP 9000/700, the break-even point is at 10 elements. The
break-even points vary in other lisps from as low as 4 elements to as
high as 100 elements. So if you're using alists in your code, using
hash tables instead may speed up your program.

A potential problem may occur, however, when the keys of an EQ or EQL
hash table are Lisp objects such as conses or arrays (or other objects
that are identified by their addresses). In most implementations, such
tables must be re-hashed after garbage collection. If your application
causes frequent GCs, this can adversely affect the performance of hash
table lookup. Since EQL-hashing and =-hashing of fixnums generally
don't require rehashing after GC, one way of avoiding this problem is
to include a unique identifier in each key object and hash on that
instead. Another solution is to use an EQUAL hash table if the keys
are conses or an EQUALP hash table if the keys are arrays or other
(non-circular!) structures.

----------------------------------------------------------------
Subject: [2-3] 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.

----------------------------------------------------------------
Subject: [2-4] Is Lisp inherently slower than more conventional languages
               such as C?

This is a tough question to answer, as you probably 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 denser (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. A more
recent test found that numeric code compiled with optimizations using
CMU CL is within the same ballpark as highly optimized Fortran code.
For unoptimized Fortran code, CMU CL was about 4 times faster.
Even the speed of numeric code generated by other Lisp compilers
(AKCL, Allegro, Lucid) was well within an order of magnitude of good
Fortran and C compilers (although slower than CMU CL).  Inspection of
the emitted C code from AKCL doesn't reveal many obvious sources of
inefficiency. (Since AKCL compiles Lisp into C, there are many cases
where KCL code is as fast as hand-written C code.)

See the paper peoplesparc.berkeley.edu:/pub/papers/fastlisp.ps.Z
for a discussion of the speed of Lisp vis a vis Fortran or C.

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.

----------------------------------------------------------------
Subject: [2-5] 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.

----------------------------------------------------------------
Subject: [2-6] 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, one 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.

----------------------------------------------------------------
Subject: [2-7] 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. Note that in such foreign function
interfaces Lisp is often left "in control" of things like memory
allocation, I/O channels, and startup code (this is a major nuisance
for lots of people).

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

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

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

----------------------------------------------------------------
Subject: [2-10] 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 (aka emphemeral GC) 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.

----------------------------------------------------------------
Subject: [2-11] 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 exit Lisp?

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")
   LispWorks:        LW:SAVE-IMAGE
Be sure to garbage collect before dumping the image. You may need to
experiment with the kind of garbage collection for large images, and
may find better results if you build the image in stages.

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 (command &key input output
                                  error-output wait if-input-does-not-exist
                                  if-output-exists if-error-output-exists)
   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").
                        You can also try RUN-PROCESS and EXCLP, but they
                        don't work with all versions of KCL.
   CMU CL:              RUN-PROGRAM (program args
               &key (env *environment-list*) (wait t) pty input
               if-input-does-not-exist output
               (if-output-exists :error) (error :output)
               (if-error-exists :error) status-hook before-execve)
   LispWorks:           FOREIGN:CALL-SYSTEM-SHOWING-OUTPUT

To toggle source file recording and cross-reference annotations, use
   Allegro:             excl:*record-source-file-info*
            excl:*load-source-file-info*
            excl:*record-xref-info*
            excl:*load-xref-info*
   LispWorks:           (toggle-source-debugging nil)

Memory management:
   CMU CL:              (bytes-consed-between-gcs)  [this is setfable]
   Lucid:        (change-memory-management
                     &key growth-limit expand expand-reserved)
   Allegro:        *tenured-bytes-limit*
   LispWorks:           LW:GET-GC-PARAMETERS
                        (use LW:SET-GC-PARAMETERS to change them)

Exiting/Quitting:
   CLISP:               EXIT
   Allegro:             EXIT (&optional excl::code &rest excl::args
                              &key excl::no-unwind excl::quiet)
   LispWorks:           BYE (&optional (arg 0))
   Lucid:               QUIT (&optional (lucid::status 0))
   CMU CL:              QUIT (&optional recklessly-p)

----------------------------------------------------------------
Subject: [2-12] 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 (^ means control):
   ^]      >=      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
   ^A              down arrow
   ^K              up arrow
   ^D              up caret
   ^_              down caret
   ^T              forall
   ^U              there exists
   ^B              alpha
   ^C              beta
   ^I              gamma
   ^J              delta
   ^O              partial delta
   ^N              infinity
   ^M              circle +
   ^V              circle x

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 "". In format statements, ^P and ^Q are used to delimit text to
be printed in a particular character style.

----------------------------------------------------------------
Subject: [2-13] 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            Steele publishes CLtL2 which offers a snapshot of
                   work in progress by X3J13.  (Unlike CLtL1, CLtL2
                   was NOT an output of the standards process and was
                   not intended to become a de facto standard.  Read
                   the Second Edition Preface for further explanation
                   of this important issue.) Includes CLOS,
                   conditions, pretty printing and iteration facilities.

   1992            X3J13 creates a draft proposed American National
                   Standard for Common Lisp. This document is the
                   first official successor to CLtL1.

[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. See [4-12] for information on obtaining a copy.]

Gabriel and Steele's "The Evolution of Lisp", which appeared in the
1993 ACM History of Programming Languages conference, is available by
anonymous ftp from
   ftp.cs.umbc.edu:/pub/Memoization/Misc/    [130.85.100.53]
as Evolution-of-Lisp.ps.Z.

Brad Miller maintains a Lisp History web page at
   http://www.cs.rochester.edu/u/miller/Lisp-History.html

----------------------------------------------------------------
Subject: [2-14]  How do I find the argument list of a function?
                 How do I get the function name from a function object?

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
   LispWorks:                           lw:function-lambda-list

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

The draft ANSI standard does include FUNCTION-LAMBDA-EXPRESSION and
FUNCTION-KEYWORDS, which can be used to create an ARGLIST function.

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

To extract the function name from the function object, as in
        (function-name #'car) ==> 'car
use the following vendor-dependent functions:

   Symbolics: (si::compiled-function-name <fn>)
    (unless (si:lexical-closure-p <fn>) ...)
   Lucid:     (sys::procedure-ref <fn> SYS:PROCEDURE-SYMBOL)
    (when (sys:procedurep <fn>) ..)
   Allegro:   (xref::object-to-function-name <fn>)
   CMU CL:    (kernel:%function-header-name <fn>)
   AKCL:      (system::compiled-function-name <fn>)
   MCL:       (ccl::function-name <fn>)
   LispWorks: (system::function-name <fn>)

If a vendor-dependent function does not exist, the following
(inefficient) code maps over all symbols looking for one whose
function-cell matches the function object.

(defun function-name (fobject)
   (do-all-symbols (fsymbol)
      (when (and (fboundp fsymbol)
                 (eq (symbol-function fsymbol) fobject))
        (return fsymbol))))

If a vendor supports FUNCTION-LAMBDA-EXPRESSION, the third value is
the name of the function, if available.

----------------------------------------------------------------
Subject: [2-15] 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 [7-1].

See the file sockets.tar.gz in the Lisp Utilities repository
described in the answer to question [6-1].

----------------------------------------------------------------
Subject: [2-16]  How can I create a stream that acts like UNIX's /dev/null
                 (i.e., gobbles any output and immediately signals EOF on
                 input operations)?

(defparameter *dev-null*
  #-lispm
  (make-two-way-stream (make-concatenated-stream) (make-broadcast-stream))
  ;; Since Lisp Machines have a built-in /dev/null which handles
  ;; additional, non-standard operations, we'll use that instead.
  #+lispm #'system:null-stream)

----------------------------------------------------------------
Subject: [2-17] Read-time conditionalization of code (#+ #- and *features*)

The #+ and #- syntax provides for the read-time conditionalization of
lisp code, depending on the presence or absence of keywords on the
*features* list. The nascent Common Lisp standard does not specify
what keywords an implementation must have on its features list.
Nevertheless, most implementations have features that allow one to
distinguish the implementation from other implementations. This allows
one to write implementation-dependent code that is run only in the
relevant implementations.

Here is a list of the features to use to specify a particular Common
Lisp implementation. Unfortunately, not every vendor has a
unique keyword that distinguishes their family of implementations from
those of other vendors, nor major and minor versions of the implementation.

   :lucid                       Lucid Common Lisp
   :lcl3.0                      Lucid Common Lisp v3.0 and above
   :lcl4.0                      Lucid Common Lisp v4.0 and above
   ----------------
   (and :allegro :franz-inc)    Franz Allegro Common Lisp
   :excl                        Franz Allegro Common Lisp
   :aclpc                       Franz Allegro Common Lisp\PC.
   :allegro-v3.0                Franz Allegro Common Lisp v3.0
   :allegro-v3.1                Franz Allegro Common Lisp v3.1
   :allegro-v4.0                Franz Allegro Common Lisp v4.0
   :allegro-v4.1                Franz Allegro Common Lisp v4.1
   ----------------
   :cmu                         CMU Common Lisp
   (and :cmu :new-compiler)     CMU Common Lisp w/Python compiler
   (and :cmu :python)           CMU Common Lisp w/Python compiler
   :cmu17                       CMU Common Lisp v17 and above
   ----------------
   kcl                          Kyoto Common Lisp
   akcl                         Austin KCL
   :ibcl                        Ibuki Common Lisp
   ----------------
   :mcl                         Macintosh Common Lisp
   :coral                       Coral Lisp; bought by Apple to become
                MACL, then MCL
   :ccl                         Coral Common Lisp
    [Note: Harlequin LispWorks also uses :ccl]
   :ccl-1                       Coral Common Lisp v1
   :ccl-1.3                     Coral Common Lisp v1.3 and higher
   :ccl-2                       present in Macintosh Common Lisp 2.0 and higher
   ----------------
   :harlequin-common-lisp       Harlequin Common Lisp
   :harlequin-unix-lisp         Harlequin on Unix platforms
   :harlequin-PC-lisp           Harlequin on PC platforms
   :lispworks                   Harlequin LispWorks development environment
   :lispworks3                  major release of Harlequin LispWorks
   :lispworks3.1                major and minor release of Harlequin LispWorks
   :harlequin                   All Harlequin products. not always present?
   ----------------
   :clisp                       CLISP Common Lisp
   ----------------
   :symbolics                   Symbolics Genera
   :imach                       Symbolics Genera for Ivory architecture
   :cloe-runtime                Symbolics CLOE
   :cloe                        CLOE 3.1
   ----------------
   :procyon                     Procyon Common Lisp
   (and :procyon :macintosh)    Procyon Common Lisp, Macintosh version
   (and :procyon :os2)          Procyon Common Lisp, OS2 version
   ----------------
   :gclisp                      Golden Common Lisp
   ----------------
   (and dec vax common)         DEC VAXlisp
   ----------------
   :explorer                    TI Explorer Lisp Machine  | used
   :TI                          TI Explorer Lisp Machine  | interchangeably
   :elroy                       TI Explorer release 3 and successors
   ----------------
   :Xerox                       Medley (Venue's CL/InterLisp combo) to rel2.01
   :medley                      Medley releases 3.0 and up
      Use  (IL:UNIX-GETPARM "mach") and (IL:UNIX-GETPARM "arch") to
      distinguish platforms under Medley.
   ----------------
   :ecl                         ECoLisp
   ----------------
   :lispm                       Symbolics, TI, and LMI Lisp machines

   In the cases where a feature is not a keyword, it is almost always
   in the LISP package.

The draft ANSI standard defines some other useful features:

  :cltl1                Compatible with the 1st edition of Steele
  :cltl2                Compatible with the 2nd edition of Steele
  :IEEE-Floating-Point  IEEE floating point support
  :X3J13                conforms to some particular draft of the ANSI
                        CL specification
  :draft-ANSI-CL        conforms to first full public review draft
  :ANSI-CL              conforms to ANSI CL after its adoption
  :common-lisp          language family "Common Lisp"

Other features used by some Lisps include:

  :clos                 Contains a native CLOS implementation.
  :pcl                  Contains the PCL implementation of CLOS.
  :flavors              Has an implementation of Symbolics Flavors
  :loop                 Contains the :cltl1 version of the Loop macro
  :ansi-loop            Contains the ANSI Loop macro
  :clx or :xlib         Contains CLX
  :clxr4 or :CLX-MIT-R4 Contains CLX for X11R4
  :clxr5 or :CLX-MIT-R5 Contains CLX for X11R5
  :compiler             Contains a compiler
  :windows              MS Windows version
  :color                Color display
  :monochrome           Monochrome display
  :multiprocessing      Has multiprocessing capabilities.
  :profiler             Has a PC-monitoring based profiler.

Platform-specific features, CPU-dependent features, and
operating-system specific features are also important because they can
indicate changes between different implementations of the same lisp,
such as compiled file extensions (e.g., .sbin, .hbin, etc.).
Unfortunately, not every vendor includes such features, and the naming
conventions are inconsistent. Where there are several names for the
same feature, we've put the preferred name first. Hopefully the
vendors will begin to standardize their use of these features.
CPU-dependent features include :sparc (used in CMU CL, Lucid CL,
Harlequin, and Allegro CL), :mips (used in Allegro CL), :r2000 (used
in Allegro CL even on r4000 machines), :mc68000, and :pa (HP's
9000/800 RISC cpu).  Platform-specific features include :sun (used in
Allegro CL and Lucid), :sun4 (used in CMU CL and Allegro CL), :sgi
(used in Allegro CL), :hp300, :hp400, :hp500, :sun3, :vax, :prime,
:dec, :dec3100, :macintosh (used in Procyon but not MCL), :ibm-pc,
:ibm-rt-pc.  OS-specific features include :unix (used in CMU CL, IBCL,
and Lucid CL), :vms, :sunos (used in CMU CL), :sun-os (used in Lucid),
:sunos4.0 and :sunos4 (used in various Allegro versions independent of
the actual version of SunOS), :mach (used in CMU CL), :hpux, :ultrix,
:os2, and :svr4.

Notes:

   :allegro alone doesn't suffice to distinguish Franz Allegro Common
   Lisp from Macintosh Allegro Common Lisp (an early version of
   Macintosh Common Lisp). :excl specifies that the EXCL package (a
   set of Allegro extensions to Common Lisp) is present, but this has
   since become synonymous with Franz Allegro Common Lisp.

   Thanks to Vincent Keunen for gathering the information in this list.

----------------------------------------------------------------
Subject: [2-18]  What reader macro characters are used in major Lisp systems?

The draft ANSI standard for Common Lisp leaves many dispatching macro
characters unassigned. Of these, the following are explicitly reserved
for the user and hence will never be defined by Common Lisp:
   #!, #?, #[, #], #{, and #}.
All other unassigned macro characters are not reserved for the user,
and hence the user has no guarantee that they won't be used by some
Lisp implementation.

As a result, there is the potential of portability clashes between
systems that use the same macro characters. This question lists the
non-standard macro character usage of major Lisp systems, in an effort
to avoid such conflicts.

   #"        AKCL; pathnames
   #$        Macintosh Common Lisp; traps
   #%        Cyc; references to constants in the representation language
   #%        Harlequin LispWorks; ?
   #@        Macintosh Common Lisp; Points notation
   #@         Defsystem
   #I        Portable Infix Package
   #L        Allegro Common Lisp; logical pathnames
   #M        Series
   #T         Allegro Common Lisp; ?
   #Y        CLISP; ?
   #Z        Series
   #_        Macintosh Common Lisp; traps
   #`        Harlequin LispWorks; ?

There is a proposal in the ANSI draft to have COMPILE-FILE and LOAD
bind *READTABLE*, which would allow one to locally redefine syntax
through private readtables. Unfortunately, this doesn't help with the
Infix Package, where one wants to globally extend syntax.

----------------------------------------------------------------
Subject: [2-19] How do I determine if a file is a directory or not?
                How do I get the current directory name from within a Lisp
                program? Is there any way to create a directory?

There is no portable way in Common Lisp of determining whether a file
is a directory or not. Calling DIRECTORY on the pathname will not
always work, since the directory could be empty. For UNIX systems
   (defun DIRECTORY-P (pathname)
      (probe-file (concatenate 'string pathname "/.")))
seems to work fairly reliably. (If "foo" is a directory, then "foo/."
will be a valid filename; if not, it will return NIL.) This won't, of
course, work on the Macintosh, or on other operating systems (e.g.,
MVS, CMS, ITS). On the Macintosh, use DIRECTORYP.

Moreover, some operating systems may not support the concept of
directories, or even of a file system. For example, recent work on
object-oriented technology considers files to be collections of
objects. Each type of collection defines a set of methods for reading
and writing the objects "stored" in the collection.


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
   LispWorks:           LW:*CURRENT-WORKING-DIRECTORY*
                        (use LW:CHANGE-DIRECTORY to change it)

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.

There is no portable way of creating a new directory from within a
Lisp program.

----------------------------------------------------------------
Subject: [2-20] What is a "Lisp Machine" (LISPM)?

A Lisp machine (or LISPM) is a computer which has been optimized to run lisp
efficiently and provide a good environment for programming in it. The
original Lisp machines were implemented at MIT, with spinoffs as LMI (defunct)
and Symbolics (bankrupt). Xerox also had a series of Lisp machines
(Dandylion, Dandytiger), as did Texas Instruments (TI Explorer). The
TI and Symbolics Lisp machines are currently available as cards that
fit into Macintosh computers (the so-called "Lisp on a chip").

Optimizations typical of Lisp machines include:

   - Hardware Type Checking. Special type bits let the type be checked
     efficiently at run-time.

   - Hardware Garbage Collection.

   - Fast Function Calls.

   - Efficient Representation of Lists.

   - System Software and Integrated Programming Environments.

For further information, see:

   Paul Graham, "Anatomy of a Lisp Machine", AI Expert, December 1988.

   Pleszkun and Thazhuthaveetil, "The Architecture of Lisp Machines",
   IEEE Computer, March 1987.

   Ditzel, Schuler and Thomas, "A Lisp Machine Profile: Symbolics 3650",
   AI Expert, January 1987.

   Peter M. Kogge, "The Architecture of Symbolic Computers",
   McGraw-Hill 1991. ISBN 0-07-035596-7.

[Derived from a post by Arthur Pendragon <[e-mail]>.]

----------------------------------------------------------------
Subject: [2-21] How do I tell if a symbol names a function and not a macro?

FBOUNDP tests whether the symbol is globally bound to an operator
(e.g., a function, macro, or special form). SYMBOL-FUNCTION returns
the contents of a symbol's "function slot" if the symbol names a
function. But if the symbol names a macro or special form, it is
completely unspecified what a call to SYMBOL-FUNCTION will return.
Instead, use code like the following to test whether a symbol names a
function:

   (defun fbound-to-function-p (symbol)
     (and (fboundp symbol)
          (not (macro-function symbol))
          (not (special-operator-p symbol))))

----------------------------------------------------------------
;;; *EOF*
Archive-name: lisp-faq/part3
Last-Modified: Tue Nov 15 15:54:47 1994 by Mark Kantrowitz
Version: 1.51
Maintainer: Mark Kantrowitz and Barry Margolin <[e-mail]>
URL: http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/lisp/top.html
Size: 36399 bytes, 797 lines

;;; ****************************************************************
;;; Answers to Frequently Asked Questions about Lisp ***************
;;; ****************************************************************
;;; Written by Mark Kantrowitz and Barry Margolin
;;; lisp_3.faq

This post contains Part 3 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 [e-mail].

This section contains a list of common pitfalls. Pitfalls are aspects
of Common Lisp which are non-obvious to new programmers and often
seasoned programmers as well.

Common Pitfalls (Part 3):

  [3-0]  Why does (READ-FROM-STRING "foobar" :START 3) return FOOBAR
         instead of BAR?
  [3-1]  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?
  [3-2]  Why can't I apply #'AND and #'OR?
  [3-3]  I used a destructive function (e.g. DELETE, SORT), but it
         didn't seem to work.  Why?
  [3-4]  After I NREVERSE a list, it's only one element long.  After I
         SORT a list, it's missing things.  What happened?
  [3-5]  Why does (READ-LINE) return "" immediately instead of waiting
         for me to type a line?
  [3-6]  I typed a form to the read-eval-print loop, but nothing happened. Why?
  [3-7]  DEFMACRO doesn't seem to work.
         When I compile my file, LISP warns me that my macros are undefined
         functions, or complains "Attempt to call <function> which is
         defined as a macro.
  [3-8]  Name conflict errors are driving me crazy! (EXPORT, packages)
  [3-9]  Closures don't seem to work properly when referring to the
         iteration variable in DOLIST, DOTIMES, DO and LOOP.
  [3-10] What is the difference between FUNCALL and APPLY?
  [3-11] Miscellaneous things to consider when debugging code.
  [3-12] When is it right to use EVAL?
  [3-13] Why does my program's behavior change each time I use it?
  [3-14] 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)?
  [3-15] I'm using DO to do some iteration, but it doesn't terminate.
  [3-16] My program works when interpreted but not when compiled!

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

----------------------------------------------------------------
Subject: [3-0] 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:

       READ-FROM-STRING string &OPTIONAL eof-error-p eof-value
                               &KEY :start :end :preserve-whitespace

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.

To get the desired result, you should use
   (READ-FROM-STRING "foobar" t nil :START 3)
If you need to understand and use the optional arguments, please refer
to CLTL2 under READ-FROM-STRING, otherwise, this will behave as
desired for most purposes.

----------------------------------------------------------------
Subject: [3-1] 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.

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

----------------------------------------------------------------
Subject: [3-3] 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. They see the value of the argument, not the argument
itself. 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. Thus
"destructive" just means that the function may munge the list by
modifying the pointers in the cars and cdrs of the list's cons cells.
This can be more efficient, if one doesn't care whether the original
list gets trashed or not.

One thing to be careful about when doing this (storing the result back
into the original location) 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 destructive 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 of the function 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.

----------------------------------------------------------------
Subject: [3-4] 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.

----------------------------------------------------------------
Subject: [3-5] 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.

----------------------------------------------------------------
Subject: [3-6] 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.

----------------------------------------------------------------
Subject: [3-7]  DEFMACRO doesn't seem to work.
                When I compile my file, LISP warns me that my macros
                are undefined functions, or complains
                  "Attempt to call <function> which is defined as a macro."

When you evaluate a DEFMACRO form or proclaim a function INLINE, it
doesn't go back and update code that was compiled under the old
definition. When redefining a macro, be sure to recompile any
functions that use the macro. Also be sure that the macros used in a
file are defined before any forms in the same file that use them.

Certain forms, including LOAD, SET-MACRO-CHARACTER, and
REQUIRE, are not normally evaluated at compile time. Common Lisp
requires that macros defined in a file be used when compiling later
forms in the file. If a Lisp doesn't follow the standard, it may be
necessary to wrap an EVAL-WHEN form around the macro definition.

Most often the "macro was previously called as a function" problem
occurs when files were compiled/loaded in the wrong order. For
example, developers may add the definition to one file, but use it in
a file which is compiled/loaded before the definition. To work around
this problem, one can either fix the modularization of the system, or
manually recompile the files containing the forward references to macros.

Also, if your macro calls functions at macroexpand time, those functions
may need to be in an EVAL-WHEN. For example,

    (defun some-function (x)
      x)

    (defmacro some-macro (y)
      (let ((z (some-function y)))
        `(print ',z)))

If the macros are defined in a file you require, make sure your
require or load statement is in an appropriate EVAL-WHEN. Many people
avoid all this nonsense by making sure to load all their files before
compiling them, or use a system facility (or just a script file) that
loads each file before compiling the next file in the system.

----------------------------------------------------------------
Subject: [3-8]  Name conflict errors are driving me crazy! (EXPORT, packages)

If a package tries to export a symbol that's already defined, it will
report an error. You probably tried to use a function only to discover
that you'd forgotten to load its file. The failed attempt at using the
function caused its symbol to be interned. So now, when you try to
load the file, you get a conflict. Unfortunately, understanding and
correcting the code which caused the export problem doesn't make those
nasty error messages go away. That symbol is still interned where it
shouldn't be. Use unintern to remove the symbol from a package before
reloading the file. Also, when giving arguments to REQUIRE or package
functions, use strings or keywords, not symbols: (find-package "FOO"),
(find-package :foo).

A sometimes useful technique is to rename (or delete) a package
that is "too messed up".  Then you can reload the relevant files
into a "clean" package.

----------------------------------------------------------------
Subject: [3-9]  Closures don't seem to work properly when referring to the
                iteration variable in DOLIST, DOTIMES, DO and LOOP.

DOTIMES, DOLIST, DO and LOOP all use assignment instead of binding to
update the value of the iteration variables. So something like

   (let ((l nil))
     (dotimes (n 10)
       (push #'(lambda () n)
         l)))

will produce 10 closures over the same value of the variable N. To
avoid this problem, you'll need to create a new binding after each
assignment:

   (let ((l nil))
     (dotimes (n 10)
    (let ((n n))
      (push #'(lambda () n)
        l))))

Then each closure will be over a new binding of n.

This is one reason why programmers who use closures prefer MAPC and
MAPCAR to DOLIST.

----------------------------------------------------------------
Subject: [3-10] What is the difference between FUNCALL and APPLY?

FUNCALL is useful when the programmer knows the length of the argument
list, but the function to call is either computed or provided as a
parameter.  For instance, a simple implementation of MEMBER-IF (with
none of the fancy options) could be written as:

(defun member-if (predicate list)
  (do ((tail list (cdr tail)))
      ((null tail))
   (when (funcall predicate (car tail))
     (return-from member-if tail))))

The programmer is invoking a caller-supplied function with a known
argument list.

APPLY is needed when the argument list itself is supplied or computed.
Its last argument must be a list, and the elements of this list become
individual arguments to the function.  This frequently occurs when a
function takes keyword options that will be passed on to some other
function, perhaps with application-specific defaults inserted.  For
instance:

(defun open-for-output (pathname &rest open-options)
  (apply #'open pathname :direction :output open-options))

FUNCALL could actually have been defined using APPLY:

(defun funcall (function &rest arguments)
  (apply function arguments))

----------------------------------------------------------------
Subject: [3-11] Miscellaneous things to consider when debugging code.

This question lists a variety of problems to watch out for when
debugging code. This is sort of a catch-all question for problems too
small to merit a question of their own. See also question [1-3] for
some other common problems.

Functions:

  * (flet ((f ...)) (eq #'f #'f)) can return false.

  * The function LIST-LENGTH is not a faster, list-specific version
    of the sequence function LENGTH.  It is list-specific, but it's
    slower than LENGTH because it can handle circular lists.

  * Don't confuse the use of LISTP and CONSP. CONSP tests for the
    presence of a cons cell, but will return NIL when called on NIL.
    LISTP could be defined as (defun listp (x) (or (null x) (consp x))).

  * Use the right test for equality:
        EQ      tests if the objects are identical -- numbers with the
                same value need not be EQ, nor are two similar lists
                necessarily EQ. Similarly for characters and strings.
                For instance, (let ((x 1)) (eq x x)) is not guaranteed
                to return T.
        EQL     Like EQ, but is also true if the arguments are numbers
                of the same type with the same value or character objects
                representing the same character. (eql -0.0 0.0) is not
                guaranteed to return T.
        EQUAL   Tests if the arguments are structurally isomorphic, using
                EQUAL to compare components that are conses, bit-vectors,
                strings or pathnames, and EQ for all other data objects
                (except for numbers and characters, which are compared
                using EQL). Except for strings and bit-vectors, arrays
                are EQUAL only if they are EQ.
        EQUALP  Like EQUAL, but ignores type differences when comparing
                numbers and case differences when comparing characters.
        =       Compares the values of two numbers even if they are of
                different types.
        CHAR=   Case-sensitive comparison of characters.
        CHAR-EQUAL      Case-insensitive comparison of characters.
        STRING= Compares two strings, checking if they are identical.
                It is case sensitive.
        STRING-EQUAL  Like STRING=, but case-insensitive.

  * Some destructive functions that you think would modify CDRs might
    modify CARs instead.  (E.g., NREVERSE.)

  * READ-FROM-STRING has some optional arguments before the
    keyword parameters.  If you want to supply some keyword
    arguments, you have to give all of the optional ones too.

  * If you use the function READ-FROM-STRING, you should probably bind
    *READ-EVAL* to NIL. Otherwise an unscrupulous user could cause a
    lot of damage by entering
        #.(shell "cd; rm -R *")
    at a prompt.

  * Only functional objects can be funcalled in CLtL2, so a lambda
    expression '(lambda (..) ..) is no longer suitable. Use
    #'(lambda (..) ..) instead. If you must use '(lambda (..) ..),
    coerce it to type FUNCTION first using COERCE.

Methods:

  * PRINT-OBJECT methods can make good code look buggy. If there is a
    problem with the PRINT-OBJECT methods for one of your classes, it
    could make it seem as though there were a problem with the object.
    It can be very annoying to go chasing through your code looking for
    the cause of the wrong value, when the culprit is just a bad
    PRINT-OBJECT method.

Initialization:

  * Don't count on array elements being initialized to NIL, if you don't
    specify an :initial-element argument to MAKE-ARRAY. For example,
         (make-array 10) => #(0 0 0 0 0 0 0 0 0 0)

Iteration vs closures:

  * DO and DO* update the iteration variables by assignment; DOLIST and
    DOTIMES are allowed to use assignment (rather than a new binding).
    (All CLtL1 says of DOLIST and DOTIMES is that the variable "is
    bound" which has been taken as _not_ implying that there will be
    separate bindings for each iteration.)

    Consequently, if you make closures over an iteration variable
    in separate iterations they may nonetheless be closures over
    the same variable and hence will all refer to the same value
    -- whatever value the variable was given last.  For example,
        (let ((fns '()))
          (do ((x '(1 2) (cdr x)))
              ((null x))
            (push #'(lambda () x)
                  fns))
          (mapcar #'funcall (reverse fns)))
    returns (nil nil), not (1 2), not even (2 2). Thus
         (let ((l nil))
           (dolist (a '(1 2 3) l)
             (push #'(lambda () a)
                   l)))
    returns a list of three closures closed over the same bindings, whereas
         (mapcar #'(lambda (a) #'(lambda () a)) '(1 2 3))
    returns a list of closures over distinct bindings.

Defining Variables and Constants:

  * (defvar var init) assigns to the variable only if it does not
    already have a value.  So if you edit a DEFVAR in a file and
    reload the file only to find that the value has not changed,
    this is the reason.  (Use DEFPARAMETER if you want the value
    to change upon reloading.) DEFVAR is used to declare a variable
    that is changed by the program; DEFPARAMETER is used to declare
    a variable that is normally constant, but which can be changed
    to change the functioning of a program.

  * DEFCONSTANT has several potentially unexpected properties:

     - Once a name has been declared constant, it cannot be used a
       the name of a local variable (lexical or special) or function
       parameter.  Really.  See page 87 of CLtL2.

     - A DEFCONSTANT cannot be re-evaluated (eg, by reloading the
       file in which it appears) unless the new value is EQL to the
       old one.  Strictly speaking, even that may not be allowed.
       (DEFCONSTANT is "like DEFPARAMETER" and hence does an
       assignment, which is not allowed if the name has already
       been declared constant by DEFCONSTANT.)

       Note that this makes it difficult to use anything other
       than numbers, symbols, and characters as constants.

     - When compiling (DEFCONSTANT name form) in a file, the form
       may be evaluated at compile-time, load-time, or both.

       (You might think it would be evaluated at compile-time and
       the _value_ used to obtain the object at load-time, but it
       doesn't have to work that way.)

Declarations:

  * You often have to declare the result type to get the most
    efficient arithmetic.  Eg,

       (the fixnum (+ (the fixnum e1) (the fixnum e2)))

     rather than

       (+ (the fixnum e1) (the fixnum e2))

  * Declaring the iteration variable of a DOTIMES to have type FIXNUM
    does not guarantee that fixnum arithmetic will be used.  That is,
    implementations that use fixnum-specific arithmetic in the presence
    of appropriate declaration may not think _this_ declaration is
    sufficient.  It may help to declare that the limit is also a
    fixnum, or you may have to write out the loop as a DO and add
    appropriate declarations for each operation involved.

FORMAT related errors:

  * When printing messages about files, filenames like foo~ (a GNU-Emacs
    backup file) may cause problems with poorly coded FORMAT control
    strings.

  * Beware of using an ordinary string as the format string,
    i.e., (format t string), rather than (format t "~A" string).

  * FORMAT returns NIL, so if you added a format statement at the end
    of a function for debugging purposes, and that function normally
    returns a value to the caller, you may have changed the behavior
    of your program.

Miscellaneous:

  * Be careful of circular lists and shared list structure.

  * Watch out for macro redefinitions.

  * A NOTINLINE may be needed if you want SETF of SYMBOL-FUNCTION to
    affect calls within a file.  (See CLtL2, page 686.)

  * When dividing two numbers, beware of creating a rational number where
    you intended to get an integer or floating point number. Use TRUNCATE
    or ROUND to get an integer and FLOAT to ensure a floating point
    number. This is a major source of errors when porting ZetaLisp or C
    code to Common Lisp.

  * If your code doesn't work because all the symbols are mysteriously
    in the keyword package, one of your comments has a colon (:) in
    it instead of a semicolon (;).

  * If you redefine a function while in the debugger, the redefinition
    may not take effect immediately. This will happen, for example,
    when the execution stack is halted near the invocation of the function.
    The function pointer on the stack will still be pointing to the
    old definition. Go up the stack a few levels before restarting to
    avoid reusing the old definition.

----------------------------------------------------------------
Subject: [3-12] 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)))

The following question (taken from an actual post) is typical of the
kind of question asked by a programmer who is misusing EVAL:

   I would like to be able to quote all the atoms except the first in a
   list of atoms.  The purpose is to allow a function to be read in and
   evaluated as if its arguments had been quoted.

This is the wrong approach to solving the problem. Instead, he should
APPLY the CAR of the form to the CDR of the form. Then quoting the
rest of the form is unnecessary. But one wonders why he's trying to
solve this problem in the first place, since the toplevel REP loop
already involves a call to EVAL. One gets the feeling that if we knew
more about what he's trying to accomplish, we'd be able to point out a
more appropriate solution that uses neither EVAL nor APPLY.

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

----------------------------------------------------------------
Subject: [3-13] 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 or constant folding optimizations).

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

Note that similar issues may also apply to hard-coded strings. If you
want to modify elements of a string, create the string with MAKE-STRING.

----------------------------------------------------------------
Subject: [3-14]  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)))

----------------------------------------------------------------
Subject: [3-15] I'm using DO to do some iteration, but it doesn't terminate.

Your code probably looks something like
   (do ((sublist list (cdr list))
        ..)
       ((endp sublist)
        ..)
     ..)
or maybe
   (do ((index start (+ start 2))
        ..)
       ((= index end)
        ..)
     ..)

The problem is caused by the (cdr list) and the (+ start 2) in the
first line. You're using the original list and start index instead of
the working sublist or index. Change them to (cdr sublist) and
(+ index 2) and your code should start working.

----------------------------------------------------------------
Subject: [3-16] My program works when interpreted but not when compiled!

Look for problems with your macro definitions, such as a macro that is
missing a quote. When compiled, this definition essentially becomes a
constant. But when interpreted, the body of the macro is executed each
time the macro is called.

For example, in Allegro CL the following code will behave differently
when interpreted and compiled:
  (defvar x 10)
  (defmacro foo () (incf x))
  (defun bar () (+ (foo) (foo)))
Putting a quote before the (incf x) in the definition of foo fixes the
problem.

If you use (SETF (SYMBOL-FUNCTION 'foo) ...) to change the definition
of a built-in Lisp function named FOO, be aware that this may not work
correctly (i.e., as desired) in compiled code in all Lisps. In some
Lisps, the compiler treats certain symbols in the LISP package
specially, ignoring the function definition. If you want to redefine a
standard function try proclaiming/declaring it NOTINLINE prior to
compiling any use that should go through the function cell. (Note that
this is not guarranteed to work, since X3J13 has stated that it is not
permitted to redefine any of the standard functions).

----------------------------------------------------------------
;;; *EOF*
Archive-name: lisp-faq/part4
Last-Modified: Fri Mar 10 17:09:24 1995 by Mark Kantrowitz
Version: 1.53
Maintainer: Mark Kantrowitz and Barry Margolin <[e-mail]>
URL: http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/lisp/top.html
Size: 66663 bytes, 1264 lines

;;; ****************************************************************
;;; Answers to Frequently Asked Questions about Lisp ***************
;;; ****************************************************************
;;; lisp_4.faq

This post contains Part 4 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 [e-mail].

Lisp/Scheme Implementations and Mailing Lists (Part 4):

  [4-0]   Free Common Lisp implementations.
  [4-1]   Commercial Common Lisp implementations.
  [4-1a]  Lisp to C translators
  [4-2]   Scheme Implementations
  [4-4]   Free Implementations of Other Lisp Dialects
  [4-5]   Commercial Implementations of Other Lisp Dialects
  [4-6]   What is Dylan?
  [4-7]   What is Pearl Common Lisp?
  [4-9]   What Lisp-related discussion groups and mailing lists exist?
  [4-10]  ANSI Common Lisp -- Where can I get a copy of the draft standard?

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

----------------------------------------------------------------
Subject: [4-0]   Free Common Lisp implementations.

Repositories of Lisp source code are described in the answer to
question [6-1].

Remember, when ftping compressed or compacted files (.Z, .arc, .fit,
etc.) to use binary mode for retrieving the files.

   CLiCC (Common Lisp to C Compiler) generates C-executables from Common
   Lisp application programs. CLiCC is not a Common Lisp system, and
   hence does not include any program development or debugging support.
   CLiCC is intended to be used as an add-on to existing Common Lisp
   systems for generating portable applications. (CLiCC has been tested
   in Allegro CL, Lucid CL, CMU CL, CLISP, and AKCL. It should run in any
   CLtL1 lisp with CLOS.)  CLiCC supports CL_0, a subset of Common Lisp +
   CLOS, which excludes EVAL and related functions. At present CL_0 is
   based on CLtL1, but is headed towards CLtL2 and ANSI-CL. The generated
   C code (ANSI-C or K&R-C compatible) may be compiled using a
   conventional C compiler on the target machine, and must be linked with
   the CLiCC runtime library in order to generate executables. CLiCC has
   a foreign function interface.  CLiCC is available by anonymous ftp from
      ftp.informatik.uni-kiel.de:/pub/kiel/apply/clicc-0.6.4.tar.gz
      [134.245.15.114].
   CLiCC was developed by Wolfgang Goerigk <[e-mail]>,
   Ulrich Hoffman <[e-mail]>, and Heinz Knutzen
   <[e-mail]> of Christian-Albrechts-Universitaet zu
   Kiel, Institut fuer Informatik und Praktische Mathematik,
   Preusserstr.  1-9, D-24105 Kiel, Germany. The authors welcome
   suggestions and improvements and would appreciate receiving email
   even if you just used CLiCC successfully. For more information,
   send mail to [e-mail].

   CLISP is a Common Lisp (CLtL1 + parts of CLtL2) implementation by
   Bruno Haible of Karlsruhe University and Michael Stoll of Munich
   University, both in Germany.  It runs on microcomputers (DOS, OS/2,
   Atari ST, Amiga 500-4000) as well as on Unix workstations (Linux, Sun4,
   Sun386, HP9000/800, SGI, Sun3 and others) and needs only 1.5 MB of RAM.
   It is free software and may be distributed under the terms of GNU GPL.
   German and English versions are available, French coming soon.  CLISP
   includes an interpreter, a compiler, a subset of CLOS (e.g., no MOP)
   and, for some machines, a screen editor. Packages running in CLISP
   include PCL and, on Unix machines, CLX and Garnet.  Available by anonymous
   ftp from
      ma2s2.mathematik.uni-karlsruhe.de:/pub/lisp/clisp/ [129.13.115.2]
   For more information, contact [e-mail].
   There is a mailing list for users of CLISP. It is the proper forum for
   questions about CLISP, installation problems, bug reports, application
   packages etc. For information about the list and how to subscribe,
   send mail to [e-mail], with the two lines
          help
          information clisp-list
   in the message body.
   A Sybase SQL interface interface for CLIPS is available
   by anonymous ftp from wuarchive.wustl.edu:packages/clips2sybase/. For
   more information, write to Sherry Steib <[e-mail]>.

   CMU Common Lisp (CMU CL) is free, and runs on HPs, Sparcs (Mach,
   SunOs, and Solaris), DecStation 3100 (Mach), SGI MIPS (Iris), DEC
   Alpha/OSF1, IBM RT (Mach) and requires 16mb RAM, 25mb disk. It
   includes an incremental compiler, Hemlock emacs-style editor,
   source-code level debugger, code profiler and is mostly X3J13
   compatible, including the new loop macro.  It is available by
   anonymous ftp from
      ftp.cs.cmu.edu:/afs/cs.cmu.edu/project/clisp/release [128.2.206.173]
   Login with username "anonymous" and "userid@host" (your email
   address) as password. Due to security restrictions on anonymous ftps
   (some of the superior directories on the path are protected against
   outside access), it is important to "cd" to the source directory with
   a single command.  Don't forget to put the ftp into binary mode before
   using "get" to obtain the compressed/tarred files. The binary releases
   are contained in files of the form
                <version>-<machine>_<os>.tar.Z
   Other files in this directory of possible interest are
   17f-source.tar.gz, which contains all the ".lisp" source files
   used to build version 17f. A listing of the current contents of the
   release area is in the file FILES. You may also use "dir" or "ls" to
   see what is available. Bug reports should be sent to [e-mail].

   ECoLisp is a Common Lisp implementation which compiles Lisp functions
   into C functions that use the C stack and standard procedure call
   conventions. This lets Lisp and C code be easily mixed. It can be used
   as a C library from any C application.  It is available by anonymous
   ftp from
      ftp.di.unipi.it:/pub/lang/lisp/     [131.114.4.36]
      ftp.icsi.berkeley.edu:/pub/ai/ecl/  [128.32.201.7]
   as the file ecl-??.tar.gz where ?? is the version number. This is an alpha
   release. So far it has been tested on Sun workstations (SunOS 4.x),
   SGI (IRIX 4.x), and IBM PC (DOS/go32). For more information, please contact
   Giuseppe Attardi <[e-mail]> or <[e-mail]>.

   GNU Common Lisp (GCL) is a free implementation of Common Lisp (CLtL1)
   based originally on Austin Kyoto Common Lisp (AKCL). Versions 1.0
   and above of GCL (aka versions 1-625 and above of AKCL) are
   available under the GNU General Public Library License v2.0, and no
   longer require the kcl.tar file to build the system. For
   information on previous versions of AKCL, see the KCL entry. GCL
   generates C code which it compiles with the local optimizing C
   compiler (e.g., GCC).  It is intended to eventually support the
   ANSI standard for Common Lisp. GCL runs on Sparc, IBM RT, RS/6000,
   DecStation 3100, hp300, hp800, Macintosh II (under AUX), mp386,
   IBM PS2, IBM RT_AIX, Silicon Graphics 4d, Sun3, Sun4, Sequent
   Symmetry, IBM 370, NeXT, Vax, and IBM PC 386/486 (linux, bsd).
   GCL version 1.0 and above are available by anonymous ftp from
      ftp.cli.com:/pub/gcl/        [192.31.85.129]
      math.utexas.edu:/pub/gcl/        [128.83.133.215]
   as the file gcl-X.X.tgz (e.g., gcl-1.0.tgz), where X.X should be
   replaced with the version number; you'll generally want the largest
   version number. The bandwidth to math.utexas.edu is higher than cli.
   The file pcl-gcl-1.0.tgz contains a port of PCL (CLOS) to GCL.
   The file xgcl-2.tgz contains an interface to X Windows for GCL,
   including a low-level interface to Xlib, and in addition to being
   available from the above sites, is also available from
      ftp.cs.utexas.edu:/pub/novak/xgcl/
      http://www.cs.utexas.edu/users/novak/
   For more information, write to William Schelter <[e-mail]>
   (or <[e-mail]>, <[e-mail]>). GCL is under
   continuing development, and folks interested in helping should send
   him email. Andy Wang <[e-mail]> has compiled GCL 1.0
   for Linux 1.1.50 (using gcc 2.5.8 and libc 4.5.26) and made the
   resulting binaries available by anonymous ftp from
      sunsite.unc.edu:/pub/Linux/Incoming/gcl-1.0.bin.tgz

   Kyoto Common Lisp (KCL) is free, but requires a license. Conforms to CLtL1.
   KCL was written by T. Yuasa <[e-mail]> and M. Hagiya
   <[e-mail]> at Kyoto University in 1984. Austin
   Kyoto Common Lisp (AKCL) is a collection of ports, bug fixes and
   improvements to KCL by Bill Schelter (<[e-mail]> or
   <[e-mail]>). Since 1994, AKCL versions 1-625 and
   higher are covered by the GNU GPL, so generally one will generally
   not need KCL (see GCL above for details). {A}KCL generates C code
   which it compiles with the local C compiler. Both are available by
   anonymous ftp from
      rascal.ics.utexas.edu:/pub/ [128.83.138.20]
      ftp.cli.com:/pub/ [192.31.85.1]
      utsun.s.u-tokyo.ac.JP:/pub/ [133.11.11.11]
   KCL is in the file kcl.tar, and AKCL is in the file akcl-xxx.tar.Z
   (take the highest value of xxx).  To obtain KCL, one must first sign
   and mail a copy of the license agreement to: Special Interest Group in
   LISP, c/o Taiichi Yuasa, Department of Computer Science, Toyohashi
   University of Technology, Toyohashi 441, JAPAN. Runs on Sparc, IBM RT,
   RS/6000, DecStation 3100, hp300, hp800, Macintosh II (under AUX),
   mp386, IBM PS2, Silicon Graphics 4d, Sun3, Sun4, Sequent Symmetry, IBM
   370, NeXT and Vax. For the beta test version of the DOS port, see
   the files akclexe.zip and go32sexe.zip in
      math.utexas.edu:/pub/msdos/akcl-beta/
   Commercial versions of {A}KCL are available from Austin Code Works,
   11100 Leafwood Lane, Austin, TX 78750-3409, Tel. [phone], Fax
   512-258-1342, E-mail [e-mail], including a CLOS for AKCL.
   See also Ibuki, below.

   PowerLisp is a Common Lisp development environment for the Macintosh.
   It consists of a Common Lisp interpreter, native-code 680x0 compiler,
   680x0 macro assembler, disassembler, incremental linker and
   multi-window text editor. It requires a Macintosh with at least a
   68020 processor (any Mac except a Plus, SE or Classic) and system 7.0
   or later. About 2 megabytes of RAM are required to run it, and to do
   much with it you need more like 5 or 6 megabytes. Like any Common Lisp
   system, the more memory the better.  PowerLisp has the ability to run
   in the background. While executing a Common Lisp program, the user may
   switch to another application as it continues to run. You can also
   edit programs while a Common Lisp program is running. PowerLisp is
   targeted to be compatible with CTLTL2 without CLOS (for now) but some
   Common Lisp functions are not yet implemented. Upcoming versions
   should include the remaining language features. The current released
   version is 1.10. PowerLisp is available from America Online and Genie as a
   shareware program ($50). It is also available from the Lisp
   Repository, as
      ftp.cs.cmu.edu:/user/ai/lang/lisp/impl/powerlsp/v1_10/powerlsp.hqx
   Written by Roger Corman. For more information, send mail to
   [e-mail], [e-mail] or [e-mail] (RogerC34
   on America Online).

   RefLisp is a small Lisp interpreter. Versions exist for MS-DOS and
   UNIX (AIX). The MS-DOS version supports CGA/EGA/VGA graphics and the
   Microsoft Mouse. The interpreter is a shallow-binding (i.e.,
   everything has dynamic scope), reference counting design making it
   suitable for experimenting with real-time and graphic user interface
   programming. Common Lisp compatibility macros are provided, and most
   of the examples in "Lisp" by Winston & Horn have been run on RefLisp.
   RefLisp makes no distinction between symbol-values and
   function-values, so a symbol can be either but not both.  RefLisp
   comes with an ASCII manual and many demonstration programs, including
   an analogue clock which never stops for garbage collection.  It is
   written in ANSI C and is in the public domain. Source and binaries are
   available in the Lisp Utilities repository by anonymous ftp from
      ftp.cs.cmu.edu:/user/ai/lang/lisp/impl/reflisp/
   For further information, send email to the author Bill Birch
   <[e-mail]>.

   WCL is an implementation of Common Lisp for Sparc based workstations.
   It is available free by anonymous ftp from
      cdr.stanford.edu:/pub/wcl/  [36.93.0.31]
   as the files wcl2.2-solaris-src.tar.gz, wcl2.2-solaris-bins.tar.gz,
   wcl2.2-sunos4-src.tar.gz, wcl2.2-sunos4-bins.tar.gz, and
   wgdb4.2-sunos4.tar.gz. It includes a native solaris version (but with
   no dynamic .o loading or wgdb yet...), can use any version of GCC 2.X
   (GCC 2.1 is no longer required), and includes separate binary and
   source distribution so that recompilation is no longer needed to
   install WCL and WGDB. The wcl2.2-*.tar.gz files contain the WCL
   distribution, including CLX and PCL; wgdb4.2-sunos4.tar.gz contains a
   version of the GDB debugger which has been modified to grok WCL's
   Lisp.  WCL provides a large subset of Common Lisp as a Unix shared
   library that can be linked with Lisp and C code to produce efficient
   and small applications. For example, the executable for a Lisp version
   of the canonical ``Hello World!''  program requires only 40k bytes
   under SunOS 4.1 for SPARC. WCL provides CLX R5 as a shared library,
   and comes with PCL and a few other utilities.  For further information
   on WCL, see the paper published in the proceedings of the 1992 Lisp
   and Functional Programming Conference, a copy of which appears in the
   wcl directory as lfp-paper.ps, or look in the documentation directory
   of the WCL distribution. Written by Wade Hennessey
   <[e-mail]>.  Please direct any questions to
   [e-mail]. If you would like to be added to a mailing
   list for information about new releases, send email to
   [e-mail].

   XLISP is free, and runs on the IBM PC (MSDOS), Amiga (AmigaDOS),
   Atari ST (TOS), Apple Macintosh, and Unix. It should run on anything
   with a C compiler.  It was written by David Michael Betz,
   167 Villa Avenue #11, Los Gatos, CA 95032, 408-354-9303 (H),
   408-862-6325 (W), [e-mail]. The reference manual was written by
   Tim Mikkelsen. Version 2.0 is available by anonymous ftp from
      cs.orst.edu:/pub/xlisp/ [128.193.32.1] or
      sumex-aim.stanford.edu:/info-mac/lang/
   Version 2.1g* is the same as XLISP 2.0, but modified by Tom Almy
   <[e-mail]> to bring it closer to Common Lisp, in
   addition to fixing several bugs. The latest version of XLISP can be
   obtained by anonymous ftp from
      ftp.cs.cmu.edu:/user/ai/lang/lisp/impl/xlisp/ [128.2.206.173]
   It may also be available (in possible older versions) from
      ftp.biostr.washington.edu:/pub/xlisp      [128.95.10.115]
      wasp.eng.ufl.edu:/pub                     [128.227.116.1]
   A Macintosh port of version 2.1e (and the C source code to its
   interface) is also available, from Macintosh ftp sites such as
      sumex.stanford.edu:/info-mac/dev/xlisp-21e2.hqx
      mac.archive.umich.edu:/mac/development/languages/xlisp2.1e2.sit.hqx
   The Macintosh version was written by Brian Kendig, <[e-mail]>.
   To obtain a copy through US mail, send email to Tom Almy,
   [e-mail]. A Windows version of the statistical
   version of xlisp is available by anonymous ftp from
      ftp.cica.indiana.edu:/util/wxlslib.zip
   A version of XLISP-PLUS 2.1g that includes an experimental byte code
   compiler is available by anonymous ftp from
      umnstat.stat.umn.edu:/pub/xlispstat/xlisponly/ [128.101.51.1]
   as the file xlisp21gbc.tar.gz. Write to Luke Tierney <[e-mail]>
   for more information.

----------------------------------------------------------------
Subject: [4-1]   Commercial Common Lisp implementations.

Allegro Common Lisp:

   Allegro Common Lisp 4.2 runs on a variety of platforms, including
   Sparcs, RS6000, HP700, Silicon Graphics, DecStation (prices start at
   $4,500) and NeXT ($2,000). It requires 12mb RAM for the 680x0 and 16mb
   for RISC. It includes native CLOS, X-windows support, Unix interface,
   incremental compilation, generational garbage collection, and a
   foreign function interface.  Options include Allegro Composer
   (development environment, including debugger, inspector, object
   browser, time/space code profiler, and a graphical user interface,
   $1,500), Common LISP Interface Manager (CLIM 2.0 is a portable
   high-level user interface management system.  CLIM 2.0 for Allegro
   CL supports both Motif and Openlook, $1,000) and Allegro CLIP
   (a parallel version of Lisp for the Sequent).  Franz also markets
   Allegro CL\PC 2.0 for Windows 3.1 for $995 (discount prices of $449 are
   sometimes advertised in various AI magazines). Allegro CL\PC provides 32-bit
   compilation, complete CLOS, an integrated development environment,
   interface to the Windows API, DLL support, and free runtime delivery.
   Write to: Franz Inc., 1995 University Avenue, Berkeley, CA 94704 or
   call 1-800-333-7260, 510-548-3600, fax [phone], telex 340179
   WUPUBTLXSFO. Bug reports can be mailed to [e-mail].  Questions
   about Franz Inc. products (e.g., current and special pricing) can be
   sent to [e-mail]. To receive Franz Flash, Franz's electronic
   newsletter, send mail to [e-mail]. The Franz Forum bboard is
   accessible by telnet to franzforum.franz.com. Files related to the
   bboard (e.g., patches, Franz's GNU-Emacs/Lisp interface, the Allegro FAQ)
   are available by anonymous ftp from
      ftp.uu.net:/vendor/franz/ [192.48.96.9]

CLOE:

   CLOE (Common Lisp Operating Environment) is a cross-development
   environment for IBM PCs (MSDOS) and Symbolics Genera. It includes
   CLOS, condition error system, generational garbage collection,
   incremental compilation, code time/space profiling, and a stack-frame
   debugger. It costs from $625 to $4000 and requires 4-8mn RAM and a 386
   processor.  Write to: Symbolics, 6 New England Tech Center,
   521 Virginia Road, Concord, MA 01742, call 1-800-394-5522 or
   508-287-1000 or fax [phone].

Golden Common Lisp:

   Golden Common Lisp (GCLisp 4.4) runs on IBM PCs under DOS, Windows,
   OS/2, and Windows NT, costing $2,000 ($250 extra for Gold Hill
   Windows), and includes an incremental compiler, foreign function
   interface, interactive debugger, SQL interface, and emacs-like editor.
   It supports DDE and other Windows stuff, and is CLtL1 compatible.
   Supports PCL/CLOS. It requires 4mb RAM, and 12mb disk. See a review in
   PC-WEEK 4/1/91 comparing GCLisp with an older version of MCL.  Write
   to: Gold Hill Computers, 26 Landsdowne Street, Cambridge, MA 02139,
   call 617-621-3300, or fax [phone].

Harlequin LispWorks:

   LispWorks (R) from Harlequin runs on a variety of Unix platforms,
   including Sun Sparc and clones (SunOS and Solaris), IBM RS/6000 (AIX),
   DEC MIPS (Ultrix), DEC Alpha (OSF/1), HP PA (HP-UX), and SGI (IRIX).
   LispWorks uses menus and graphics to provide convenient, user friendly
   access to its wide array of powerful tools.  A C/C++ interface, an SQL
   interface, and a fully integrated Prolog compiler are a standard part
   of LispWorks.  CLIM 2.0 is also available.

     +  COMMON LISP: CLtL2 compatible, native CLOS/MOP, generational GC,
        C/C++ interface.

     +  ENVIRONMENT: Prolog, Emacs-like editor/listener/shell, defadvice,
        defsystem, cross-referencing, lightweight processes,
        debugger, mail reader, extensible hypertext online doc, LALR
        parser generator.

     +  BROWSERS/GRAPHERS: files, objects, classes, generic functions,
        source code systems, specials, compilation warnings.

     +  GRAPHICS: CLX, CLUE, Toolkit, CAPI, Open Look, Motif,
        interface builder.

     +  INTEGRATED PRODUCTS: CLIM 2.0, KnowledgeWorks (RETE engine).

   For further information, contact by e-mail worldwide:
      [e-mail] (OR @harlequin.co.uk)
   or in the US:
      FAX:   [phone]
      Voice: 800-WORKS-4-YOU (800-967-5749) or 617-374-2400 or 617-252-0052
      Mail:  Harlequin Inc., One Cambridge Center, Cambridge, MA 02142
   or in Europe:
      FAX:   [phone] (OR 44-1223-872-519 from outside UK)
      Voice: 0223-873-800 OR -872-522 (OR 44-1223-873-800 from outside UK)
      Telex: 818440 harlqn g
      Mail:  Harlequin Ltd., Barrington Hall, Barrington, Cambridge, CB2 5RG


Harlequin FreeLisp:

   Harlequin Inc. is shipping FreeLisp (TM), which has been developed
   specifically to meet the Lisp teaching requirements of the academic
   community in terms of both functionality and price.  FreeLisp
   is a reduced implementation of Harlequin's premier Common Lisp
   development environment, LispWorks (R).  FreeLisp runs under on PC's
   under Windows, and has many of the environmental features as
   LispWorks but does not include a compiler. For prices and information
   about FreeLisp, contact by e-mail worldwide
      [e-mail] (OR @harlequin.co.uk)
   or in the US:
      fax:    [phone]
      voice:  800-WORKS-4-YOU (800-967-5749) or 617-374-2400 or 617-252-0052
      mail:   Harlequin Inc., One Cambridge Center, Cambridge, MA 02142
   or in Europe:
      fax:    [phone] (OR 44-1223-872-519 from outside UK)
      voice:  0223-873-800 OR -872-522 (OR 44-1223-873-800 from outside UK)
      Telex:  818440 harlqn g
      mail:   Harlequin Ltd., Barrington Hall, Barrington, Cambridge, CB2 5RG

Ibuki Common Lisp:

   Ibuki Common Lisp (IBCL) v02/01 is a commercialized and improved
   version of Kyoto Common Lisp. It runs on over 30 platforms, including
   Sun3, Sparc, Dec (Ultrix), Apollo, HP 9000, IBM RS/6000, Silicon
   Graphics and IBM PCs (under AIX).  It includes an incremental compiler,
   interpreter, and C/Fortran foreign function interface. It generates C
   code from the Lisp and compiles it using the local C compiler.  Image
   size is about 3mb. Cost is $2800 (workstations), $3500 (servers), $700
   (IBM PCs).  Supports CLOS and CLX ($200 extra).  Source code is
   available at twice the cost. Ibuki now also has a product called CONS
   which compiles Lisp functions into linkable Unix libraries.  Write to:
   Ibuki Inc., PO Box 1627, Los Altos, CA 94022, or call 415-961-4996,
   fax [phone], or send email to Richard Weyhrauch, [e-mail] or
   [e-mail].

LinkLisp:

   LinkLisp is a Lisp implementation for Windows that supports a large
   subset of Common Lisp. It is DLL and VBX callable from C/C++ and
   Visual Basic. It costs $249. For more information, write to Conscious
   Computing, 3100 Connecticut Avenue NW, Suite 202, Washington, DC
   20008, call 202-483-6350, or fax [phone].

Lucid Common Lisp:

   Lucid Common Lisp runs on a variety of platforms, including PCs (AIX),
   Apollo, HP, Sun-3, Sparc, IBM RT, IBM RS/6000, Decstation 3100,
   Silicon Graphics, and Vax. Lucid includes native CLOS, a foreign
   function interface, and generational garbage collection.  CLIM is
   available for Lucid as a separate product. See also the comments in
   question [1-2] on the wizards.doc file that comes with the release.

   [Note: Lucid encountered financial difficulties because of forays
    into C-related products; the Lisp end of the company remained strong.
    Harlequin announced on 23-NOV-94 that they have acquired the
    rights to the Lisp-related technology of Lucid, Inc., that they
    will market and support Lucid Common Lisp alongside their
    LispWorks products, and that they have hired several former Lucid
    employees for this purpose.]

   For further information, contact by e-mail worldwide:
      [e-mail] (OR @harlequin.co.uk)
   or in the US:
      FAX:   [phone]
      Voice: 800-WORKS-4-YOU (800-967-5749) or 617-374-2400 or 617-252-0052
      Mail:  Harlequin Inc., One Cambridge Center, Cambridge, MA 02142
   or in Europe:
      FAX:   [phone] (OR 44-1223-872-519 from outside UK)
      Voice: 0223-873-800 OR -872-522 (OR 44-1223-873-800 from outside UK)
      Telex: 818440 harlqn g
      Mail:  Harlequin Ltd., Barrington Hall, Barrington, Cambridge, CB2 5RG


Macintosh Common Lisp:

   Macintosh Common Lisp (MCL 2.0) runs on the Apple Macintosh (Mac+ or
   higher with 4mb RAM and system software 6.0.4 or later or AUX 3.0) and
   is available from APDA for $495. It includes a native CLOS Macintosh
   Toolbox/interface toolkit, ephemeral garbage collection, incremental
   compiler, window-based debugger, source-code stepper, object
   inspector, emacs-style editor, and a foreign function interface.
   Bug reports should be sent to [e-mail]. With
   MCL version 2.0, Apple has started distributing a CD-ROM which
   contains, among other things, a large collection of Lisp code,
   complete MCL manuals in an online-browser format, the CLIM 1.0 manual
   in TeX and postscript, and copies of Gambit 1.8 Scheme, SIOD 2.8
   Scheme, Pixie Scheme, and a demo version of MacScheme. For more
   information, write to: APDA, Apple Computer Inc., 20525 Mariani
   Avenue, MS 33-G, Cupertino, CA 95014-6299 or call toll free
   1-800-282-2732 (US), 1-800-637-0029 (Canada), 1-716-871-6555. Their
   fax number is 1-716-871-6511 and their telex is 171-576. Email may
   also be sent to [e-mail] or [e-mail].
   CLIM for MCL is available for $495 as a separate product from
   Lucid, Inc., 707 Laurel Street, Menlo Park, CA 94025 U.S.A.,
   415-329-8400, fax: [phone], <[e-mail]>.
   [Note: A November 10, 1994 press release announced that Apple has
    licensed MCL to Digitool, Inc. for the purpose of future
    development of MCL. Digitool will introduce a Power Macintosh
    version next year that generates native PowerPC code. For more
    information write to Digitool, Inc., 675 Massachusetts Avenue,
    Cambridge, MA 02139, call 617-441-5000, fax [phone], or send
    email to <[e-mail]>.]

Medley:

   Medley 2.0 is a Common Lisp development environment that includes a
   native CLOS w/MOP, window toolkit, window-based debugger, incremental
   compiler, structure editor, inspectors, stepper, cross-referencer
   (Masterscope), code analysis tools, and browsers. It is the successor
   to InterLisp-D.  It runs on a variety of platforms, including Suns,
   DecStations, 386/486s, IBM RS/6000, MIPS, HP, DEC Alpha, and Xerox
   1186. The price for Unix machines is $3,195 for the developer version
   and $1,250 for the runtime version.  Medley also runs under DOS 4.0 or
   higher ($795 developer version, $300 runtime version, and $250 student
   version). Instructional licenses are also available at $250/copy for DOS
   (to a max of $1,250) and $1,000/copy for Unix (to a max of $5,000).
   For more information, write to Venue, 1624 Franklin Street, Suite 1212,
   Oakland, CA 94612, call 800-228-5325 or 510-835-8856, fax
   510-835-8251, or send email to [e-mail].

muLISP-90:

   muLISP-90 v7.1 is a small Lisp which runs on IBM PCs (or the HP 95LX
   palmtop), MS-DOS version 2.1 or later. It isn't Common Lisp, although
   there is a Common Lisp compatibility package which augments muLISP-90
   with over 450 Common Lisp special forms, macros, functions and control
   variables. Includes a screen-oriented editor and debugger, a window
   manager, an interpreter and a compiler. Among the example programs is
   DOCTOR, an Eliza-like program. The runtime system allows one to create
   small EXE or COM executables. Uses a compact internal representation
   of code to minimize space requirements and speed up execution. The
   kernel takes up only 50k of space. Costs $150. muLISP-XM is a version
   of muLISP-90 that can take advantage of up to 4 gigabytes of extended
   memory and costs $300.  Write to Soft Warehouse, Inc., 3660 Waialae
   Avenue, Suite 304, Honolulu, HI 96816-3236, call 808-734-5801, or fax
   808-735-1105.

NanoLISP:

   NanoLISP 2.0 is a Lisp interpreter for DOS systems that supports a
   large subset of the Common Lisp (CLtL2) standard, including lexical and
   dynamic scoping, four lambda-list keywords, closures, local functions,
   macros, output formatting, generic sequence functions, transcendental
   functions, 2-d arrays, bit-arrays, sequences, streams, characters
   double-floats, hash-tables and structures. Runs in DOS 2.1 or higher,
   requiring only 384k of RAM. Cost is $100. Write to: Microcomputer Systems
   Consultants, PO Box 6646, Santa Barbara, CA 93160 or call 805-967-2270.

Poplog Common Lisp:

   Poplog Common Lisp is an incremental compiler and X-based development
   environment for Common Lisp. Poplog Common Lisp provides a compact and
   memory-efficient implementation which has recently been upgraded to
   include support for CLtL2, including a native CLOS implementation.

   The Poplog environment also includes efficient incremental compilers
   for Prolog, Standard ML and Pop-11, a language-sensitive editor and
   supports easy dynamic linking to C, Fortran etc. Poplog has over 400
   customers in 36 countries.

   Poplog runs on a variety of platforms including Sun SPARC (SunOS 4.1,
   Solaris 2.x), HP-RISC (HP-UX), Silicon Graphics (IRIX), PC UNIX (SCO,
   Linux), DECstation (Ultrix) and under VMS on both VAX and Alpha.

   For more information, contact:
       Integral Solutions Ltd, 3 Campbell Court,
       Bramley, Basingstoke, Hants. RG26 5EG, UK.
       Call [phone], fax [phone]
       Email [e-mail]

   In North America, contact:
       Computable Functions, Inc., 35 South Orchard Drive,
       Amherst, MA 01002.
       Call 413-253-7637, fax [phone].

Procyon Common Lisp:

   Procyon Common Lisp runs on either the Apple Macintosh or IBM PC (386/486
   or OS/2 native mode), costing 450 pounds sterling ($675) educational,
   1500 pounds ($2250) commercial. It requires 2.5mb RAM on the Macintosh
   and 4mb RAM on PCs (4mb and more than 4mb recommended respectively).  It
   is a full graphical environment, and includes a native CLOS with
   meta-object protocol, incremental compilation, foreign function
   interface, object inspector, text and structure editors, and debugger.
   Write to: Scientia Ltd., St. John's Innovation Centre, Cowley Road,
   Cambridge, CB4 4WS, UK, with phone [phone], fax [phone].
   E-mail: [e-mail].
   [NOTE: The rights to the MS Windows version of Procyon were sold to
    Franz who are marketing and developing it as Allegro CL\PC. See
    Allegro's entry for more information. The MS Windows version of
    Procyon is no longer available from Scientia. Expertelligence no
    longer distributes any version of Procyon.]

Software Engineer:

   Software Engineer 2.1 is a Lisp for Windows that creates small
   stand-alone executables (no royalties or run-time libraries required).
   It is a subset of Common Lisp, but includes CLOS. Supports DDE and
   Windows API calls. It requires 2mb RAM, but can use up to 16mb of
   memory, generating 286/386 specific code. It costs $350.  Write to:
   Raindrop Software, 833 Arapaho Road, Suite 104, Richardson, TX 75081,
   call 214-234-2611, fax [phone], or send email to
   [e-mail].

Star Sapphire Common LISP:

   Star Sapphire Common LISP 3.4 provides a subset of Common Lisp and
   includes an emacs-like editor, compiler, debugger, DOS graphics and
   CLOS. It runs on IBM PCs (MSDOS or Windows), requires 640k RAM, a hard
   disk, and costs $100.  Write to: Sapiens Software Corporation,
   PO Box 3365, Santa Cruz, CA 95063-3365, call 408-458-1990,
   fax [phone].  Copies may also be ordered from the Programmers'
   Shop at 800-421-8006.  Sapiens Software also has a Lisp-to-C
   translator in beta-test.

Top Level Common Lisp:

   Top Level Common Lisp includes futures, a debugger, tracer, stepper,
   foreign function interface and object inspector.  It runs on Unix
   platforms, requiring 8mb RAM, and costs $687.  Write to: Top Level,
   100 University Drive, Amherst, MA 01002, call [phone], or fax
   [phone].

Lisps which run on special-purpose hardware (Lisp Machines) include

   o  Symbolics           1-800-394-5522 (508-287-1000)   fax [phone]
      6 Concord Farms, 555 Virginia Road, Concord, MA 01742.
      In Germany: Symbolics Systemhaus GmbH, Mergenthalerallee 77,
         65760 Eschborn, (49) 6196-47220, fax [phone].
      Symbolics Open Genera runs on DEC 3000 Workstations (models 600
      and 800 APX with the OSF/1 operating system), at a price of $18,500.

   o  TI Explorers
         Texas Instruments Incorporated, Data Systems Group,
         P.O. Box 181153 DSG-230, Austin, Texas 78718

   o  Xerox Interlisp.    See Medley above.

----------------------------------------------------------------
Subject: [4-1a] Lisp to C translators

Lisp-to-C Translator translates Common Lisp into human-readable ANSI
C.  Release 3.2 supports such features as CLOS, the condition system,
Lisp type declaration heeding, and Mac, Windows, and Alpha
compatibility.  (Release 3.0, introduced in 1992, eliminated the old
requirement that the garbage collector had to be called explicitly).
Works with Lucid, Symbolics, Allegro, Harlequin and MCL.  It costs
$11,995.  Write to: Chestnut Software, Inc., 2 Park Plaza, Suite 205,
Boston, MA, 02116, call 617-542-9222, fax [phone], or e-mail Mr.
Kenneth J. Koocher <[e-mail]>.

Some Lisp compilers (AKCL, Ibuki) and Scheme compilers (Bigloo,
Hobbit/SCM, Scheme->C) compile into C.

----------------------------------------------------------------
Subject: [4-2] Scheme Implementations

Scheme implementations are listed in the Scheme FAQ posting,

Free Scheme implementations include PC-Scheme, PCS/Geneva, MIT Scheme (aka
C-Scheme), SCM, Hobbit, Gambit, T, Oaklisp, Elk, Scheme->C, SIOD
(Scheme in One Defun), XScheme, Fools' Lisp, Scheme48, UMB Scheme,
VSCM, Pixie Scheme, HELP (a lazy Scheme), Similix, FDU Scheme,
PseudoScheme, Scheme84 and Scheme88.

Commercial Scheme implementations include Chez Scheme, MacScheme, and EdScheme.

Of the free Scheme implementations, the following are implemented in Lisp:

   Peter Norvig's book "Paradigms of AI Programming" has a chapters about
   Scheme interpreters and compilers, both written in Common Lisp. The
   software from the book is available by anonymous ftp from
   unix.sri.com:/pub/norvig/ and on disk in Macintosh or DOS format from
   the publisher, Morgan Kaufmann.  For more information, contact: Morgan
   Kaufmann, Dept. P1, 2929 Campus Drive, Suite 260, San Mateo CA 94403,
   or call Toll free tel: [phone]; FAX: [phone]

   PseudoScheme is available free by anonymous ftp from
      swiss-ftp.ai.mit.edu:/archive/pseudo/pseudo-2-8.tar.Z [18.43.0.152]
   It is Scheme implemented on top of Common Lisp, and runs in Lucid,
   Symbolics CL, VAX Lisp under VMS, and Explorer CL. It should be easy
   to port to other Lisps. It was written by Jonathan Rees
   ([e-mail], [e-mail]). Send mail to
   [e-mail] to be put on a mailing list for
   announcements. Conforms to R3RS except for lacking a correct
   implementation of call/cc. It works by running the Scheme code through
   a preprocessor, which generates Common Lisp code.

   Scheme84 is in the public domain, and available by mail from Indiana
   University. It runs on the VAX in Franz Lisp under either VMS or BSD Unix.
   To receive a copy, send a tape and return postage to: Scheme84
   Distribution, Nancy Garrett, c/o Dan Friedman, Department of Computer
   Science, Indiana University, Bloomington, Indiana. Call 1-812-335-9770
   or send mail to [e-mail] for more information. It will also
   run in Jeff Dalton's port of Franz Lisp to Net/Free/386BSD on 386-like
   machines.  (See the Lisp FAQ for information on Franz Lisp.)

   Scheme88 is a re-implementation of Scheme84 to run in Common Lisp. It
   available by anonymous ftp from
      rice.edu:/public/scheme88.sh
   and also from the Scheme Repository.

----------------------------------------------------------------
Subject: [4-4]   Free Implementations of Other Lisp Dialects

Franz Lisp:

   [Franz Lisp is a dialect of Lisp that predates Common Lisp. It is
   very similar to MacLisp. It lacks full lexical scoping.]

   The official archive site for Franz List Opus 38.92 and 38.93b (the
   last public domain releases) is
       ftp.cs.cmu.edu:/user/ai/lang/others/franzlsp/
   It includes the official version from the ucbvax ftp site before
   its demise, Barry Schein's port of 38.92, the UC Davis port of 38.92,
   and Jeff Dalton's port of 38.92 (see below). For more information,
   contact [e-mail].

   An implementation of (Berkeley) Franz Lisp Opus 38.92 for 386/486
   machines running NetBSD 0.9 (and possibly also 386BSD and FreeBSD)
   is available by anonymous ftp from
      macbeth.cogsci.ed.ac.uk:/pub/franz-for-NetBSD/
   The implementation generates C code and hence is quite portable. It
   has been tested on 68K Suns, VAX 750s, and ICL Perqs running PNX.
   A reference manual is included in the distribution. For more
   information, write to Jeff Dalton <[e-mail]>, or see the URL
      http://www.aiai.ed.ac.uk/~jeff/franz-for-386.html

   PC LISP is a Lisp interpreter for IBM PCs (MSDOS) available from any
   site that archives the group comp.binaries.ibm.pc, such as
      wuarchive.wustl.edu:/mirrors/msdos/lisp/pclisp30.zip
   PC-LISP is a Franz LISP dialect and is by no means Common LISP
   compatible. It is also available directly from the author by sending
   2 blank UNFORMATTED 360K 48TPI IBM PC diskettes, a mailer and
   postage to: Peter Ashwood-Smith, 8 Du Muguet, Hull, Quebec, CANADA,
   J9A-2L8; phone [phone] (home). Source code is available from the
   author for $15.

EuLisp:

   Feel (Free and Eventually Eulisp) is an initial implementation of the
   EuLisp language. It can be retrieved by anonymous FTP from
      ftp.bath.ac.uk:/pub/eulisp/
   as the file feel-0.75.tar.Z. feel-0.75.sun4.Z is the Sparc executable.
   The EuLisp language definition is in the same directory.  Feel is also
   available from
      ftp.gmd.de:/languages/lisp/eulisp/ [129.26.8.84]
   It includes an integrated object system, a module system, condition
   system, and support for parallelism (threads). EuLisp (European
   Lisp) is sort of like an extended Scheme.  The program is a C-based
   interpreter, and a bytecode interpreter/compiler will be available
   sometime soon.  The distribution includes an interface to the PVM
   library, support for TCP/IP sockets, and libraries for futures, Linda,
   and CSP.  Feel is known to run on Sun3, Sun4, Stardent Titan, Alliant
   Concentrix 2800, Orion clippers, DEC VAX, DECstation 3000, Gould
   UTX/32, and Inmos T800 transputer (using CS-Tools). (All bar the last
   four have a threads mechanism.) It can run in multi-process mode on
   the first three machines, and hopefully any other SysV-like machine
   with shared memory primitives. Porting Feel to new machines is
   reasonably straightforward. It now also runs on MS-DOS machines.
   Written by Pete Broadbery <[e-mail]>.

   Apply/Eu2C is an EuLisp->C compiler available from ISST.  Eu2C runs on
   top of Franz Allegro CL 4.1 and compiles EuLisp-Modules into C source
   code which then must be compiled by an ANSI C-compiler (currently only
   GCC is supported).  The Eu2C implementation provides EuLisp 0.99
   level-0, with the exception of concurrency. Future versions of Eu2C
   will include a C interface and straight module compilation.  The
   development of Apply/Eu2C was supported by the German Federal Ministry
   for Research and Technology (BMFT) within the joint project APPLY. The
   partners of this project are the Christian Albrechts University Kiel,
   the Fraunhofer Institute for Software Engineering and Systems
   Engineering (ISST), the German National Research Center for Computer
   Science(GMD), and VW-Gedas.  The main goal of APPLY project is to
   develop a Lisp system which consistently supports the efficient
   execution of applications and simplifies their integration into
   current software environments.  Towards that end, ISST is
   investigating strategies for the compilation of EuLisp-Modules into
   efficient stand-alone C-Programs. The Eu2C compiler is the first step
   along this path. Eu2C is available by anonymous ftp from
   ftp.isst.fhg.de:/APPLY/Distribution/.  Please send bug reports and
   comments to [e-mail] or [e-mail]. If
   you're using Eu2C, please send them a message with "Apply/Eu2C" in the
   subject line to be added to the mailing list of users.

   More information about EuLisp may be found in
      Lisp and Symbolic Computation 6(1-2), August 1993
   which was devoted to EuLisp.

JLISP:
   jlisp is a lisp interpreter designed to be used as an embedded
   interpreter and is easily interfaced with C/C++.  jlisp is easily
   extended. It is available by anonymous ftp from
      ftp.ee.rochester.edu:/pub/weisberg/jlisp-1.03.tar.gz
   For more information, write to Jeff Weisberg <[e-mail]>

----------------------------------------------------------------
Subject: [4-5]   Commercial Implementations of Other Lisp Dialects

   Franz Lisp 2.0 runs on the Apple Macintosh, requiring 1mb RAM for the
   interpreter ($99) and 2.5mb RAM for the compiler ($199).  Student prices
   are $60 for the interpreter and $110 for the interpreter and compiler.
   Includes editor and language reference manual. Complete sources are
   available for $649. The ALJABR symbolic mathematics system costs $249.
   Write to:  Fort Pond Research, 15 Fort Pond Road, Acton, MA 01720,
   call 1-508-263-9692, or send mail to [e-mail].

   Le-Lisp includes a compiler, color and graphic output, a debugger, a
   pretty printer, performance analysis tools, tracing, and incremental
   execution. Le-Lisp currently runs on Unix, VMS, and Windows 3.1.  Note
   that Le-Lisp is neither Common Lisp nor Scheme.  Le-Lisp was
   originally developed in 1980 at Inria, the French national computer
   science laboratory, by a team led by Jerome Chailloux for work on VLSI
   design. It was based on several earlier Lisps in the MacLisp family,
   but was not directly derived from MacLisp.  Le-Lisp enjoyed a large
   success in the French academic world because it was small, fast, and
   portable, being based on a abstract machine language called LLM3.  In
   1983, for example, Le-Lisp ran on Z-80 machines running CP/M. In 1987,
   Ilog was formed as an offshoot of Inria to commercialize and improve
   Le-Lisp and several products which had been developed with it,
   including a portable graphic interface system and an expert system
   shell.  Since then, Ilog has continued to grow and expand the use of
   Le-Lisp into industrial markets around the world.  Ilog is the largest
   European Lisp vendor, and continues to develop new products and
   markets for Lisp.  In 1992, Ilog released the next major version of
   Le-Lisp, Le-Lisp version 16.  This version modernizes Le-Lisp for use
   in the industrial world, adding lexical closures and
   special-form-based semantics for static analysis, a new object system
   based on the EuLisp object system (TELOS), an enhanced module system
   for application production, a conservative GC for integration with C
   and C++, and compilation to C for portability and efficiency on a wide
   range of processors.  For pricing and other information, write to
   ILOG, 2 Avenue Gallieni, BP 85, 94253 Gentilly Cedex, France, call
   33-1-46-63-66-66, fax [phone], or send email to Jerome
   Chailloux ([e-mail]).

   CLISP v6.89 is a library of functions which extends the C programming
   language to include some of the functionality of Lisp. Requires
   ANSI C. Costs $349 with no run-time fee.
   Write to Drasch Computer Software, 187 Slade Road, Ashford, CT 06278,
   or call or fax [phone].

   Two references in Dr. Dobb's journal on Lisp-style libraries for C
   are: Douglas Chubb, "An Improved Lisp-Style Library for C", Dr. Dobb's
   Jounral #192, September 1992, and Daniel Ozick, "A Lisp-Style Library
   for C", Dr. Dobb's Journal #179:36-48, August 1991. Source is available by
   ftp from various archives, including wuarchive.wustl.edu (MSDOSDDJMAG),
   or ftp.mv.com:/pub/ddj, or the DDJ Forum on Compuserve.

   Lily (LIsp LibrarY) is a C++ class library that lets C++ programmers
   write LISP-style code. Includes some example programs from Winston's
   Lisp book recoded in Lily. Most or all of chapters 17 (Symbolic
   Pattern Matching), 18 (Expert Problem Solving), and 23 (Lisp in Lisp)
   are implemented in the examples. Lily works with GNU G++ (2.4.5) and
   Turbo C++ for Windows. Lily is available by anonymous ftp from
     sunsite.unc.edu:/pub/packages/development/libraries/ [152.2.22.81]
   as lily-0.1.tar.gz. This site is fairly slow; a copy is available from
   the Lisp Utilities collection. For more information, contact
   Roger Sheldon <[e-mail]>.


Other Lisps for PCs include:

   o  UO-LISP from Calcode Systems, e-mail:calcode![e-mail]
      It comes complete with compiler and interpreter, and is optimised for
      large programs.  It is Standard LISP, not Common LISP. They are based
      in Amoroso Place in Venice, CA.

   o  LISP/88 v1.0. Gotten from Norell Data Systems, 3400 Wilshire Blvd,
      Los Angeles, CA 90010, in 1983. They may or may not still exist.

   o  IQLisp. Not a Common Lisp but still very good for PCs - you can
      actually get a lot done in 640K.  The lisp itself runs in less than
      128K and every cons cell takes only 6 bytes.  Unfortunately that
      makes the 640K (maybe a little more, but certainly no more than 1M)
      limit really hard. It has a byte code compiler which costs extra.
      This has support for all sorts of PC specific things.
      It costs $175 w/o compiler, $275 with.
      Write to: Integral Quality, Box 31970, Seattle, WA 98103,
      call Bob Rorschach, [phone] or email [e-mail].

----------------------------------------------------------------
Subject: [4-6] What is Dylan?

Dylan is a new Object-Oriented Dynamic Language (OODL), based on
Scheme, CLOS, and Smalltalk.  The purpose of the language is to retain
the benefits of OODLs and also allow efficient application delivery.
The design stressed keeping Dylan small and consistent, while allowing
a high degree of expressiveness. Dylan is consistently object-oriented;
it is not a procedural language with an object-oriented extension. A
manual/specification for the language is available from Apple Computer.
Send email to [e-mail] or write to
Apple Computer, 1 Main Street, Cambridge, MA 02142.  Include your
complete address and also a phone number (the phone number is
especially important for anyone outside the US). Comments on Dylan can
be sent to the internet mail address [e-mail].

The mailing list [e-mail] is for any and all
discussions of Dylan, including language design issues, implementation
issues, marketing issues, syntax issues, etc. The mailing list
[e-mail] is for major announcements about
Dylan, such as the availability of new implementations, new versions
of the manual, etc.  This mailing list should be *much* lower volume
than info-dylan.  Everything sent to this list is also sent to
info-dylan.  The newsgroup comp.lang.dylan is gatewayed to the
info-dylan mailing list.

Send mail to the -request version of the list to be added to it.
You can also send an email message to [e-mail]
with "subscribe info-dylan" or "unsubscribe info-dylan" in the body,
and likewise for the other lists, mutatis mutandis.

Apple hasn't announced plans to release Dylan as a product.

The directory cambridge.apple.com:pub/dylan contains some documents
pertaining to Dylan, including a FAQ list.

======== THOMAS ========

Thomas is a compiler for a language that is compatible with the
language described in the book "Dylan(TM) an object-oriented dynamic
language" by Apple Computer Eastern Research and Technology, April
1992. Thomas was written at Digital Equipment Corporation's Cambridge
Research Laboratory. Thomas is NOT Dylan(TM) and was built with no
direct input, aid, assistance or discussion with Apple.

Thomas is available to the public by anonymous ftp at
       crl.dec.com:/pub/DEC/Thomas
       gatekeeper.pa.dec.com:/pub/DEC/Thomas
       swiss-ftp.ai.mit.edu:/archive/Thomas

The Thomas system is written in Scheme and runs under MIT's CScheme,
DEC's Scheme->C, and Marc Feeley's Gambit.  It can run on a wide range
of machines including the Macintosh, PC compatibles, Vax, MIPS, Alpha,
and 680x0.  Thomas generates IEEE compatible Scheme code.

A ready-made version of Thomas 1.1 interpreter built upon MacGambit
2.0 as a double-clickable Macintosh application is available by
anonymous ftp from cambridge.apple.com:/pub/dylan/gambit/ as
the file thomas-1.1-interp.hqx.

For discussion of Thomas, send a note to
   [e-mail]
to be added to the mailing list.

DEC CRL's goals in building Thomas were to learn about Dylan by
building an implementation, and to build a system they could use to
write small Dylan programs. As such, Thomas has no optimizations of
any kind and does not perform well.

The original development team consisted of:
          Matt Birkholz ([e-mail])
          Jim Miller ([e-mail])
          Ron Weiss ([e-mail])
In addition, Joel Bartlett ([e-mail]), Marc Feeley
([e-mail]), Guillermo Rozas ([e-mail])
and Ralph Swick ([e-mail]) contributed time and energy to the
initial release.

======== Marlais ========

Marlais is a simple interpreter for a language strongly resembling
Dylan. It is available by anonymous ftp from
   ftp.cis.ufl.edu:/pub/Marlais
   cambridge.apple.com:/pub/dylan/Marlais
   travis.csd.harris.com:/pub/
Currently runs on i386 and i486 (OS/2 or Linux), IBM PC/RT, IBM
RS/6000, HP9000/300, HP9000/700, DECstations (Ultrix), SGI (IRIX),
Sony News, Apple Macintosh (A/UX), Sun3, Sun4, Vax (4.3bsd and
ultrix), m88k (Harris Nighthawk running CX/UX), MIPS M/120, Sequent
Symmetry, Encore Multimax.  Contact Joe Wilson <[e-mail]> or
Brent Benson <[e-mail]> for more information.

================

The Gwydion Project at CMU is developing an innovative new software
development environment based on the Dylan language (and, in the
process, will make available a very high-quality implementation of
Dylan). This project includes many of the same people responsible for
CMU Common Lisp. (In Welsh mythology, Gwydion is the uncle of Dylan
and nephew of Math.) A Mosaic page describing the project goals, how
they fit in with the Dylan language, and copies of the Dylan language
manual and latest approved design notes is available as
   http://legend.gwydion.cs.cmu.edu:8001/gwydion/
For more information, write to [e-mail].

Mindy (Mindy Is Not Dylan Yet) is a Dylan-like language from the
Gwydion Project. Mindy is intended for use as a development tool while
work on the "real" high-performance Dylan implementation progresses.
Mindy is available by anonymouse ftp from legend.gwydion.cs.cmu.edu as
the file /afs/cs.cmu.edu/project/gwydion/release/mindy.tar.gz.
Send bug reports to [e-mail]; support will be minimal.

----------------------------------------------------------------
Subject: [4-7] What is Pearl Common Lisp?

When Apple Computer acquired Coral Software in January 1989, they
re-released Coral's Allegro Common Lisp and its optional modules as
Macintosh Allegro Common Lisp (now just Macintosh Common Lisp).
Coral's other product, Pearl Lisp, was discontinued at that time.
Pearl Lisp provides a subset of the functionality of MACL 1.3 and is
not even fully CLtL1-compatible (e.g., the implementation of defstruct is
different).

Despite rumors to the contrary, Pearl Lisp is not and never was public
domain. Nevertheless, Pearl Lisp and its documentation were placed in
the "Moof:Goodies:Pearl Lisp" folder on the first pressing of "Phil
and Dave's Excellent CD", the precursor to the current Apple
Developer's CD-ROM series.  Apple removed Pearl from later versions of
the developer CD-ROM distribution because of complaints from other
Lisp vendors. If you own a copy of Pearl Lisp or a copy of this
CD-ROM, you can make it runnable under System 7 with some slight
modifications using ResEdit.  To repeat, Pearl Lisp is NOT public
domain, so you must own a copy to use it.

To make it runnable, one needs to use ResEdit to make changes to the
BNDL and FREF resources so that it will connect to its icons properly.
This will make it respond to double-clicks in the normal manner and
make it be properly linked to its files. Detailed instructions for
modifying Pearl Lisp using ResEdit may be obtained from the Lisp
Utilities Repository by anonymous ftp from
   ftp.cs.cmu.edu:/user/ai/lang/lisp/impl/pearl/
as the file pearl.txt.

After you've made the changes, it will run under System 7 on 68000s
and 68030s if you turn off 32-bit addressing. It seems to bomb on a
Quadra.

If you need a more powerful Lisp or one that is compatible with the
standard for Common Lisp, consider purchasing Macintosh Common Lisp.

----------------------------------------------------------------
Subject: [4-9] What Lisp-related discussion groups and mailing lists exist?

Before posting to any discussion group, please read the rest
of this FAQ, to make sure your question isn't already answered.

Scheme-related mailing lists and newsgroups are listed in the Scheme
FAQ, and AI-related mailing lists and newsgroups are listed in the AI FAQ.

First of all, there are several Lisp-related newsgroups:
   comp.lang.lisp          General Lisp-related discussions.
                           See below for archive information.

   comp.lang.clos          Discussion related to CLOS, PCL, and
                           object-oriented programming in Lisp.
                           Gatewayed to [e-mail].
                           (or equivalently, [e-mail])
                           See below for info on the newsgroup's archives.

   comp.org.lisp-users     Discussions related to Association of Lisp Users.
                           Gatewayed to the ALU mailing list. This is an
                           organizational mailing list/newsgroup, not a
                           technical forum.

   comp.std.lisp           For discussion of emerging standards for
                           the Lisp language, including "de facto" standards.
               Moderated by Brad Miller <[e-mail]>.
                           Submissions should be sent to
                             [e-mail]
                           Archived on
                             ftp.cs.rochester.edu:/pub/archives/lisp-standards/
                           Gatewayed to a mailing list (send mail to
                           [e-mail] to join).

   comp.lang.lisp.mcl      Discussions related to Macintosh
                           Common Lisp. This newsgroup is gatewayed
                           to the [e-mail]
                           mailing list and archived on cambridge.apple.com.

   comp.lang.lisp.franz    Discussion of Franz Lisp, a dialect of Lisp.
                           (Note: *not* Franz Inc's Allegro.)

   comp.lang.lisp.x        Discussion of XLISP, a dialect of Lisp, and XScheme.

   comp.sys.xerox          Discussions related to using Medley (name exists
                           for historical reasons, and is likely to change
                           soon). Gatewayed to the info-1100 mailing list.

   comp.sys.ti.explorer       TI Explorers Lisp machines.

   comp.windows.garnet     Garnet, a Lisp-based GUI.

   comp.ai and subgroups   General AI-related dicusssion.


The newsgroup comp.lang.lisp is archived on
   ftp.gmd.de:/usenet/comp.lang.lisp/ [129.26.8.84]
by month, from 1989 onward. Individual files are in rnews
format. (They contain articles prefixed by a header line "#! rnews
<nchars> archive" where <nchars> is the number of characters in the
article following the header. That format is convenient for various
news processing programs (e.g.  relaynews) and is rather easy to
process from a lisp program too.)  A copy of the GMD archives for
comp.lang.lisp is available on cambridge.apple.com:/pub/comp.lang.lisp/.


We list several mailing lists below. In general, to be added to
a mailing list, send mail to the "-request" version of the address.
This avoids flooding the mailing list with annoying and trivial
administrative requests. [To subscribe to info-mcl, info-dylan, or
other mailing lists based at cambridge.apple.com, send a message to
[e-mail] with "subscribe <list_name>" in the
message body. Likewise use "unsubscribe <list_name>" to cancel your
subscription and "help" to get help.]

General Lisp Mailing Lists:

   [e-mail]          Technical discussion of Common Lisp.
   [e-mail]       Low volume moderated mailing list
                   associated with the Lisp Utilities
                   Repository at CMU. (Also known as
                                   [e-mail])
   [e-mail]              A mailing list concerning the contents
                                   of this FAQ posting only.

   [e-mail]       Forum for use by members (current
                                   and prospective) of the Association
                                   of Lisp Users. It is bidirectionally
                                   gatewayed into the newsgroup
                                   comp.org.lisp-users. This is an
                                   organizational mailing list,
                                   not a technical forum.

Particular Flavors of Lisp:

   [e-mail]    Macintosh Common Lisp. Gatewayed
                                   to the comp.lang.lisp.mcl newsgroup.
   [e-mail]  Automatically generated digest format
                       version of the info-mcl mailing list.

   [e-mail]           CMU Common Lisp bug reports

   [e-mail]                 Symbolics Lisp Users Group
                   Archived on warbucks.ai.sri.com and
                                   ftp.ai.sri.com:/pub/slug.

   [e-mail]      Franz Allegro Common Lisp

   [e-mail]   Lisp on the Amiga

   [e-mail]                     Kyoto Common Lisp
                                   Archived in ftp.cli.com:/pub/kcl/kcl-mail-archive
   [e-mail]       Forwards to [e-mail].

   [e-mail]          LispWorks

   [e-mail]   CLISP
    To subscribe, send mail to [e-mail]
    with "subscribe clisp-list <your full name>" in the message body.
        Use "help" to get a help message back and "unsubscribe clisp-list"
        to remove yourself from the list.

   [e-mail]  TI Explorer Lisp Machine
   [e-mail]  TI Explorer Lisp Machine

   [e-mail]    Xerox/Envos Lisp machine environment,
                                   InterLisp-D, and Medley. Gatewayed to
                                   the newsgroup comp.sys.xerox. Will be
                                   moving to [e-mail].

   [e-mail]   The Franz Lisp Language.
   [e-mail] Maintainers of Franz Lisp.

Lisp Windowing Systems:

   [e-mail]           Common Lisp Window System Discussions.
   [e-mail]        CLX (Common Lisp X Windows)
   [e-mail]                    Common Lisp Interface Manager
   [e-mail]      Common Lisp User-Interface Environment
   [e-mail]      Express Windows
   [e-mail]         Garnet (send mail to [e-mail]
                                   or [e-mail] to be added)
   [e-mail]               GINA and CLM
   [e-mail]       LispWorks
   [e-mail]           WINTERP (OSF/Motif Widget INTERPreter)
   [e-mail]         YYonX

Lisp Object-Oriented Programming:

   [e-mail]  (same as [e-mail])
      Discussion related to CLOS, PCL, and object-oriented programming
      in Lisp.  The name is in honor of the first freely-available
      implementation of CLOS, Xerox PARC's Portable Common Loops, and
      was originally the mailing list for discussing that
      implementation.  Now gatewayed to the comp.lang.clos newsgroup.
      The mailing list is archived on nervous.cis.ohio-state.edu in
      the directory pub/lispusers/commonloops.
      The CLOS code repository is in pub/lispusers/clos.

Miscellaneous:

   [e-mail]
           Use of Lisp and Lisp-based systems in statistics.
   [e-mail]
    Job offers requiring a knowledge of Lisp. See [1-7].

Electronic Journals:

  Electronic Journal of Functional and Logic Programming (EJFLP)

     EJFLP is a refereed journal that will be distributed for free via e-mail.
     The aim of EJFLP is to create a new medium for research investigating the
     integration of the functional, logic and constraint programming paradigms.

     For instructions on submitting a paper, send an empty mail message with
    Subject: Help
     to
        [e-mail].
     You will receive an acknowledgment of your submission within a few hours.

     To subscribe to the journal, send an empty mail message to
         [e-mail]
     You will receive an acknowledgment of your subscription within
     a few days.

     If there are any problems with the mail-server, send mail to
     [e-mail].

     The editorial board is: Rita Loogen (RWTH Aachen), Herbert Kuchen (RWTH
     Aachen), Michael Hanus (MPI-Saarbruecken), Manuel MT Chakravarty (TU
     Berlin), Martin Koehler (Imperial College London), Yike Guo (Imperial
     College London), Mario Rodriguez-Artalejo (Univ. Madrid), Andy Krall
     (TU Wien), Andy Mueck (LMU Muenchen), Tetsuo Ida (Univ. Tsukuba,
     Japan), Hendrik C.R. Lock (IBM Heidelberg), Andreas Hallmann (Univ.
     Dortmund), Peter Padawitz (Univ. Dortmund), Christoph Brzoska (Univ.
     Karlsruhe).


----------------------------------------------------------------
Subject: [4-10] Where can I get a copy of the ANSI Common Lisp standard?
                What is ISO Lisp?

As of December 8, 1994, Common Lisp is now an official ANSI Standard:
ANSI X3.226:1994 American National Standard for Programming Language
Common LISP (X3J13).

The standard will be available from ANSI sometime after June 1995.
Until then, hard copies of the draft standard may be purchased from
Global Engineering Documents, Inc., 2805 McGaw Avenue, Irvine, CA
92714, 1-800-854-7179, 714-261-1455 for a single copy price of $80
($104 international).

Copies of the TeX sources and Unix-compressed DVI files for the draft
standard may be obtained by anonymous FTP from
   parcftp.xerox.com:/pub/cl/ [13.1.64.94]
The files corresponding to the second Public Review of Common Lisp are
in the directory /pub/cl/dpANS2/*. These files correspond to draft
14.10, also known as document X3J13/93-102, which was forwarded by
X3J13 to X3 in October, 1993. (The files from the first draft are in
the directory /pub/cl/document/*.) The draft is about 1500 pages long.
The file Reviewer-Notes.text should be read before ftping the other files.

For more information, write to X3 Secretariat, Attn: Lynn Barra, 1250
Eye Street NW, Suite 200, Washington, DC 20005-3922, call
202-626-5738, fax [phone], or send email to [e-mail].


The international working group on Lisp is ISO/IEC JTC1/SC22/WG16.
Christian Queinnec ([e-mail]) is the WG16 Convenor.
Kent Pitman ([e-mail]) is the International Representative of
X3J13 to WG16 and is also Project Editor for WG16. WG16 is working on
the design of a dialect of Lisp called ISLISP (which is neither a
subset nor a superset of Common Lisp).  A Committee Draft (CD) of
the ISLISP specification has been registered by WG16 as ``CD13816:
Information Technology - Programming languages, their environments and
system software interfaces - Programming language ISLISP.''  The CD,
which WG16 internally refers to as version 11.4, is available by
anonymous FTP from
   ma2s2.mathematik.uni-karlsruhe.de:/pub/lisp/islisp/  [129.13.115.2]
as the file islisp-114.ps or islisp-114.ps.Z.
A WG16 letter ballot is presently in progress to determine whether this
Committee Draft will become a Draft International Standard (DIS); the
ballot closes 30-Nov-94.

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

;;; *EOF*


Archive-name: lisp-faq/part5
Last-Modified: Wed Mar  8 16:59:51 1995 by Mark Kantrowitz
Version: 1.52
Maintainer: Mark Kantrowitz and Barry Margolin <[e-mail]>
URL: http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/lisp/top.html
Size: 28360 bytes, 593 lines

;;; ****************************************************************
;;; Answers to Frequently Asked Questions about Lisp ***************
;;; ****************************************************************
;;; Written by Mark Kantrowitz and Barry Margolin
;;; lisp_5.faq

This post contains Part 5 of the Lisp FAQ. It is cross-posted to the
newsgroup comp.lang.clos because it contains material of interest to
people concerned with CLOS, PCL and object-oriented programming in
Lisp. The other parts of the Lisp FAQ are posted only to the
newsgroups comp.lang.lisp and news.answers.

If you think of questions that are appropriate for this FAQ, or would
like to improve an answer, please send email to us at [e-mail].

CLOS/PCL Questions (Part 5):

  [5-0]   What is CLOS (PCL) and where can I get it?
          How do you pronounce CLOS? What is the Meta-Object Protocol (MOP)?
  [5-1]   What documentation is available about object-oriented
          programming in Lisp?
  [5-2]   How do I write a function that can access defstruct slots by
          name?  I would like to write something like
          (STRUCTURE-SLOT <object> '<slot-name>).
  [5-3]   How can I list all the CLOS instances in a class?
  [5-4]   How can I store data and CLOS instances (with possibly circular
          references) on disk so that they may be retrieved at some later
          time? (Persistent Object Storage)
  [5-5]   Given the name of a class, how can I get the names of its slots?
  [5-6]   Free CLOS software.
  [5-7]   Common CLOS Blunders

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

In general, questions about object oriented programming in Lisp,
especially questions about using CLOS or compiling PCL, should be
directed to the newsgroup comp.lang.clos.

----------------------------------------------------------------
Subject: [5-0]  What is CLOS (PCL) and where can I get it?
                How do you pronounce CLOS?

CLOS (Common Lisp Object System) is the object-oriented programming
standard for Common Lisp. It is the successor to Symbolics FLAVORS and
Xerox LOOPS (Lisp Object Oriented Programming System). The acronym
CLOS is pronouned either as "See-Loss" or "Closs", depending on taste.
PCL (Portable Common Loops) is a portable CLOS implementation, and is
available by anonymous ftp from
   parcftp.xerox.com:/pub/pcl/ [13.1.64.94]
Also in the same directory are sources for CLX R5 and an inspecter.

Most Common Lisp implementations now include their own CLOS
implementations. Common Lisp implementations with native CLOS include:
MCL, {A}KCL, Allegro CL (including Allegro CL\PC), Ibuki, Lucid,
Medley, Symbolics Genera, CLOE, and Harlequin LispWorks. CMU CL uses a
customized version of PCL as their CLOS. However, not all native CLOS
implementations have as detailed a meta-object protocol as PCL. For
example, MCL 2.0 users sometimes use the july-1d version of PCL
instead of the native CLOS for precisely this reason.

The book ``The Art of the Metaobject Protocol'' (see below) includes
the CLOS Metaobject Protocol specification as chapters 5 and 6.  The
sources for the MOP spec itself are available from
   parcftp.xerox.com:/pub/pcl/mop/ [13.1.64.94]
as the file spec.tar.Z, but this is no substitute for buying the
book, since the book contains a lot of useful explanatory material
beyond the spec. The Closette files related to the book are also
available from parcftp as the file closette.lisp.

The CLOS code repository is available by anonymous ftp to
   nervous.cis.ohio-state.edu:/pub/lispusers/clos/ [128.146.61.200]
If you've got code you'd like to add to the repository, send mail to
Arun Welch, [e-mail].

----------------------------------------------------------------
Subject: [5-1] What documentation is available about object-oriented
               programming in Lisp?

Books about object-oriented programming in Lisp include:

   1. dpANS CL describes the entire Common Lisp language, which includes the
      CLOS standard.  Informally, CLtL2 can also be used to learn about CLOS,
      but please remember that CLtL2 is not an official X3J13 committee
      document. (The presentation of CLtL2 differs from that of the draft
      proposed standard, and some matters of fact have changed in the proposed
      standard since the publication of CLtL2.)

   2. Sonya E. Keene
      "Object-Oriented Programming in Common Lisp:
       A Programmer's Guide to CLOS"
      Addison-Wesley (Reading, MA), 1989. 266 pages. ISBN 0-201-17589-4.
           Tutorial introduction to CLOS with many examples and
           a lot of good advice for designing large programs using CLOS.

   3. Jo A. Lawless and Molly M. Miller.
      "Understanding CLOS: the Common Lisp Object System"
      Digital Press, 1991. 192 pages.

   4. Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow.
      "The Art of the Metaobject Protocol"
      MIT Press, 1991. 335 pages. ISBN 0-262-61074-4, $34.95.
           The first part of the book presents a model CLOS implementation,
           introduces the basic principles of metaobject protocols, and
           works through the key elements of the CLOS Metaobject Protocol.
           The second half is the detailed specification of the CLOS
           Metaobject Protocol. A simple working interpreter suitable
           for experimentation is contained in an appendix.

   5. Robert R. Kessler and Amy R. Petajan.
      "LISP, Objects, and Symbolic Programming"
      Scott, Foresman and Company (Glenview, IL), 1988. 644 pages.
           Includes a small Lisp compiler.

   6. A short introduction to CLOS written by Jeff Dalton of the
      University of Edinburgh <[e-mail]> is available by
      anonymous ftp from
         aiai.ed.ac.uk:/lisp/random [192.41.104.6]
      as the file clos-guide.

   7. Andreas Paepcke, editor.
      "Object-Oriented Programming: The CLOS Perspective"
      MIT Press, 1993. 400 pages, ISBN 0-262-16136-2 ($40).
         This book is a collection of essays on the following topics:
           -  Description of CLOS and its design philosophy.
           -  The Metaobject Protocol and its use.
           -  Comparison of CLOS with Smalltalk, Eiffel, Sather, and C++.
           -  CLOS Uses and Methodology. Descriptions of two large CLOS
              applications (Sun's LispView and a hybrid knowledge
              representation tool) and an approach to documenting
              object-oriented protocols (similar to that of AMOP).
           -  Implementation details. Descriptions of TI CLOS for the
              Explorer and PCL's method dispatch mechanism.

----------------------------------------------------------------
Subject: [5-2] 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 probably will
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))))

or using CLOS (generic functions):

(defgeneric spaceship-slot (spaceship slot-name)
  (:method ((x spaceship) (slot (eql :name)))
    (spaceship-name x))
  (:method ((x spaceship) (slot (eql :captain)))
    (spaceship-captain x))
  (:method ((x spaceship) (slot (eql :position)))
    (spaceship-position x))
  (:method ((x spaceship) (slot (eql :velocity)))
    (spaceship-velocity x)))

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 SYSTEM:STRUCTURE-REF
in Lucid (LCL:STRUCTURE-REF in earlier versions of Lucid) and
EXCL:STRUCTURE-REF in Allegro.
----------------------------------------------------------------
Subject: [5-3] 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 be 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 descendant classes to define the slot at the
level of the class hierarchy that is appropriate. You could also try
defining the classes that need instance-recording as instances of a
metaclass that holds the instance registry on the class object. The
recording behavior could then be built-in to an after method on
initialize-instance for the root class of the metaclass, or even
allocate-instance. To allow for garbage collection of old instances,
you will also need to define a generic function to remove the recorded
instances from the list of instances.
----------------------------------------------------------------
Subject: [5-4]  How can I store data and CLOS instances (with possibly
                circular references) on disk so that they may be
                retrieved at some later time? (Persistent Object Storage)

There are two approaches to CLOS object persistence. The first uses
regular CLOS facilities in concert with a standard file system. The
second uses a more sophisticated storage facility, such as a database.
The first solution provides just the persistence, and usually cannot
retrieve only some of the objects from disc. The second goes beyond this
by providing some or all of the facilities typically associated with
databases: transaction management, concurrency control, queries,
selective object materialization, etc. Below, the two solutions are
addressed in turn.

There are two main techniques for the file system solution. The first
involves using #. to compile the data into a file.  The second
produces an ASCII representation which, when evaluated, will reproduce
an equivalent set of data.

If the data you wish to save is stored in the variable *hash-table*,
create a file containing just the lines
        (in-package "YOUR-PACKAGE")
        (setq *hash-table* '#.*hash-table*)
and compile it. The #. macro performs read-time evaluation of the
expression following the dot, and so this compiles the data into the
file. You may then load the file to restore the data. However, the
resulting binary file is not portable between Lisp implementations,
and sometimes not even for the same Lisp on different platforms. Also,
some Lisps will treat the data as constant, and place it on pages in
memory that are marked read-only (after it is loaded). If one tries to
later modify the data, these Lisps will signal an error. Lucid CL only
puts such constants in a read-only area when they appear inside
functions, so this should be safe. Allegro CL doesn't seem to complain
about modification if the data is a cons. DEC's VAXLisp, however, has
problems with #. circular structures in .fas files. MCL seems to work
well with using #. to save data (and even functions) to a file.

The other technique is to produce an ASCII representation of the Lisp
objects which may then be saved to a file. To reproduce the data, one
can load (or compile and load) the file. This technique is portable
between different Lisps and platforms. Unfortunately, the resulting
data is not necessarily EQ to the original. Kerry Koitzsch's
save-object.lisp package is included in the Lisp Utilities Repository,
   ftp.cs.cmu.edu:/user/ai/lang/lisp/code/ext/save_obj/
The Lisp Utilities Repository is described in detail in the answer to
question [6-1].

See also the discussion of MAKE-LOAD-FORM and MAKE-LOAD-FORM-SAVING-SLOTS
in CLtL2.

Here are some solutions to object persistence that use databases instead
of file systems.

Free Persistent Object Storage systems include:

   WOOD (William's Object Oriented Database) is a simple persistent
   object store for MCL 2.0, written by Bill St. Clair
   <[e-mail]>.  Its goal is to provide a way to
   save/restore Lisp objects to/from disk.  It is available by anonymous
   ftp from the MCL repository on cambridge.apple.com:/pub/MCL2/CONTRIB/.
   Send bug reports to [e-mail]. To be added to the
   mailing list, send mail to [e-mail].

   PCLOS is a persistent object store for CLOS that was implemented using
   CLOS's metaobject protocol. It allowed multiple different storage
   facilities to be used. The benefit of this approach is it lets you use
   different storage facilities depending on your needs, ranging from a
   full-blown database with concurrency control and recovery to a very
   fast store that trades speed for functionality. For example, an
   in-memory store that saves its state to disk periodically can be much
   faster than traditional databases, but risks loss of data due to
   crashes. Unfortunately, PCLOS was built on a very old version of CLOS,
   so it is unusable in its current form, and there are no plans to
   update it. The introductory MOP chapter in the book "Object-Oriented
   Programming: The CLOS Perspective" (see [5-1] above) explains how to
   do the rewrite in principle and shows how the CLOS MOP was used for
   object persistence in PCLOS. See also
      1. Andreas Paepcke, "PCLOS: A Flexible Implementation of CLOS
         Persistence", in Proceedings of ECOOP-88, S. Gjessing and K.
         Nygaard, editors, Lecture Notes in Computer Science, Springer
         Verlag, pages 374-389, 1988.  [Explains the PCLOS architecture.]
      2. Andreas Paepcke, "PCLOS: A Critical Review", in OOPSLA-89, 1989.
         [Uses PCLOS as a roadmap through the issues of object persistence.]
      3. Andreas Paepcke, "PCLOS Reference Manual", Hewlett-Packard
         Laboratories, December, 1991.
   For more information about PCLOS, write to Andreas Paepcke
   <[e-mail]>.

   GBB (see [6-3]) is a blackboard architecture with persistence of a
   sort. Every object in GBB is held in RAM, and there are dump and
   restore functions. It handles distributed object delivery and
   function-call triggering of receiving processes.

Commercial Persistent Object Storage systems include:

   AllegroStore is a high-performance object-oriented database management
   system from Franz. It offers Allegro CL users persistent object
   storage with very fast retrieval and update of object data.  It
   provides query processing and transaction-based operation. Built on a
   multi-client, multi-server architecture, it permits concurrent access
   over a network to objects by multiple independent processes.  It uses
   the ObjectStore ODBMS from Object Design Inc, and thus has both Lisp
   and C interfaces and is also very fast.  The CLOS interface is based
   on MOP, with dynamic class/schema modification and redefinition.
   AllegroStore can handle large-scale applications with minimal impact
   on performance. It uses page-faulting and page-locking mechanisms
   instead of object locking, providing high throughput and low overhead
   for concurrent access by multiple users.  Standard database features
   include deadlock detection, referential integrity, and inverse
   functions.  Exception handling is integrated into the Lisp condition
   system. AllegroStore runs on Sparc, SGI, HP, RS/6000, and
   MS-Windows/NT systems.  For more information, send email to
   [e-mail], write to Franz Inc., 1995 University Avenue, Berkeley,
   CA 94704, call 1-800-333-7260, 510-548-3600, fax [phone], or
   telex 340179 WUPUBTLXSFO.

   ITASCA ODBMS V2.2 is a distributed active object database management
   system. ITASCA allows clients to transparently access data that is
   distributed among multiple servers.  ITASCA supports full dynamic
   schema modification that can be performed during any phase of the
   software lifecycle.  Applications written in dissimilar and
   incompatible languages, such as C/C++ and CLOS, can share objects through
   ITASCA. ITASCA stores methods inside the database, promoting
   reusability and maintainability.  ITASCA is based on work at MCC's
   Object-Oriented and Distributed Systems Lab on the ORION system. For
   more information, write to Itasca Systems, Inc., 7850 Metro Parkway,
   Minneapolis, MN 55425, [e-mail], 612-851-3155, fax [phone].
   [Clint Hyde has written a MOP CLOS interface to Itasca, which has some
   features not present in their interface. For a free copy of his source
   code, send him mail to [e-mail].]

   LispWorks (from Harlequin), in addition to providing a traditional
   SQL-based interface to relational databases, also provides a CLOS/SQL
   interface, which is an object-oriented access layer that enables SQL
   data to be manipulated as objects within Lisp, even though those objects
   are not manifest in the database.  This can be especially useful when
   importing data from and exporting data to a database provided by another
   (usually non-Lisp-based) application that already uses a relational
   database to achieve data persistence.

   Statice is a commercial product from Symbolics, that provides a
   powerful persistent ODBMS. It runs on Symbolics Lisp Machines.

----------------------------------------------------------------
Subject: [5-5] Given the name of a class, how can I get the names
               of its slots?

(defun class-slot-names (class-name)
  "Given a CLASS-NAME, returns a list of the slots in the class."
  (mapcar #'clos:slot-definition-name
          (clos:class-slots (find-class class-name))))

(defmethod class-slot-names ((instance standard-object))
  "Given an INSTANCE, returns a list of the slots in the instance's class."
  (mapcar #'clos:slot-definition-name
          (clos:class-slots (class-of instance))))

You can use CLASS-DIRECT-SLOTS instead of CLASS-SLOTS if you don't
want inherited slots. Note that these functions are from the
meta-object protocol specified in the original X3J13 draft spec
(document X3J13/88-003), and may not be supported by all Lisps.

----------------------------------------------------------------
Subject: [5-6] Free CLOS software.

Software Repositories:

   The CLOS code repository is available by anonymous ftp to
   nervous.cis.ohio-state.edu:/pub/lispusers/clos/ [128.146.61.200]
   If you've got code you'd like to add to the repository, send
   mail to Arun Welch, [e-mail].
   The CLOS code repository includes dag.lisp.Z and 3DGeometry.lisp.

----------------------------------------------------------------
Subject: [5-7] Common CLOS Blunders

This question is based on a document written by Marty Hall
<[e-mail]>. The full text of Marty's
"Introduction to CLOS" handout is available by anonymous ftp from
   ftp.cs.cmu.edu:/user/ai/lang/lisp/doc/intro/closintr.tgz

This question lists a variety of common errors that occur when writing
CLOS code. It is extremely useful to glance through this list when
debugging CLOS code.

[A] Omitting a set of parentheses around the arglist in DEFMETHOD.

    For example, writing
       (defmethod Area (Sq Square) ...)
    instead of
       (defmethod Area ((Sq Square)) ...)

    Lisp will accept the former, and think that you have two
    unspecialized arguments instead of one argument specialized as a
    Square.

[B] Missing parentheses around the slot definition list in DEFCLASS.

    For example, writing
       (defclass Rectangle (Polygon)
     (Width ...)
     (Height ...))
    instead of
       (defclass Rectangle (Polygon)
     ((Width ...)
      (Height ...)))

    Lisp will not accept the former, but the error message doesn't
    always clearly identify the problem.

[C] Forgetting to include an empty slot definition list if you don't
    define local slots in DEFCLASS.

    For example, writing
       (defclass Square (Rectangle))
    instead of
       (defclass Square (Rectangle) ())
    Lisp will not accept the former.

[D] Referring to the class name instead of the instance variable in
    DEFMETHOD.

    For example, writing
       (defmethod Area ((Sq Square))
     (* (Width Square) (Width Square)))
    instead of
       (defmethod Area ((Sq Square))
     (* (Width Sq) (Width Sq)))

    Lisp may give you a warning about an unknown free variable, but
    probably won't even do that if you type the defmethod directly into
    the Lisp Listener (Lucid doesn't). So you might not encounter a
    problem until run-time.

[E] Forgetting that accessors are functions and thus could conflict
    with built-in function names.

    For example, writing
       (defclass Graphical-Object ()
     ((Position :accessor Position)))
    will signal an error, since you cannot redefine the built-in
    POSITION function.

[F] Putting the new value last instead of first in the definition of a
    SETF method.

    For example, writing
       (defmethod (setf Area) ((Sq Square) (New-Area number))
     (setf (Width Sq) (sqrt New-Area)))
    instead of
       (defmethod (setf Area) ((New-Area number) (Sq Square))
     (setf (Width Sq) (sqrt New-Area)))

   Lisp will accept the former, causing users to be later puzzled as
   to why (setf (Area Square-1) 10) doesn't work.

[G] Putting the new value last instead of first in a call to a :writer
    method.

    For example, given
       (defclass Circle ()
     ((Radius :reader Radius :writer Set-Radius :initform 5)))
       (setq Circle-1 (make-instance 'Circle))
    and writing
       (Set-Radius Circle-1 10)
    instead of
       (Set-Radius 10 Circle-1)

[H] Confusion about documentation strings in DEFMETHOD.

    People often write code like
       (defmethod Area ((Rect Rectangle))
     "WIDTH times HEIGHT of the rectangle"
     (* (Width Rect) (Height Rect)))
    without clearly thinking about what this might mean.  Some people
    think it will make a documentation string on the generic function that
    can be retrieved by calling (DOCUMENTATION 'Area 'function) or the
    equivalent emacs keystrokes. Others vaguely expect it to make a doc
    string on each separate method, and that the call to DOCUMENTATION
    will somehow be able to automagically figure out which method it
    applies to.

    In fact, Lisp won't complain about this code, with the result that the
    documentation is added to the method *object*, which beginners
    probably know nothing about.

    Use the :documentation entry in defgeneric to add a documentation
    string to the generic function.

[I] Invalid :initargs are accepted by MAKE-INSTANCE.

    Many Lisp implementations will accept unknown keyword initargs without
    complaint, even at the highest safety settings.

    So the following code, which includes a typo of :SLOT1 instead of
    :SLOT-1 in the call to make-instance
       (defclass Foo ()
    ((Slot-1 :accessor Slot-1 :initarg :Slot-1 :initform 5)))

       (setq Test (make-instance 'Foo :Slot1 10))
    will not produce an error message, with the result that
    (Slot-1 Test) returns 5, not 10.

    This is a bug in the implementation; all implementations are
    supposed to flag this as an error.

[J] Forgetting the class must exist before any method can specialize upon it.

    Lisp programmers are used to being able to define functions in any
    order, where even if FOO calls BAR, FOO can be defined first. But doing
       (defmethod Area ((Rect Rectangle)) ...)
       (defclass Rectangle (Polygon) ...)
    is illegal. You have to define the class first.

    If while trying to debug the problem, you define the class by
    evaluating the definition without reordering the code to put the
    class first, you'll only run into problems later the next time you
    try to recompile the code from scratch.

    Many experienced programmers put each class definition in its own
    file at the top of the file, with methods for that class after it
    in the file. Others opt to put all the class definitions for a
    program in a single file that is loaded first, with methods in files
    that are loaded later.

[K] Changing a method to apply to a more general class does not
    supersede previous method.

    For example, suppose a user writes
       (defmethod Half-Area ((Rect Filled-Rectangle))
     (/ (Area Rect) 2))
    and then notices that this functionality could apply to all
    Rectangles, not just Filled-Rectangles. They might then change the
    class referenced in this method, under the specious intuition that by
    changing the old defintion, they are replacing it. In fact, they are
    actually adding a new, less-specific method.

    Now suppose that later on, they change this new method (in this
    example, by adding a call to FLOAT to avoid returning a ratio),
       (defmethod Half-Area ((Rect Rectangle))
     (float (/ (Area Rect) 2)))
    If they test it on an instance of Filled-Rectangle, they will be
    puzzled as to why their new definition appears to have not taken
    effect. But because the old definition specialized to Filled-Rectangle
    still exists, they're actually getting the old, more-specific definition.

    Moreover, the next time they restart a fresh Lisp and recompile
    the code, the problem will magicly disappear, since the old
    definition is no longer in the code.

----------------------------------------------------------------
;;; *EOF*

Archive-name: lisp-faq/part6
Last-Modified: Tue Jan 31 15:41:50 1995 by Mark Kantrowitz
Version: 1.52
Maintainer: Mark Kantrowitz and Barry Margolin <[e-mail]>
URL: http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/lisp/top.html
Size: 74887 bytes, 1429 lines

;;; ****************************************************************
;;; FTP Archives and Other Resources *******************************
;;; ****************************************************************
;;; Written by Mark Kantrowitz and Barry Margolin
;;; lisp_6.faq

This post contains Part 6 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 [e-mail].

Topics Covered (Part 6):
  [6-0] General information about FTP Resources for Lisp
  [6-1] Repositories of Lisp Software
  [6-3] Publicly Redistributable Lisp Software
  [6-6] Formatting code in LaTeX (WEB and other literate programming tools)
  [6-7] Where can I get an implementation of Prolog in Lisp?
  [6-8] World-Wide Web (WWW) Resources

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

----------------------------------------------------------------
Subject: [6-0] General information about FTP Resources for Lisp

Remember, when ftping compressed or compacted files (.Z, .z, .arc, .fit,
etc.) to use binary mode for retrieving the files.

Files that end with a .z suffix were compressed with the patent-free
gzip (no relation to zip). Source for gzip is available from:
   prep.ai.mit.edu:/pub/gnu/
as the files gzip-1.2.3.shar, gzip-1.2.3.tar,or gzip-1.2.3.msdos.exe.

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

----------------------------------------------------------------
Subject: [6-1] Repositories of Lisp Software

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

Common Lisp Repository:

   The Common Lisp Repository is accessible by anonymous ftp to
      ftp.cs.cmu.edu:/user/ai/lang/lisp/ [128.2.206.173]
   through the AFS directory
      /afs/cs.cmu.edu/project/ai-repository/ai/lang/lisp/
   or by WWW from the URL
      http://www.cs.cmu.edu:8001/Web/Groups/AI/html/repository.html
   and includes more than 250 megabytes of sources, including all
   freely distributable implementations and many programs. This
   repository supersedes the Lisp Utilities collection, and is now
   part of the CMU Artificial Intelligence Repository.

   Programs in the repository include XREF (portable cross referencing
   tool for Lisp, similar to the Symbolics Who-Calls and the Xerox
   MasterScope programs), Brad Miller's initializations package for
   Allegro CL 4.0, DEFSYSTEM (portable system definition facility, a
   "Make" for Lisp), a portable implementation of the X3J13 June 1989
   specification for logical pathnames, METERING (a portable code
   time/space profiling tool), SOURCE-COMPARE (a portable "diff" utility
   for Lisp), USER-MANUAL (a program which helps with documenting Lisp
   code), PSGRAPH (Joe Bates' PostScript DAG grapher), several matchers
   for Lisp, NREGEX (a regular expressions matcher), a date formatter, an
   infix reader macro for Lisp, SAVE-OBJECT (Kerry Koitzsch's package to
   save ASCII representations of Lisp objects to a file), Stephen
   Nicoud's semi-portable CLtL2 version of defpackage, LALR (Mark
   Johnson's lisp YACC parser generator), various implementations of the
   Loop Macro, William Schelter's sloop macro, Frank Ritter and Jim
   Panagos' implementation of the Yale yloop macro (described in
   McDermont, Charniak and Riesbeck's AI programming book), all free Lisp
   GUIs, including Express Windows, the iterate macro, Waters' Series
   Macro package, Waters' XP Lisp Pretty Printer, Bruno Haible's
   implementation of the Simplex algorithm, MAPFORMS (Moon's code
   walker), Brad Miller's resources package, and much much more.

   The repository has standardized on using 'tar' for producing
   archives of files and 'gzip' for compression.

   To search the keyword index by mail, send a message to:
      [e-mail]
   with one or more lines containing calls to the keys command, such as:
      keys lisp iteration
   in the message body.  Keywords may be regular expressions and are
   compared with the index in a case-insensitive conjunctive fashion.
   You'll get a response by return mail. Do not include anything else
   in the Subject line of the message or in the message body.  For help on
   the query mail server, include:
      help
   instead.

   A Mosaic interface to the keyword searching program is in the
   works.  We also plan to make the source code (including indexes) to
   this program available, as soon as it is stable.

   Most of the Common Lisp Repository appears on Prime Time Freeware
   for AI, Issue 1-1, a mixed-media book/CD-ROM publication. It
   includes two ISO-9660 CD-ROMs bound into a 224 page book and sells
   (list) for US$60 plus applicable sales tax and shipping and handling
   charges. Payable through Visa, Mastercard, postal money orders in US
   funds, and checks in US funds drawn on a US bank. For more
   information write to Prime Time Freeware, 370 Altair Way, Suite 150,
   Sunnyvale, CA  94086  USA, call 408-433-9662, 408-433-0727 (fax),
   or send email to [e-mail].

   Contributions of software and other materials are always welcome but
   must be accompanied by an unambiguous copyright statement that grants
   permission for free use, copying, and distribution -- either a
   declaration by the author that the materials are in the public domain,
   that the materials are subject to the GNU General Public License (cite
   version), or that the materials are subject to copyright, but the
   copyright holder grants permission for free use, copying, and
   distribution. (We will tell you if the copying permissions are too
   restrictive for us to include the materials in the repository.)
   Inclusion of materials in the repository does not modify their
   copyright status in any way. Materials may be placed in:
      ftp.cs.cmu.edu:/user/ai/new/
   When you put anything in this directory, please send mail to
      [e-mail]
   giving us permission to distribute the files, and state whether
   this permission is just for the AI Repository, or also includes
   publication on the CD-ROM version (Prime Time Freeware for AI).
   We would also appreciate if you would include a 0.doc file for your
   package; see /user/ai/new/package.doc for a template. (If you don't
   have the time to write your own, we can write it for you based on
   the information in your package.)

   The Common Lisp Repository is maintained by Mark Kantrowitz,
   [e-mail].

   Known mirrors:
      ftp.sunet.se:/pub/lang/lisp/

CLOS:
   The CLOS code repository is available by anonymous ftp to
      nervous.cis.ohio-state.edu:/pub/lispusers/clos/ [128.146.61.200]
   If you've got code you'd like to add to the repository, send mail to
   Arun Welch, [e-mail].  The CLOS code
   repository includes dag.lisp.Z and 3DGeometry.lisp.  [The AI
   Repository's Lisp Section includes a directory of CLOS code as well,
   in ftp.cs.cmu.edu:/user/ai/lang/lisp/oop/clos-code/.]

MCL:
   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/MCL2/contrib/       [134.149.2.3]
      http://www.cambridge.apple.com
   and also contains the Info-MCL mailing list archives. The
   repository contains, among other things, AV_Parser.hqx and Zebu
   (general parser toolkits), babylon-2.2.sit.hqx (expert system shell
   from GMD in Germany), btree.sit.hqx (binary trees), LGL.lisp (Lisp
   Graphics Library for MCL), quicktime code, mmlisp.sit.hqx
   (midi-manager interface), tips on optimizing MCL code, PARKA.sit.hqx
   (a knowledge representation system), starsim.sit.hqx (*Lisp for MCL),
   IP/TCP examples, and support for hypercard XCMDs and XFCNs.  See the
   file README for a quick overview of the contents of the MCL
   repository.

CLIM:
   The CLIM Library (a library of user contributed code for the CLIM
   environment) is available by anonymous ftp on
      cambridge.apple.com:/pub/clim [134.149.2.3]
   For information on CLIM, see the entry in [6-5] below.  For more
   information on the CLIM Library, contact Vincent Keunen, [e-mail].

MIT AI Lab:
   ftp.ai.mit.edu:/pub/
      loop-macro.tar               [LOOP from CLtL1]
      series/                      [SERIES from CLtL2; older version]
      Iterate/                     [Alternative to series and loop.]
      clmath.tar                   [Numeric math 1984]
      ontic/                       [ONTIC Knowledge Rep. for Mathematics]
   clmath is a Lisp library of mathematical functions that calculate
   hyperbolic and inverse hyperbolic functions, Bessel functions,
   elliptic integrals, the gamma and beta functions, and the incomplete
   gamma and beta functions.  There are probability density functions,
   cumulative distributions, and random number generators for the normal,
   Poisson, chi-square, Student's T, and Snedecor's F functions. Discrete
   Fourier Transforms. Multiple linear regression, Fletcher-Powell
   unconstrained minimization, numerical integration, root finding,
   and convergence. Code to factor numbers and to do the
   Solovay-Strassen probabilistic prime test is included.
   A technical report describing CLMath is available as MIT AI Lab
   Memo 774, Gerald Roylance, "Some Scientific Subroutines in LISP",
   September 1984. Iterate is Jonathan Amsterdam's alternative to
   series and the Loop macro. For more information, contact [e-mail].

LispUsers Archives:
   The LispUsers Archives, a collection of programs for Medley, can be
   found on
      nervous.cis.ohio-state.edu:/pub/lispusers/medley/
   The files include a plotting module, addressbook, chat program, clock,
   call-grapher, grep implementation, Tower of Hanoi, Life, lisp dialect
   translator, and fonts. Also on nervous.cis.ohio-state.edu is GTT, an
   implementation of Chandrasekaran's Generic Tasks Toolset, in directory
   pub/lispusers/toolset.

Amiga LISP implementations:
   There's a repository of Amiga LISP implementations (and other Lisp-like
   language implementations) on gatekeeper.pa.dec.com:/pub/micro/amiga/lisp/.

Inside Computer Understanding:
   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:/pub/schank/icu/
   This includes the SAM and ELI miniatures. It will eventually include copies
   of the miniature versions of PAM, POLITICS, and Tale-Spin. The FOR
   macro is also available in this directory, as are a set of functions
   for manipulating and matching lisp representations of Conceptual
   Dependency formulas.  Contact Bill Andersen <[e-mail]> for
   more information.

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, [phone]; FAX: [phone]
    Mac          ISBN 1-55860-227-5
    DOS 3.5"     ISBN 1-55860-228-3
    DOS 5.25"    ISBN 1-55860-229-1

NL Software Registry:
   A catalog of free and commercial natural language software is
   available from the Natural Language Software Registry, by anonymous
   ftp from
      ftp.dfki.uni-sb.de:/registry/
   or by email to [e-mail].

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 [e-mail].

Waters' Programs:

   Dick Waters' XP Lisp Pretty Printer is available by anonymous ftp
   from
      merl.com:/pub/xp/
   as the files xp-code.lisp, xp-doc.txt, and xp-test.lisp.

   The Series Macro is available from
      merl.com:/pub/series/
   as the files s-code.lisp, s-test.lisp, and s-doc.txt. The
   Series macro package is described fully in Waters, R.C., "Automatic
   Transformation of Series Expressions into Loops", ACM Transactions on
   Programming Languages and Systems, 13(1):52--98, January 1991,
   MIT/AIM-1082 and MIT/AIM-1083.

   Both programs are also available from the Common Lisp Repository
   described above.

   For further information, contact Dick Waters, <[e-mail]> or
   <[e-mail]>. An improved version of Series is in the works.

----------------------------------------------------------------
Subject: [6-3] Publicly Redistributable Lisp Software

AI Algorithms and Tools:

   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/ [148.187.10.13]
   Written by Mike Rosner and Dean Allemang {dean,mike}@idsia.ch.

   AI_ATTIC is an anonymous ftp collection of classic AI programs and
   other information maintained by the University of Texas at Austin.  It
   includes Parry, Adventure, Shrdlu, Doctor, Eliza, Animals, Trek, Zork,
   Babbler, Jive, and some AI-related programming languages.  This
   archive is available by anonymous ftp from
      ftp.cc.utexas.edu:/pub/AI_ATTIC/  [128.83.186.13]
   (AKA bongo.cc.utexas.edu). For more information, contact
   [e-mail].

Analogical Reasoning:

   SME is the Structure-Mapping Engine, as described in Falkenhainer,
   Forbus, and Gentner's 1987 AIJ article.  Available from
   multivac.ils.nwu.edu:/pub/SME For further information, contact Brian
   Falkenhainer <[e-mail]> or Ken Forbus
   <[e-mail]>.

Benchmarks:

   Gabriel Lisp Benchmarks are available by anonymous ftp as
   ai.toronto.edu:/pub/gabriel-lisp-benchmarks.tar.Z.
   The benchmarks are described in the book "Performance Evaluation of
   Lisp Systems", by Richard Gabriel.

   Lucid CL contains a set of benchmarks in its goodies/ directory,
   including Bob Boyer's logic programming benchmark, a benchmark to
   create and browse through an AI-like database of units, a CLOS speed
   test, a compilation speed test, TAKR (the 100 function version of TAK
   that tries to defeat cache memory effects), CTAK (A version of the
   TAKeuchi function that uses the CATCH/THROW facility), STAK (A version
   of the TAKeuchi function with special variables instead of parameter
   passing), DERIV and DDERIV (Symbolic derivative benchmarks written by
   Vaughn Pratt), DESTRU (a destructive operation benchmark), DIV2 (a
   benchmark which divides by 2 using lists of n ()'s), the FFT benchmark
   written by Harry Barrow, FPRINT (a benchmark to print to a file),
   FRPOLY (a Franz Lisp benchmark by Fateman based on polynomial
   arithmentic), Forest Baskett's PUZZLE benchmark (originally written in
   Pascal), the TPRINT benchmark to read and print to the terminal, a
   benchmark that creates and traverses a tree structure, and TRIANG
   (board game benchmark). Some of the benchmarks may work only in Lucid.

Blackboard Architectures:

   The UMass GBB system (V1.2) is available by anonymous ftp from
   ftp.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, 401 Main Street,
   Amherst, Massachusetts 01002, 413-256-8990, fax [phone].

   For a tutorial on how to build a blackboard system, see the paper
      P. R. Kersten and Avi C. Kak, "A Tutorial on LISP Object-Oriented
      Programming for Blackboard Computation (Solving the Radar Tracking
      Problem)", International Journal of Intelligent Systems 8:617-669, 1993
   Although samples of the code are given in the paper, the full source
   code is available in a separate technical report from the School of
   Electrical Engineering at Purdue University.  If you are interested in
   getting a copy of the technical report, send mail to Avi Kak
   <[e-mail]>. (The circumstances under which the software was
   developed prevent them from making the source code available by
   anonymous FTP. However, the full source code is printed in the
   technical report.)

Case-based Reasoning:

   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 <[e-mail]> or Ray Bareiss
   <[e-mail]> or Erik Eilerts <[e-mail]>
   Available by anonymous ftp from cs.utexas.edu:/pub/porter

   The complete code for "Inside Case-Based Reasoning" by Riesbeck and
   Schank, 1989, is available by anonymous ftp from
      cs.umd.edu:/pub/schank/icbr/
   This includes code for an instructional version of CHEF by Kristian
   Hammond and MICRO-xxx. Contact Bill Andersen <[e-mail]>
   for more information.

CLOS Software:
   See question [5-6].

Constraint Programming and Non-determinism:

   SCREAMER:

   Screamer is an extension of Common Lisp that adds support for
   nondeterministic programming.  Screamer consists of two levels.  The
   basic nondeterministic level adds support for backtracking and
   undoable side effects.  On top of this nondeterministic substrate,
   Screamer provides a comprehensive constraint programming language in
   which one can formulate and solve mixed systems of numeric and
   symbolic constraints.  Together, these two levels augment Common Lisp
   with practically all of the functionality of both Prolog and
   constraint logic programming languages such as CHiP and CLP(R).
   Furthermore, Screamer is fully integrated with Common Lisp. Screamer
   programs can coexist and interoperate with other extensions to Common
   Lisp such as CLOS, CLIM and Iterate.

   In several ways Screamer is more efficient than other implementations
   of backtracking languages.  First, Screamer code is transformed into
   Common Lisp which can be compiled by the underlying Common Lisp
   system.  Many competing implementations of nondeterministic Lisp are
   interpreters and thus are far less efficient than Screamer.  Second,
   the backtracking primitives require fairly low overhead in Screamer.
   Finally, this overhead to support backtracking is only paid for those
   portions of the program which use the backtracking primitives.
   Deterministic portions of user programs pass through the Screamer to
   Common Lisp transformation unchanged.  Since in practise, only small
   portions of typical programs utilize the backtracking primitives,
   Screamer can produce more efficient code than compilers for languages
   in which backtracking is more pervasive.

   Screamer is fairly portable across most Common Lisp implementations.
   It currently runs under Genera 8.1.1 and 8.3 on both Symbolics 36xx
   and Ivory machines, under Lucid 4.0.2 and 4.1 on Sun SPARC machines,
   under MCL 2.0 and 2.0p2 on Apple Macintosh machines, and under Poplog
   Common Lisp on Sun SPARC machines.  It should run under any
   implementation of Common Lisp which is compliant with CLtL2 and with
   minor revision could be made to run under implementations compliant
   with CLtL1 or dpANS.

   Screamer is available by anonymous FTP from
      ftp.ai.mit.edu:/pub/screamer.tar.Z
   Contact Jeffrey Mark Siskind <[e-mail]> for further
   information. Screamer is also available from the Common Lisp Repository.

   The Screamer Tool Repository, a collection of user-contributed
   Screamer code, is available by anonymous ftp from
      ftp.cis.upenn.edu:/pub/screamer-tools/
   or by WWW from
      http://www.cis.upenn.edu/~screamer-tools/home.html
   Please direct all inquires about the repository to
   [e-mail].

Defeasible Reasoning:

   An implementation of J. Paris and A. Vencovska's model of belief is
   available by anonymous ftp from
      ftp.cs.cmu.edu:/user/ai/areas/reasonng/defeasbl/belief/
   Paris and Vencovska's paper (Artificial Intelligence, 64(2), December
   1993) provides a mathematical model of an agent's belief in an event
   by identifying it with his ability to imagine the event within the
   context of his previous experience.  This approach leads to beliefs
   having properties different from those normally ascribed to it. The
   implementation was written by Ian Pratt <[e-mail]> and Jens
   Doerpmund <[e-mail]> and runs in Common Lisp.

Eliza and Similar Programs:

   See Peter Norvig's book and AI_ATTIC (question [6-1] above).

   The doctor.el is an implementation of Eliza for
   GNU-Emacs emacs-lisp. Invoke it with "Meta-X doctor"

   muLISP-87 (a MSDOS Lisp sold by Soft Warehouse) includes
   a Lisp implementation of Eliza.

   Implementations of ELIZA for other languages are mentioned in the AI FAQ.

   The original Parry (in MLISP for a PDP-10) is available in
   labrea.stanford.edu:/pub/parry.tar.Z.

   Other programs, such as RACTER, are listed in part 4 of the AI FAQ.

Expert Systems:

   FOCL is an expert system shell and machine learning program written in
   Common Lisp. The machine learning program extends Quinlan's FOIL
   program by containing a compatible explanation-based learning
   component.  FOCL learns Horn Clause programs from examples and
   (optionally) background knowledge. The expert system includes a
   backward-chaining rule interpreter and a graphical interface to the
   rule and fact base. For details on FOCL, see: Pazzani, M. and Kibler,
   D., "The role of prior knowledge in inductive learning", Machine
   Learning 9:54-97, 1992. It is available by anonymous ftp from
      ics.uci.edu:/pub/machine-learning-programs/
   as the files README.FOCL-1-2-3, FOCL-1-2-3.cpt.hqx (a binhexed,
   compacted Macintosh application), FOCL-1-2-3.tar.Z (Common Lisp
   source code), and FOCL-1-2-3-manual.hqx (binhexed manual).  If you
   use a copy of FOCL, or have any comments or questions, send mail to
   [e-mail].

   BABYLON is a development environment for expert systems. It
   includes frames, constraints, a prolog-like logic formalism, and a
   description language for diagnostic applications. It is implemented in
   Common Lisp and has been ported to a wide range of hardware platforms.
   Available by anonymous ftp from
      ftp.gmd.de:/gmd/ai-research/Software/Babylon/ [129.26.8.84]
   as a BinHexed stuffit archive, on the Web via the URL
      http://www.gmd.de/
   on the Apple CD-ROM, or with the book "The AI Workbench BABYLON",
   which contains *full source code* of BABYLON and the stand-alone
   version for the Mac. The book describes the use of BABYLON in detail.

   OPS5 is a public domain Common Lisp implementation of the OPS5
   production system interpreter written by Charles Forgy. It is
   available from the CMU AI Repository in
      ftp.cs.cmu.edu:/user/ai/areas/expert/ops5/
   and includes the original port by George Wood and Jim Kowalski
   (ops5orig.tar.gz), and a later port by Mark Kantrowitz (ops5.tar.gz).
   The latter has been tested under Allegro, Lucid, CMU CL, Ibuki CL and
   MCL.

Frame Languages:

   FrameWork is a portable generic frame system available from the CMU
   AI Repository, in
      ftp.cs.cmu.edu:/user/ai/areas/kr/frames/framework/

   THEO (learning frame system) is available free from CMU, after
   signing a license agreement. Send mail to [e-mail].

   FrameKit is available free from CMU, after signing a
   license agreement. Send mail to [e-mail]

   KR. Send mail to [e-mail] for more info.

   PARKA. Frames for the CM. Contact [e-mail].

   PARMENIDES (Frulekit) is available free, after signing
   a license agreement. Send mail to [e-mail]

   FROBS is available free by anonymous ftp from
   cs.utah.edu:/pub/frobs.tar.Z
   Contact Robert Kessler <[e-mail]> for more info.

   PFC is a simple frame system written by Tim Finin
   available free by anonymous ftp from linc.cis.upenn.edu.

   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 <[e-mail]>.

Genetic Algorithms:

   GECO (Genetic Evolution through Combination of Objects) is a
   genetic algorithm shell written by George Williams,
   <[e-mail]>. It is available by anonymous ftp
   from cambridge.apple.com:/pub/mcl2/contrib/ as the following
   files:
      GECO-v1.0.cpt.hqx       binhex'd Compact Pro archive
      GECO-v1.0.tar.Z         compressed tar file for Unix machines (no MCL
                              fonts)
      GECO.abstract           a brief description
   It runs in MCL 2.0, but should be portable among CLtL2 compliant
   Common Lisps.

   GAL is a genetic algorithm suite written by Bill Spears of NRL. The
   MCL2.0 port was done by Howard Oakley <[e-mail]> and
   is available from cambridge.apple.com:/pub/MCL2/contrib as
   GAL.sea.hqx.  Improvements and adaptations should be sent to Bill
   Spears, but questions on the MCL port should be directed to Howard Oakley.

   Other genetic algorithms code is available
      ftp.aic.nrl.navy.mil:/pub/galist
   including Genesis (source-code/ga-source/genesis.tar.Z) and the archives
   of the GA-List mailing list. A survey of free and commercial
   genetic algorithms implementations is available in
   information/ga-software-survey.txt.

Knowledge Representation:

   KNOWBEL is an implementation of Telos (a sorted/temporal logic
   system) by Bryan M. Kramer, <[e-mail]>. 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 (Semantic Network Processing System) is the implementation of a
   fully intensional theory of propositional knowledge representation and
   reasoning. SNePS includes a module for creating and accessing
   propositional semantic networks, path-based inference, node-based
   inference based on SWM (a relevance logic with quantification) that
   uses natural deduction and can deal with recursive rules, forward,
   backward and bi-directional inference, nonstandard logical connectives
   and quantifiers, an assumption based TMS for belief revision, a
   morphological analyzer and a generalized ATN (GATN) parser for parsing
   and generating natural language, SNePSLOG, a predicate-logic-style
   interface to SNePS, XGinseng, an X-based graphics interface for
   displaying, creating and editing SNePS networks, SNACTor, a
   preliminary version of the SNePS Acting component, and SNIP 2.2, a new
   implementation of the SNePS Inference Package that uses rule shadowing
   and knowledge migration to speed up inference.  SNeRE (the SNePS
   Rational Engine), which is part of Deepak Kumar's dissertation about
   the integration of inference and acting, will replace the current
   implementation of SNACTor.  SNePS is written in Common Lisp, and has
   been tested in Allegro CL 4.1, Lucid CL 4.0, TI Common Lisp, CLISP
   May-93, and CMU CL 17b. It should also run in Symbolics CL, AKCL 1.600
   and higher, VAX Common Lisp, and MCL. The XGinseng interface is built
   on top of Garnet.  SNePS 2.1 is free according to the GNU General
   Public License version 2. The SNePS distribution is available by
   anonymous ftp from
      ftp.cs.buffalo.edu:/pub/sneps/  [128.205.32.9]
   as the file rel-x-yyy.tar.Z, where 'x-yyy' is the version. The other
   files in the directory are included in the distribution; they are
   duplicated to let you get them without unpacking the full distribution
   if you just want the bibliography or manual. If you use SNePS, please
   send a short message to [e-mail] and
   [e-mail]. Please also let them know whether you'd like to
   be added to the SNUG (SNePS Users Group) mailing list.

   COLAB (COmpilation LABoratory) is a hybrid knowledge representation
   system emphasizing the horizontal and vertical compilation of
   knowledge bases. It is comprised of cooperating subsystems -- CONTAX,
   FORWARD, RELFUN and TAXON -- which deal with different knowledge
   representation and reasoning formalisms. Each subsystem can also be
   used as stand-alone system. CONTAX deals with constraint nets and
   constraint-propagation techniques. Relational knowledge in the form of
   Horn rules is processed by forward (FORWARD) and backward (RELFUN)
   chaining. Taxonomic knowledge is represented by intensional concept
   definitions which are automatically arranged in a subsumption
   hierarchy (TAXON).  The COLAB software was developed at DFKI and the
   University of Kaiserslautern and runs in Common Lisp. (The subsystems
   have been tested in AKCL and Lucid CL, and possibly also Allegro CL
   and Symbolics CL.) All the subsystems are available free of charge for
   research purposes.
   o  RELFUN is a logic-programming language with call-by-value (eager),
      non-deterministic, non-ground functions, and higher-order operations.
      It accepts freely interchangeable LISP-style and PROLOG-style syntaxes.
      For sources to RELFUN and copies of relevant papers, contact
      Dr. Harold Boley, DFKI, Postfach 2080, W-6750 Kaiserslautern, Germany,
      call [phone], fax [phone], or send email to
      [e-mail].
   o  TAXON is a terminological knowledge representation system extended by
      concrete domains.  For sources to TAXON and copies of relevant papers,
      contact Philipp Hanschke, DFKI, Postfach 2080, W-6750 Kaiserslautern,
      Germany, call [phone], fax [phone], or send email to
      [e-mail].
   o  CONTAX is a constraint system for weighted constraints over
      hierarchically structured finite domains. CONTAX uses CLOS in addition
      to Common Lisp.  For sources to CONTAX and copies of relevant papers,
      contact Manfred Meyer, DFKI, Postfach 2080, W-6750 Kaiserslautern,
      Germany, call [phone], fax [phone], or send email to
      [e-mail].
   o  FORWARD is a logic programming language with bottom-up and top-down
      evaluation of Horn clauses. For sources to FORWARD and copies of
      relevant papers, contact Knut Hinkelmann, DFKI, Postfach 2080, W-6750
      Kaiserslautern, Germany, call [phone], fax [phone],
      or send email to [e-mail].

   URANUS is a logic-based knowledge representation language. Uranus is
   an extension of Prolog written in Common Lisp and using the syntax of
   Lisp. Uranus extends Prolog with a multiple world mechanism for
   knowledge representation and term descriptions to provide
   functional programming within the framework of logic programming.
   It is available free by anonymous ftp from
      etlport.etl.go.jp:/pub/uranus/ftp/ [192.31.197.99]
   for research purposes only.  For more information contact the author,
   Hideyuki Nakashima <[e-mail]>.

Languages and Alternate Syntaxes:

   Generalized Lisp (or Glisp for short) is a coordinated set of high
   level syntaxes for Common Lisp.  Initially GLisp consists of three
   dialects: Mlisp, Plisp and ordinary Lisp, together with an extensible
   framework for adding others.  Mlisp (Meta-Lisp) is an Algol-like
   syntax for people who don't like writing parentheses. For example,
   one can write print("abc", stream) instead of (print "abc" stream).
   Plisp (Pattern Lisp) is a pattern matching rewrite-rule language.
   Plisp is a compiler-compiler; its rules are optimized for writing
   language translators.  All dialects may be freely intermixed in a
   file. The translators for all dialects are written in Plisp, as is
   the Glisp translator framework itself. Support routines for the
   translators are written in Mlisp and/or Lisp. All dialects are
   translated to Common Lisp and execute in the standard Common Lisp
   environment. Glisp is available by anonymous ftp from apple.com or
      ftp.apple.com:/dts/mac/lisp/glisp.tar.Z
   GLISP runs in MCL and has to be modified for other Common Lisp
   implementations.

   CGOL is algol-like language that is translated into Lisp before
   execution. It was developed originally by Vaughn Pratt. A Common Lisp
   implementation of CGOL is available by anonymous ftp from
      peoplesparc.berkeley.edu:/pub/cgol.1.tar.Z  [128.32.131.14]
   (The number "1" may increase if newer versions are posted.)  It was
   written by a UC Berkeley graduate student, Tom Phelps, as a term
   project, so there may still be some rough edges. There is a lot of
   documentation in the distribution, including the "original" CGOL memo
   (pratt.memo). For more information, contact Richard Fateman
   <[e-mail]>.

   StarLisp Simulator. The StarLisp Simulator simulates *Lisp, one of
   the programming langauges used to program the Connection Machine.
   StarLisp runs under Symbolics, Lucid, Allegro, and Franz, and is
   available by anonymous ftp from
      think.com:/cm/starlisp/starsim-f19-sharfile
   The "CM5 *Lisp Tutorial" is available by anonymous ftp from
      arp.anu.edu.au:/ARP/papers/starlisp/  [150.203.20.2]
   in Andrew "ez" and postscript formats.  Write to Zdzislaw Meglicki
   <[e-mail]> for more information about the tutorial.

   InterLisp->Common-Lisp Translator -- ftp.ai.sri.com:/pub/pkarp/lisp/ilisp/
   Other InterLisp to Common Lisp translators may be found in the LispUsers
   archive listed above.

   The Yale Haskell system runs in CMU Common Lisp, Lucid CL, and AKCL.
   It is available by anonymous ftp from
        Chalmers animal.cs.chalmers.se:/pub/haskell/yale/ [129.16.225.66]
        Glasgow  ftp.dcs.glasgow.ac.uk:/pub/haskell/yale/ [130.209.240.50]
        Yale     nebula.cs.yale.edu:/pub/haskell/yale/    [128.36.13.1]
   as the files
        haskell-beta-2-source.tar.Z   -- full sources
        haskell-beta-2-sparc.tar.Z    -- sparc executable

Lisp Tools:

   See the Common Lisp Repository in [6-2].

   The Automatic Memoization Facility adds a practical memoization
   facility to Common Lisp. Automatic memoization is a technique by which
   an existing function can be transformed into one that "remembers"
   previous arguments and their associated results, yielding large
   performance gains for certain types of applications.  This facility
   extends the ideas from Norvig's book into what is needed for a
   practical tool for us in large programs. It adds facilities for
   bookkeeping and timing, and lets you evaluate of the timing advantages
   of memoization, and save hash tables to disk for automatic reuse in
   later sessions. The code is available by anonymous ftp from
   archive.cs.umbc.edu:/pub/Memoization [130.85.100.53]. Contact Marty Hall
   <[e-mail]> for more information. The code includes an
   overview of memoization and its applications.

   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
         nebula.cs.yale.edu:/pub/plisp/plisp.tar.Z [128.36.13.1]
   Written by John Peterson <[e-mail]>.

   RegExp is an extension to Allegro Common Lisp which adds
   regular expression string matching, using the foreign
   function interface. Available by anonymous ftp from
   ftp.ai.sri.com:/pub/pkarp/regexp/. Contact [e-mail]
   for more information.

   ifi.informatik.uni-stuttgart.de:/pub/xit/cl-utilities/ contains
   three small utilities:
        completion.lisp         A simple filename completion program.
        cl-utilities.lisp       Some macros for dealing with points,
                                regions, and some miscellaneous macros.
        copy-objects.lisp       Code for copying instances.

   think.com:/think/lisp contains some useful lisp code (most of it
   Symbolics dependent) including:
        lisp-lint.lisp          A set of compiler style checkers that
                                warn when a function call does not
                                conform to Common Lisp.

   MEASURES is a system to handle engineering numbers and measures in
   Common Lisp. It runs in Allegro CL, LispWorks, MCL, and Symbolics CL.
   Written by Roman Cunis.  Some documentation can be found in the file
   measures.doc and examples in measures-example.lisp.  It is available
   from the Common Lisp Repository
      ftp.cs.cmu.edu:/user/ai/lang/lisp/lisp/syntax/
   in the file measures-2.0.tar.gz.  For further information, contact Ralf
   Moeller, University of Hamburg, Bodenstedtstr 16, 2000 Hamburg 50,
   Germany, call 40-4123-6134, fax [phone], or send email to
   [e-mail].

   DEFTABLE provides a macro that unifies the interface to Common
   Lisp's table-like data structures (e.g., association lists, property
   lists, and hash tables). Written by Peter Norvig
   <[e-mail]>.  It is available by anonymous ftp from
   ftp.ai.mit.edu:/pub/lptrs/deftable.lisp [128.52.32.6] and also the
   Lisp Utilities Repository. An article describing deftable was
   published in ACM Lisp Pointers 5(4):32-38, December 1992.

   SEQUEL (SEQUEnt processing Language) is designed both as a general
   purpose AI language for generating type-secure and efficient Lisp
   programs and as a very high level specification language for
   implementing logics on the computer. Designed at the University of
   Leeds, SEQUEL compiles sequent-calculus specifications of arbitrary
   logics to working proof assistants.  The sequent calculus
   specifications are compiled into Horn clauses and from Horn clauses
   into virtual machine instructions of an abstract machine SLAM (SequeL
   Abstract Machine) which then translates these instructions into
   efficient Lisp code using WAM-style compilation techniques.  Although
   a functional programming language, SEQUEL includes facilities for
   backtracking usually associated with logic programming, and supports a
   pattern-matching method of building functions based on Prolog
   notation.  The Lisp code generated from SEQUEL functions is completely
   portable and runs in most Common Lisp implementations. It is
   comparable in efficiency with hand-written code.  SEQUEL also supports
   optional static type-checking in the manner of SML and similar
   languages.  With type-checking enabled, all inputs and loaded files
   are type-checked and the resulting Lisp programs are type-secure.  The
   SEQUEL compiler uses the information gleaned from type-checking to add
   compiler directives within the generated Lisp functions to produce
   optimized Lisp programs.  SEQUEL includes a UNIX-style top level with
   its own trace package and type-checking debugger. SEQUEL is also of
   interest to automated reasoning researchers. It provides a very
   powerful means of generating proof assistants and theorem provers that
   have a very fast performance using WAM-derived compilation techniques.
   The theorem provers are automatically verified. It includes a facility
   for Datalog and an efficient occurs-check Horn-clause-to-Lisp
   compiler, a mouse driven graphical interface for all proof assistants
   and theorem provers built under SEQUEL (currently available only under
   Lucid).  Several demonstration theorem provers for different logics,
   including FOL, Clarke's logic of space, partial evaluation, set
   theory, and constructive type theory are available.  SEQUEL runs under
   Kyoto CL, Lucid CL, and CMU Common Lisp.  SEQUEL is available free for
   non-commercial purposes by anonymous ftp from
      agora.leeds.ac.uk:/scs/logic/  [129.11.144.130]
   and includes LaTeX documentation in the distribution. For more
   information, contact Mark Tarver <[e-mail]> or
   <[e-mail]>.

   ILU (Xerox PARC Inter-Language Unification) is a system for promoting
   language interoperability via interfaces between units of program
   structure called "modules". ILU currently supports Common Lisp, ANSI
   C, C++, and Modula-3. The Common Lisp support provides CLOS `network
   objects' that communicate via RPC between Lisp processes, as well
   between Lisp and other languages.  ILU is available by anonymous ftp
   from
      parcftp.parc.xerox.com:/pub/ilu/1.6.4/ilu-1.6.4.tar.gz
   Write to Bill Janssen <[e-mail]> for more information.

Machine Learning:

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

   COBWEB/3 is a concept formation system available free after
   signing a license agreement. Contact [e-mail]
   for more information.

   RWM (Refinement With Macros) is a Common Lisp program for learning
   problem solving strategies. RWM takes a high level description of a
   problem as input and successively refines it into a sequence of
   "easier" subproblems, which collectively constitute a strategy for
   solving the given problem. RWM also learns macro moves which are
   useful for efficiently solving the problem. A short documentation and
   some example problems/strategies are included. To get a copy of this
   description, send mail to the Bilkent University Archieve Server
   [e-mail] with "send RWM.tar.Z" in the body of the
   message. For further information, contact H. Altay Guvenir
   <[e-mail]>.

Mathematics:

   MockMma -- peoplesparc.berkeley.edu:/pub/mma.tar.Z       [128.32.131.14]
   A Mathematica-style parser written in Common Lisp. Written by Richard
   Fateman; [e-mail]. Runs in any valid Common Lisp.
   Tested in Allegro, KCL and Lucid.

   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.

   QUAIL (Quantitative Analysis in Lisp) extends Common Lisp to better
   support quantitative analysis. It includes an object-oriented
   quantitative analysis programming environment based on CLOS.  Quail
   was developed by the Statistical Computing Laboratory of the
   Department of Statistics and Actuarial Science of the University of
   Waterloo.  It includes a variety of mathematical and statistical
   capabilities, such as symbolic and numerical differentiation,
   numerical integration, probability calculations (e.g., pseudo-random
   number generation), and statistical response models.  The
   object-oriented graphics display facilities include building blocks
   for arbitrary graphics, a collection of stock statistical graphics,
   function plotting, 3d-rotating function and surface plots, and
   graphical browsers. Quail currently runs in MCL, but a Franz and CLX
   based version is forthcoming. It is available by anonymous ftp from
      setosa.uwaterloo.ca:/pub/Quail/ [129.97.141.101]
   You must read the file README-I-MEAN-IT and return a signed copy of
   the license agreement ($10 annual license fee) before using the
   software. For further information, contact Dr. R. W. Oldford,
   <[e-mail]> or <[e-mail]>.

Medical Reasoning:

   TMYCIN -- sumex-aim.stanford.edu:/tmycin  The TMYCIN rule based system.

Music:

   Common Music is a music composition language written in Common Lisp
   and CLOS that outputs music (directly or through scorefiles) to a
   variety of synthesis packages, such as the Music Kit, Common Lisp
   Music, MIDI, and CSound.  Common Music runs under MCL 2.0, Allegro CL
   3.1.2 (NeXT), AKCL 1.615 (NeXT), Allegro CL 4.1 beta (SGI Iris), and
   AKCL 6.15 (Sun4). It is available by anonymous ftp from
      ccrma-ftp.stanford.edu:/pub/Lisp/cm.tar.Z [36.49.0.93]
      ftp.zkm.de:/pub/cm.tar.Z             [192.101.28.17]
   To be added to the mailing list, send mail to
   [e-mail]. For further information, contact
   Rick Taube, <[e-mail]> or <[e-mail]>.
   [Note: In the Common Music sources, there is a generic portable Lisp
   Listener style interpreter that supports command dispatching in
   addition to Lisp evaluation. It is the file ./utils/tl.lisp.]

   Common Lisp Music (CLM) is a software synthesis and signal
   processing package (CL-MUSIC) and a package that makes it relatively
   easy to take advantage of the Motorola DSP 56000 (CL-MUSIC-56).  It is
   available by anonymous ftp from
      ccrma-ftp.stanford.edu:/pub/Lisp/clm.tar.Z [36.49.0.93]
   Basic documentation is in clm.wn (or clm.rtf) and
   ins.lisp.  CLM runs on NeXT under Allegro CL or KCL and on SGI Indigo
   under Allegro CL. The non-56000 version should run on any machine with
   C and Common Lisp. Send bug reports or suggestions to
   Bil Schottstaedt <[e-mail]>.

   Common Music Notation (CMN) is a western music notation package based on
   Common Lisp, CLOS (pcl), PostScript, and the Adobe Sonata font. It is
   available by anonymous ftp from
      ccrma-ftp.stanford.edu:/pub/Lisp/cmn.tar.Z [36.49.0.93]
   To be added to the mailing list (same list as for Common Music),
   send mail to [e-mail].  Please send bug
   reports and suggestions to Bil Schottstaedt <[e-mail]>.

Natural Language Processing:

   The Xerox part-of-speech tagger is available by anonymous ftp from
   parcftp.xerox.com:/pub/tagger/tagger-1-0.tar.Z. It is implemented in
   Common Lisp and has been tested in Allegro CL 4.1, CMU CL 17e, and
   Macintosh CL 2.0p2. For more information, contact the authors, Jan Pedersen
   <[e-mail]> and Doug Cutting <[e-mail]>.

Natural Language Generation:

   FUF is a natural language generation system based on Functional
   Unification Grammars implemented in Common Lisp. It includes a
   unifier, a large grammar of English (surge), a user manual and many
   examples. FUF is available by anonymous ftp from
      cs.columbia.edu:/pub/fuf/
      black.bgu.ac.il:/pub/fuf/
   as the files fuf5.2.tar.Z and surge.tar.Z. For further information,
   contact the author, Michael Elhadad <[e-mail]>.
   [A WAM-based C compiler for FUF is in the works.]

Neural Networks:

   ANSIL  -- nervous.cis.ohio-state.edu:/pub/lispusers/ansil/
             "Advanced Network Simulator in Lisp"
             email: [e-mail]

Object-Oriented Programming:

   PCL -- parcftp.xerox.com:/pcl/ [13.1.64.94]
   Portable Common Loops (PCL) is a portable implementation of
   the Common Lisp Object System (CLOS). A miniature CLOS
   implementation called Closette is available pcl/mop/closette.lisp.

   CLOS-on-KEE -- zaphod.lanl.gov:/pub/
   A subset of CLOS that is implemented on top of KEE. Contact
   [e-mail] (Skip Egdorf) for more info.

   MCS (Meta Class System) -- ftp.gmd.de:/lang/lisp/mcs/ [129.26.8.84]
   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. Runs in any valid Common Lisp.
   Contact: Harry Bretthauer and Juergen Kopp, German National Research
   Center for Computer Science (GMD), AI Research Division,
   P.O. Box 1316, D-5205 Sankt Augustin 1, FRG, email: [e-mail]

   CommonORBIT (also called CORBIT) is an object-oriented extension of
   Common Lisp.  It uses a prototype (classless) model of OOP, is easy to
   use and yet has many sophisticated features found also in KL-ONE type
   languages.  CommonORBIT is a Common Lisp reimplementation of ORBIT,
   which was originally conceived by Luc Steels around 1981-1983.
   Because of its delegation-based rather than class-based inheritance,
   CommonORBIT offers extreme flexibility to define and change
   practically anything at run-time.  Because of the generic functions,
   it fits well into regular Lisp code.  It can co-exist with CLOS but
   remains completely separate. The source code of CommonORBIT is in the
   public domain and available by anonymous ftp from the Lisp
   Utilities Repository,
      ftp.cs.cmu.edu:/user/ai/lang/lisp/
   in the oop/non-clos/corbit/ subdirectory as the file corbit.tar.gz.
   Documentation is available as the files corbit.msword.hqx, corbit.ps
   or corbit.text. A stripped-down version of CORBIT, known as BOOPS
   (Beginner's Object-Oriented Programming System), is also available
   from the repository as boops.tar.Z. For further information,
   contact the author, Koenraad de Smedt <[e-mail]>.


Parser Generators:

   Mark Johnson <[e-mail]> has written a LALR parser generator
   for Common Lisp. It is fairly small (about 500 lines of code) and
   can be found in the Common Lisp Repository above.

   IPG (Incremental Parser Generator) is available by email from
   Jan Rekers <[e-mail]>.  It is an appendix to his thesis. It is
   written in LeLisp, but should be portable to other Lisp dialects.

   Zebu 2.8.5 is a parser generator for Common Lisp by Joachim H. Laubsch
   <[e-mail]>.  It is an extention written in Common
   Lisp of the Scheme version.  It generates a LALR(1) parsing table.  To
   parse a string with a grammar, only this table and a driver need to be
   loaded. The present version of Zebu contains the ability to define
   several grammars and parsers simultaneously, a declarative framework
   for specifying the semantics, as well as efficiency related
   improvements.  The current version compiles a grammar with 300
   productions (including dumping of the tables to disk) in approx 2
   minutes and 30 seconds on a HP 9000/370.  This implimentation has been
   tested in Lucid CL, Allegro CL, and MCL 2.0b. The current version
   can also produce a generator in addition to a parser. A copy may be
   found on cambridge.apple.com:/pub/mcl2/contrib/zebu-2.2.tar.Z.


Probabilistic Reasoning and Statistics:

   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 includes code for manipulating graphical belief models such
   as Bayes Nets and Relevance Diagrams (a subset of Influence Diagrams)
   using both belief functions and probabilities as basic representations
   of uncertainty. It is available by anonymous ftp from
      ftp.stat.washington.edu [128.95.17.34]
   and by email from the author, Russell Almond <[e-mail]>.
   Contact the author at [e-mail] for information about a
   commercial version GRAPHICAL-BELIEF currently in the prototype stages.

   XLISP-STAT is an extensible 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 [128.101.51.1]
   The CL port does not yet include the lisp-stat dynamic graphics
   package, only the numerics. The XLisp version is available from
   the above site and several mirror sites, such as mac.archive.umich.edu,
   and runs on the Apple Macintosh, Unix systems running X11
   (Vax, PMAX, Sun3, Encore Multimax, and Cray XMP), Sun workstations
   running SunView, and the Commodore Amiga. An experimental version
   for DOS computers running Microsoft Windows 3.0 is also available.
   Documentation is available online, in the tutorial introduction
   pub/xlispstat/xlispstat.doc.tar.Z and also in the book
      Luke Tierney, "Lisp-Stat: An Object Oriented Environment for Statistical
      Computing and Dynamic Graphics", Wiley, 1990, 397 pages.
      ISBN 0-471-50916-7.
   For more information, write to Lisp-Stat Information, School of
   Statistics, 270 Vincent Hall, University of Minnesota, Minneapolis, MN
   55455, or send e-mail to [e-mail].

   CLASP (Common Lisp Analytical Statistics Package) provides the basic
   functionality of a statistics package. It is implemented on top of
   CLOS and CLIM on a variety of platforms, and uses BBN's SciGraph
   package for plotting. The CLIM interface includes a "notebook" that is
   both a "desktop" for icons and a Lisp interactor pane.  The Common
   Lisp Instrumentation Package (CLIP) is available along with CLASP.
   CLIP is designed to allow AI system developers andevaluators a
   portable way to define and manage "alligator clips" for instrumenting
   their programs.  CLIP produces data about program behavior in CLASP
   format, as well as other commonly used data formats.  It currently has
   facilities to support experiment design, such as scenario scripting
   and factorial combination of independent variables, and can collect
   data in summary form (at the end of each trial) or based upon the
   occurrence of specific events (both periodic and non-periodic).  CLASP
   is available by anonymous ftp from
      ftp.cs.umass.edu:/pub/eksl/clasp/
   and CLIP is in the directory
      ftp.cs.umass.edu:/pub/eksl/clip/
   A tutorial on CLASP can be found in
      ftp.cs.umass.edu:/pub/eksl/clasp-tutorial/
   Bugs should be reported to [e-mail]. For more
   information, contact Dave Hart <[e-mail]>.

   IDEAL is a LISP system developed for building and evaluating influence
   diagrams and Bayesian networks.  It is accompanied with a graphical
   user interface (CLIM-based) for constructing, editing, and solving
   belief networks and influence diagrams. For more information, write
   to [e-mail].

Planning:

   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
   [e-mail]. User's group is [e-mail].
   The authors request that anybody ftping the code send a message to
   [e-mail], 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, [e-mail].

   ABTWEAK is a complete hierarchical, non-linear planner that extends
   David Chapman's (MIT 1986) TWEAK planner as described by
   Yang (Waterloo) and Tenenberg (Rochester) in 1989.  This implementation
   includes a complete search strategy suited to abstraction hierarchies
   known as LEFT-WEDGE (Woods 1991). This planner and related work
   predates that of SNLP. ABTWEAK is available by anonymous ftp from
      logos.uwaterloo.ca:/pub/abtweak/Abtweak.tar.Z
   For more information, send mail to Qiang Yang <[e-mail]>.
   Also, source, all related papers, and manuals are available via WWW
   at the home page of Steve Woods <[e-mail]>,
   on URL http://logos.uwaterloo.ca/students/sgwoods/sgwoods.html, or via the
   Logic Programming and Artificial Intelligence Group (LPAIG) page
   on URL http://logos.uwaterloo.ca/.

   RHETORICAL is a planning and knowledge tool available by
   anonymous ftp from ftp.cs.rochester.edu:/pub/packages/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 <[e-mail]>.

   PRODIGY is an integrated planning and learning system,
   available free after signing a license agreement. Contact
   [e-mail] 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
   Southern 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 [e-mail] 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 [e-mail] or to the physical address above.

   A simple route planning agent implemented in Soar6 is available by
   anonymous ftp from
      earth.med.ohio-state.edu:/pub/IEEE-Soar-code/route-planning.soar6.
   This is the complete code for the agent described in the IEEE Expert
   article: Smith, J. W. and Johnson, T. R., "A stratified approach to
   specifying, designing, and building knowledge systems", IEEE Expert,
   8(3):15-25, 1993.

   SNLP is a domain independent systematic nonlinear planner,
   available by anonymous ftp from cs.washington.edu:/pub/snlp.tar.Z
   Contact [e-mail] for more information.

   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 [e-mail].

Planning Testbeds:

   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. Contact [e-mail] for more
   information.

   TRUCKWORLD is a simulated world intended to provide a
   testbed for AI planning programs, where the planning agent
   is a truck with arms that roams around the simulated world. It is
   available by anonymous ftp from
      cs.washington.edu:/pub/ai/truckworld.tar.Z
   It includes an X interface. Contact Steve Hanks <[e-mail]>
   for more information. Send mail to
      [e-mail]
   to be added to the mailing list.

   ARS MAGNA is a simulated world intended for use as a testbed for
   planning and mapping programs.  The simulated agent is a robot in an
   indoors environment.  High-level sensing and action are provided,
   realistically modelled on current vision and robotics research.  It is
   written in Nisp, a macro package running on top of Common Lisp.  It is
   available by anonymous ftp from
      dept.cs.yale.edu:/pub/nisp/
   as file ars-magna.tar.Z.  It includes an X display.  Contact Sean Engelson
   <[e-mail]> for more information.

Qualitative Reasoning:

   QSIM is a qualitative reasoning system implemented in Common
   Lisp. It is available by anonymous ftp from cs.utexas.edu:/pub/qsim
   Contact Ben Kuipers <[e-mail]> for more information.

   QPE is the Qualitative Process Engine, an envisioner for QP theory.
   QPE is publically available from multivac.ils.nwu.edu:/pub/QPE
   Maintained by Ken Forbus <[e-mail]>.

Theorem Proving:

   MVL (Multi-Valued Logic) is a theorem proving system written in Common
   Lisp. MVL is a bilattice-based reasoning system.  By changing the
   bilattice, you can use MVL to do truth maintenance, nonmonotonic
   reasoning, first-order reasoning, and a variety of other reasoning
   strategies.  MVL is available by anonymous ftp from
      t.uoregon.edu:/mvl/mvl.tar.Z [128.223.56.46]
   as mvl.tar.Z. A user's manual may be found in the file manual.tex. For
   more information, contact Matthew L. Ginsberg, <[e-mail]>
   or <[e-mail]>. Matthew asks that you send him an email
   message if you retrieve the system by anonymous ftp.

   Boyer-Moore
   ftp.cli.com:/pub/nqthm/nqthm.tar.Z   Contact: [e-mail]
   rascal.ics.utexas.edu:/pub/             128.83.138.20
      nqthm/               Boyer and Moore's theorem prover.
                           Also available from ftp.cli.com:/pub/nqthm.
      proof-checker/       Matt Kaufmann's proof checking
                           enhancements to nqthm.
   The mailing list [e-mail] is for users of the
   Boyer-Moore theorem-prover, NQTHM.

   DTP is a general first-order theorem prover incorporating domain-independent
   control of inference (including intelligent backtracking and subgoal
   caching).  Implemented in CLtL2 Common Lisp, it runs in Franz Allegro,
   Lucid, and Macintosh (MCL) Common Lisp.  DTP is available on the Web at
      http://meta.stanford.edu/dtp/
   or by anonymous ftp from
      meta.stanford.edu:/pub/dtp/ [36.8.0.54]
   Contact Don Geddis <[e-mail]> for more information.

   RRL (Rewrite Rule Laboratory) -- herky.cs.uiowa.edu:/public/rrl
   [128.255.28.100]

   FRAPPS (Framework for Resolution-based Automated Proof Procedures) is
   a portable resolution theorem-prover written in Common Lisp. It is
   available via anonymous ftp from a.cs.uiuc.edu:/pub/frapps [128.174.252.1].
   If you take a copy of FRAPPS, please send a short note to Prof.
   Alan M. Frisch <[e-mail]>.

Truth Maintenance:

   The truth maintenance system and problem solver implementations
   described in the book "Building Problem Solvers" by Ken Forbus and
   Johan de Kleer are available by anonymous ftp from
   parcftp.xerox.com:/pub/bps/. Includes a constraint propagation
   system similar to Steele's Constraints system, among other things.
   For more information send mail to Johan de Kleer <[e-mail]>.

Virtual Reality:

   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:/public/veos/ [128.95.136.1]
   as veos.tar.Z. If you use the software, the authors ask that you send
   them mail to [e-mail].

Vision:

   OBVIUS -- white.stanford.edu:/obvius/ [36.121.0.16]
             whitechapel.media.mit.edu:/obvius/ [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 <[e-mail]> and Eero
   Simoncelli <[e-mail]>. Runs in Lucid-4.0. Includes
   LaTeX documentation and User's Guide.

Miscellaneous:

   ftp.csrl.aoyama.ac.jp:/YY/       YY window toolkit sources
   ftp.csrl.aoyama.ac.jp:/lispsrc/  Common Lisp programs, including MIT's FRL.

----------------------------------------------------------------
Subject: [6-6] Formatting code in LaTeX (WEB and other literate
               programming tools)

SLaTeX is a R4RS-compliant Scheme program that allows you to write
program code "as is" in your LaTeX or TeX source.  It is particularly
geared to the programming languages Scheme and Common Lisp, and has
been tested in Chez Scheme, Common Lisp, MIT C Scheme, Elk, Scheme->C,
SCM and UMB Scheme on Unix; and MIT C Scheme and SCM on MSDOS.  The
formatting of the code includes assigning appropriate fonts to the
various tokens in the code (keywords, variables, constants, data), at
the same time retaining the proper indentation when going to the
non-monospace (non-typewriter) provided by TeX.  SLaTeX comes with two
databases that recognize the standard keywords/variables/constants of
Scheme and Common Lisp respectively.  These can be modified by the
user using easy TeX commands.  In addition, the user can inform SLaTeX
to typeset arbitrary identifiers as specially suited TeX expressions
(i.e., beyond just fonting them).  The code-typesetting program SLaTeX
is available by anonymous ftp from
   cs.rice.edu:/public/dorai/slatex23.tar.gz
Send bug reports to [e-mail].

SchemeWEB provides simple support for literate programming in Lisp.
SchemeWEB version 2.0 is a Unix filter that allows you to generate
both Lisp and LaTeX code from one source file.  The generated LaTeX
code formats Lisp programs in typewriter font obeying the spacing in
the source file.  Comments can include arbitrary LaTeX commands.
SchemeWEB was originally developed for the Scheme dialect of Lisp, but
it can easily be used with most other dialects.  Version 2.0 is
available in the Scheme Repository as
   cs.indiana.edu:/pub/scheme-repository/new/schemeweb.sh
or in the Comprehensive TeX Archive Network (CTAN) in the directory
   ftp.shsu.edu:/tex-archive/web/schemeweb

LiSP2TeX is a system that allows easy insertions of Scheme, or Lisp,
code towards TeX files. The originality of LiSP2TeX is that it
extracts Scheme definitions from the files where they appear and wraps
them appropriately within TeX macros for insertion into the
documentation file. LiSP2TeX decorrelates writing documentation from
programming: it is therefore possible to separately develop programs
and documentations and to merge them at the end to produce up to date
final documents. LiSP2TeX also has some pretty-printing capabilities
to produce denotations full of greek letters. It is available by
anonymous ftp from ftp.inria.fr:/INRIA/Projects/icsla/.

See also ftp.cs.cmu.edu:/user/ai/lang/lisp/code/tools/user_man/.

The Literate Programming FAQ lists a number of alternatives, both
language-independent and Lisp-specific. The Literate Programming FAQ
is posted once a quarter to the comp.literate.programming newsgroup
and is available by anonymous ftp from rtfm.mit.edu. A copy may also be
requested by sending an email message to [e-mail]
   sendme litprog.faq
in the body of the message.

----------------------------------------------------------------
Subject: [6-7] Where can I get an implementation of Prolog in Lisp?

Implementations of Prolog in Lisp:

   The Frolic package from the University of Utah is written in Common Lisp
   and available by anonymous ftp from cs.utah.edu:/pub/frolic.tar.Z

   LM-PROLOG by Ken Kahn and Mats Carlsson is written in ZetaLisp and not
   easily portable to Common Lisp. It is available by anonymous ftp from
   sics.se:/archive/lm-prolog.tar.Z.

   Peter Norvig's book "Paradigms of AI Programming" includes Common Lisp
   implementations of a prolog interpreter and compiler. The software is
   available by anonymous ftp from unix.sri.com:/pub/norvig/ and on disk in
   Macintosh or DOS format from the publisher, Morgan Kaufmann.  For more
   information, contact: Morgan Kaufmann, Dept. P1, 2929 Campus Drive, Suite
   260, San Mateo CA 94403, [phone]; FAX: [phone]

   Harlequin's LispWorks comes with Common Prolog -- a fast
   Edinburgh-compatible Prolog integrated with Common Lisp.  Write to:
   Harlequin Limited, Barrington Hall, Barrington, Cambridge, CB2 5RG, call
   0223 872522 (or 44223 872522 outside UK), telex 818440 harlqn g, fax 0223
   872519, or send email to [e-mail] (or [e-mail] for US people).

   eLP (Ergo Lambda Prolog) is an interpreter written by Conal Elliott,
   Frank Pfenning and Dale Miller in Common Lisp and implements the core
   of lambda Prolog (higher-order hereditary Harrop formulas). It is
   embedded in a larger development environment called ESS (the Ergo
   Support System).  eLP implements all core language feature and offers
   a module system, I/O, some facilities for tracing, error handling,
   arithmetic, recursive top-levels, on-line documentation and a number
   of extended examples, including many programs from Amy Felty's and
   John Hannan's thesis.  It should run in Allegro Common Lisp, Lucid
   Common Lisp, Kyoto Common Lisp, CMU Common Lisp and Ibuki Common Lisp.
   The eLP implementation of lambda Prolog is no longer developed or
   maintained, but it is still available via anonymous ftp from
   ftp.cs.cmu.edu:/afs/cs.cmu.edu/project/ergo/export/ess/. The file
   ergolisp.tar.Z contains the Ergo project's extensions to Common Lisp,
   including some facilities for attributes and dealing with abstract
   syntax trees. The file sb.tar.Z contains the Ergo
   Parser/Unparser/Formatter generator and ab.tar.Z contains the Ergo
   Attribute Grammar facility. The file elp.tar.Z contains the Ergo
   implementation of lambda Prolog.  To customize grammars you need the
   sb.tar.Z file.  When you retrieve the system, please print, fill out,
   and send in a copy of the non-restrictive license you will find in the
   file LICENSE. To subscribe to the [e-mail] mailing list, send
   mail to [e-mail]. Bugs should be sent to
   [e-mail].

   The book "On Lisp" by Paul Graham includes an implementation of
   Prolog in Common Lisp. The code is available by anonymous ftp from
      endor.harvard.edu:/pub/onlisp
   and also in the CMU AI Repository as
      ftp.cs.cmu.edu:/user/ai/lang/lisp/bookcode/graham/

See the Scheme FAQ for information on implementations of Prolog in Scheme.

----------------------------------------------------------------
Subject: [6-8] World-Wide Web (WWW) Resources

The World Wide Web (WWW) is a hypermedia document that spans the
Internet.  It uses the http (HyperText Transfer Protocol) for the
light-weight exchange of files over the Internet.  NCSA Mosaic is a
World Wide Web browser developed at the National Center for
Supercomputing Applications (NCSA).

Mosaic's popularity derives, in part, from its ability to communicate
using more traditional Internet protocols like FTP, Gopher, WAIS, and
NNTP, in addition to http. Mosaic can display text, hypertext links,
and inlined graphics directly. When Mosaic encounters a file type it
can't handle internally, such as Postscript documents, mpeg movies,
sound files, and JPEG images, it uses an external viewer (or player)
like Ghostscript to handle the file. Mosaic also includes facilities
for exploring the Internet. In other words, Mosaic is an multimedia
interface to the Internet.

The hypertext documents viewed with Mosaic are written in HTML
(HyperText Markup Language), which is a subset of SGML (Standard
Generalized Markup Language).  All that is needed is just a few more
improvements, such as the ability to format tables and mathematics,
and a WYSIWYG editor, for HTML to greatly facilitate electronic
journals and other publications.

NCSA Mosaic for the X Window System is available by anonymous ftp from
   ftp.ncsa.uiuc.edu:/Mosaic/
as source code and binaries for Sun, SGI, IBM RS/6000, DEC Alpha OSF/1, DEC
Ultrix, and HP-UX. Questions about NCSA Mosaic should be directed to
[e-mail] (X-Windows version), [e-mail]
(Macintosh), and [e-mail] (Microsoft Windows).

A simple HTML version of the Lisp FAQ (this FAQ) is available as
   http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/lisp/top.html

Association of Lisp Users:
   http://www.cs.rochester.edu/u/miller/alu.html
   [Contains links to a lot of Lisp resources, including a history of
   Lisp, bibliographies of Lisp books, the Lisp Repository at CMU, and
   even some Lisp humor. Very nicely done.]
   Contact: Brad Miller <[e-mail]>

----------------------------------------------------------------
;;; *EOF*

Archive-name: lisp-faq/part7
Last-Modified: Fri Mar 10 17:09:15 1995 by Mark Kantrowitz
Version: 1.51
Maintainer: Mark Kantrowitz and Barry Margolin <[e-mail]>
URL: http://www.cs.cmu.edu:8001/Web/Groups/AI/html/faqs/lang/lisp/top.html
Size: 16790 bytes, 295 lines

;;; ****************************************************************
;;; Lisp Window Systems and GUIs ***********************************
;;; ****************************************************************
;;; Written by Mark Kantrowitz and Barry Margolin
;;; lisp_7.faq

This post contains Part 7 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 [e-mail].

Topics Covered (Part 7):

  [7-1] How can I use the X Window System or other GUIs from Lisp?
  [7-2] What Graphers/Browsers are available?

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

----------------------------------------------------------------
Subject: [7-1] 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-7].
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 by anonymous ftp from
   ftp.x.org:/contrib/ as the files CLX.Manual.tar.Z and CLX.R5.02.tar.Z.
   [Note: The new version of CLX for X11R6 can be found (untarred) in
   ftp.x.org:/pub/R6untarred/contrib/lib/CLX/ and includes some slight
   modifications for CLtL2 compatability. You can get it in tarred form
   from the CMU AI Repository, Lisp section.]
   Primary Interface Author: Robert W. Scheifler <[e-mail]>
   Send bug reports to [e-mail].
   The 232 page manual is available in /pub/R5untarred/mit/hardcopy/CLX
   (PostScript format) and /pub/R5untarred/mit/doc/CLX (Interleaf source).

   CLIM (Common Lisp Interface Manager) is a portable, graphical user
   interface toolkit originally developed by International Lisp
   Associates, Symbolics, and Xerox PARC, and now under joint development
   by several Lisp vendors, including Symbolics, Franz, Lucid, Illudium,
   and Harlequin.  It is intended to be a portable successor of Symbolics
   UIMS (Dynamic Windows, Presentations Types).  CLIM 2.0 also supports
   more traditional toolkit-style programming.  It runs on Symbolics Lisp
   Machines; Allegro, Lucid, and Harlequin 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 Illudium:
     Contact: Dennis Doughty - [e-mail]
     or contact: Bill York - [e-mail]
   Illidium has signed a distribution agreement for MCL CLIM with
   Lucid. [Contact Harlequin for information about Lucid.]
   CLIM includes a general purpose grapher. The CLIM 2.0 SPECIFICATION
   is available by anonymous ftp from ftp.uu.net:/vendor/franz/clim/clim.ps.Z.
   To be added to the mailing list send mail to [e-mail].

   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 [e-mail].

   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 [e-mail] for more information.
   [Intellicorp's KEE4.0 comes with Common Windows also. They've
    implemented the CW spec to run on Lucid 4.0 on Sparcs, HP300/400s,
    HP700/800s, and IBM RS6000s. Contact [e-mail] 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: [e-mail]

   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, CMU CL, Lucid
   CL, and Symbolics Genera. GINA uses CLOS.  Available free in the X
   contrib directory or by anonymous ftp from either
      ftp.x.org:/contrib (formerly export.lcs.mit.edu) or
      ftp.gmd.de:/gmd/gina [129.26.8.84]
   as the files CLM+GINA.README, CLM2.2.tar.Z and GINA2.2.tar.Z.  CLM was
   written by Andreas Baecker <[e-mail]>, GINA by Mike Spenke
   <[e-mail]>, and IB by Thomas Berlage <[e-mail]>.
   Contact Mike Spenke for more info. To be added to the mailing list,
   send a message to [e-mail].

   EW (Express Windows) is intended to mimic Symbolics' Dynamic Windows user
   and programmer interfaces. It is available free in the Common Lisp
   Repository as
      ftp.cs.cmu.edu:/user/ai/lang/lisp/gui/ew/
   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 <[e-mail]>.

   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 as
      a.gp.cs.cmu.edu:/usr/garnet/garnet/README [128.2.242.7]
   Garnet includes the Lapidiary interactive design tool, C32 constraint
   editor, spreadsheet object, 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 ([e-mail]) for more
   information. Bug reports should be sent to [e-mail].
   Administrative questions should be sent to [e-mail] or
   [e-mail]. Garnet is discussed on the newsgroup
   comp.windows.garnet (which is gatewayed to [e-mail] for
   those without access to netnews).

   LISP2WISH is a very simple demonstration of how to connect and
   communicate SYNCHRONOUSLY between a lisp process and a C process
   running a Tcl/Tk executable.  The demo uses the vanilla 'wish'
   executable that is included with the Tcl/Tk distribution.  Tcl/Tk is a
   very flexible system for building Graphical User Interfaces (GUIs),
   with the look-and-feel of Motif.  One writes scripts in a high-level,
   C-like language, and an interpreter evaluates the commands and passes
   execution either to a built-in function (and there are many), or to
   your own C routines.  Tcl/Tk is becoming increasingly popular because
   of its ease of use, and because it is freely distributable (even
   commercially, I believe).  For more information on Tcl/Tk, look on the
   USENET newsgroup comp.lang.tcl, or get the distribution from the
   archive (listed below) or ftp.cs.berkeley.edu.  The Tcl/Tk archive
   also has many user-contributed extensions which make Tcl/Tk even more
   desirable.  Tcl/Tk was originally written by Dr. John Ousterhout, at
   Berkeley.  LISP2WISH lets you make a window/menu/drawing interface for
   your lisp routines, where you can take advantage of all the stuff
   written for Tcl/Tk (and build your own!).
   LISP2WISH has only been tested under X-Windows and Lucid Common Lisp
   4.0 and 4.1, but should work on other platforms that support Lucid
   (or Allegro) and Tcl/Tk.  LISP2WISH is available at the Tcl/Tk archive
      harbor.ecn.purdue.edu:/pub/tcl/lisp2wish6.tar.gz,
   from the author through the WWW at the URL
      http://www.cis.upenn.edu/~kaye/home.html
   by anonymous ftp from
      ftp.cis.upenn.edu:/pub/kaye/lisp2wish6.tar.Z
   or in the GUI section of the Lisp Repository as
      ftp.cs.cmu.edu:/user/ai/lang/lisp/gui/lsp2wish/lsp2wish.tgz
   For more information, contact Jonathan Kaye <[e-mail]>.

   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
      ftp.x.org:/contrib/lispview1.1 (formerly export.lcs.mit.edu) and
      xview.ucdavis.edu:/pub/XView/LispView1.1
   Includes a general-purpose 2D grapher library.
   Written by Hans Muller ([e-mail]). Runs in Sun CL and Lucid CL.
   Direct questions about the source provision to [e-mail].

   WINTERP (Widget INTERPreter) is an application development environment
   developed at HP. It enables the rapid prototyping of graphical
   user-interfaces through direct manipulation of user interface objects
   and their attached actions.  WINTERP provides an interface to the X11
   toolkit (Xt) and the OSF/Motif widget set and a built-in RPC mechanism
   for inter-application communication.  It includes an object-oriented
   2.5D graphics and animation widget based on the Xtango path transition
   animation system, the XmGraph graph browser (with graph nodes as
   arbitrary WINTERP widgets), and GIF image support.  The interpreter is
   based on David Betz's XLISP interpreter, which implements a small
   subset of Common Lisp and runs on PCs, IBM RS/6000, Decstation 3100s,
   HP9000s, Sun3, Sparcs, SGI, and NeXT.  XLISP provides a simple
   Smalltalk-like object system, with OSF/Motif widgets as real XLISP
   objects -- they can be specialized via subclassing, methods added
   or altered, etc. WINTERP includes an interface to GNU-Emacs which
   allows code to be developed and tested without leaving the editor.
   WINTERP is a free-standing Lisp-based tool for setting up window
   applications. WINTERP is available free in X contrib directory, or
   by anonymous ftp from
      ftp.x.org:/contrib/devel_tools/
   as winterp-???.tar.gz (formerly export.lcs.mit.edu) where ??? is the
   version number. The current version is 2.03 (X11r6 support).  If you
   do not have Internet access you may request the source code to be
   mailed to you by sending a message to [e-mail].
   The WWW home page for WINTERP is accessible via the URL
       http://www.eit.com/software/winterp/winterp.html
   or mirrored on
       file://ftp.x.org/contrib/devel_tools/winterp.html
   Contact Niels Mayer <[e-mail]> for more information. To be
   added to the mailing list, send mail to [e-mail].

   Xgcl provides an interface to X Windows for GCL (GNU Common Lisp),
   formerly Austin Kyoto Common Lisp (AKCL). It includes a low-level
   interface to the Xlib routines, and an interface that provides
   graphics, menus, and mouse interaction via functions that are called
   from Lisp. Xgcl is built on top of GCL, and it is somewhat larger
   (e.g. 6.7 MB for Xgcl vs. 4.9 MB for GCL) because it incorporates
   Xlib.  To make Xgcl, you must first obtain and make GCL.  The code
   was written by Gordon Novak, Hiep Nguyen, and William Schelter. Xgcl
   is available by anonymous FTP from
       math.utexas.edu:/pub/gcl/
       ftp.cli.com:/pub/gcl/
       ftp.cs.utexas.edu:/pub/novak/xgcl/
   and on the Web from
       http://www.cs.utexas.edu/users/novak
   as the file xgcl-2.tgz. To use, put the xgcl-2.tgz file in the same
   directory as gcl-1.1.tgz and uncompress it with
       gzip -dc xgcl-2.tgz | tar xvf -
   Then see the README in the directory xgcl-2. For more information,
   write to Gordon Shaw Novak, Jr. <[e-mail]>.

   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 <[e-mail]>

   Picasso is a CLOS based GUI, and is available from
      postgres.berkeley.edu:/pub/Picasso-2.0
      toe.cs.berkeley.edu:/pub/picasso/
   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 [e-mail] for
   more information. [Picasso is no longer an actively supported system.]

   XIT (X User Interface Toolkit) is an object-oriented user interface
   development environment 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 ([e-mail]) as a framework for
   Common Lisp/CLOS applications with graphical user interfaces for the X
   Window System.  XIT contains user interface toolkits, including
   general building blocks and mechanisms for building arbitrary user
   interface elements and a set of predefined common elements (widgets),
   as well as high-level interactive tools for constructing, inspecting,
   and modifying user interfaces by means of direct manipulation.
   Although the system kernel is quite stable, XIT is still under active
   development.  XIT can be obtained free by anonymous ftp from
   ftp.informatik.uni-stuttgart.de:/pub/xit/ [129.69.211.2]

----------------------------------------------------------------
Subject: [7-2] What Graphers/Browsers are available?

Most of the graphics toolkits listed above include graphers. In
particular, CLIM, LispWorks, Garnet, and Lispview all include
graphers. The ISI grapher used to be in fairly widely used, but the
CLIM grapher seems to be overtaking it in popularity.

A simple grapher like the one described in "Lisp Lore" by Bromeley and
Lamson is available by anonymous ftp from
   ftp.csrl.aoyama.ac.jp:/graphers/
as the file graphers.tar.Z.uu. It includes versions for CLX, Express
Windows, NCW, CLUE, CLM/GINA, Common Windows, LispView, Winterp, CLIM
and YY. Several implementations have a mouse sensitivity feature and
others have implementation-specific features.  A copy has been made
available from the Lisp Utilities Repository. For further information,
contact Masayuki Ida <[e-mail]>.

----------------------------------------------------------------
;;; *EOF*