home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / lisp-faq / part1 next >
Encoding:
Internet Message Format  |  1997-08-13  |  78.2 KB

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!uwm.edu!vixen.cso.uiuc.edu!news-peer.sprintlink.net!news.sprintlink.net!Sprint!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!infeed2.internetmci.com!newsfeed.internetmci.com!nntp.info.ucla.edu!nntp.club.cc.cmu.edu!cantaloupe.srv.cs.cmu.edu!mkant
  2. From: mkant+@cs.cmu.edu (Mark Kantrowitz)
  3. Newsgroups: comp.lang.lisp,news.answers,comp.answers
  4. Subject: FAQ: Lisp Frequently Asked Questions 1/7 [Monthly posting]
  5. Supersedes: <LISP_1_868777228@CS.CMU.EDU>
  6. Followup-To: poster
  7. Date: 13 Aug 1997 07:01:12 GMT
  8. Organization: Carnegie-Mellon University, School of Computer Science
  9. Lines: 1637
  10. Approved: news-answers-request@MIT.Edu
  11. Distribution: world
  12. Expires: 24 Sep 1997 07:00:20 GMT
  13. Message-ID: <LISP_1_871455620@CS.CMU.EDU>
  14. Reply-To: ai+lisp-faq@cs.cmu.edu
  15. NNTP-Posting-Host: glinda.oz.cs.cmu.edu
  16. Summary: Introductory Matter and Bibliography of Introductions and References
  17. Xref: senator-bedfellow.mit.edu comp.lang.lisp:28922 news.answers:109632 comp.answers:27540
  18.  
  19. Archive-name: lisp-faq/part1
  20. Last-Modified: Fri Mar 14 11:41:55 1997 by Mark Kantrowitz
  21. Version: 1.65
  22. Maintainer: Mark Kantrowitz and Barry Margolin <ai+lisp-faq@cs.cmu.edu>
  23. URL: http://www.cs.cmu.edu/Web/Groups/AI/html/faqs/lang/lisp/top.html
  24. Size: 79328 bytes, 1645 lines
  25.  
  26. ;;; ****************************************************************
  27. ;;; Answers to Frequently Asked Questions about Lisp ***************
  28. ;;; ****************************************************************
  29. ;;; Written by Mark Kantrowitz and Barry Margolin
  30. ;;; lisp_1.faq 
  31.  
  32. This post contains Part 1 of the Lisp FAQ.
  33.  
  34. If you think of questions that are appropriate for this FAQ, or would
  35. like to improve an answer, please send email to us at ai+lisp-faq@cs.cmu.edu.
  36.  
  37. Note that the lisp-faq mailing list is for discussion of the content
  38. of the FAQ posting only.  It is not the place to ask questions about Lisp;
  39. use either the common-lisp@ai.sri.com mailing list or the
  40. comp.lang.lisp newsgroup for that.  If a question appears frequently
  41. in one of those forums, it will get added to the FAQ list.
  42.  
  43. *** Copyright:
  44.  
  45. Copyright (c) 1992-94 by Mark Kantrowitz and Barry Margolin. 
  46. All rights reserved. 
  47.  
  48. This FAQ may be freely redistributed in its entirety without
  49. modification provided that this copyright notice is not removed.  It
  50. may not be sold for profit or incorporated in commercial documents
  51. (e.g., published for sale on CD-ROM, floppy disks, books, magazines,
  52. or other print form) without the prior written permission of the
  53. copyright holder.  Permission is expressly granted for this document
  54. to be made available for file transfer from installations offering
  55. unrestricted anonymous file transfer on the Internet.
  56.  
  57. If this FAQ is reproduced in offline media (e.g., CD-ROM, print form,
  58. etc.), a complimentary copy should be sent to Mark Kantrowitz, School
  59. of Computer Science, Carnegie Mellon University, 5000 Forbes Avenue,
  60. Pittsburgh, PA 15213-3891 USA.
  61.  
  62. This article is provided AS IS without any express or implied warranty.
  63.  
  64. *** Recent Changes:
  65.  
  66. ;;; 1.54:
  67. ;;;  8-MAR-95 mk    Removed the CORBA entry from part 5 of the FAQ, since
  68. ;;;                 Donald Vines is no longer at NEC. Thus there's nobody at
  69. ;;;                 NEC to provide support for the CLOS binding.
  70. ;;; 10-MAR-95 mk    Added Xgcl entry to part 7.
  71. ;;;
  72. ;;; 1.55:
  73. ;;; 13-MAR-95 mk    Added 800 number for Blackboard Technology Group.
  74. ;;;
  75. ;;; 1.56:
  76. ;;; 14-APR-95 mk    Updated DTP entry.
  77. ;;;
  78. ;;; 1.57:
  79. ;;;  1-MAY-95 mk    Added environment variable access to [2-11].
  80. ;;;
  81. ;;; 1.58:
  82. ;;; 29-AUG-95 mk    Added entry on CL-Grasper, the SRI Grapher, to [7-2].
  83. ;;;
  84. ;;; 1.59:
  85. ;;; 13-SEP-95 mk    Updated WOOD entry.
  86. ;;;
  87. ;;; 1.60:
  88. ;;;  9-NOV-95 mk    Updated info on ISO Lisp in [4-10].
  89. ;;; 14-NOV-95 mk    Updated Allegro CL entry, and added entry on Allegro CL 3.0
  90. ;;;                 Web Version for Windows to [4-0].
  91. ;;; 20-FEB-96 mk    ftp.uu.net:/vendor/franz/ --> ftp.franz.com:/pub/
  92. ;;;  1-MAY-96 mk    Updated MCL entry in part 4.
  93. ;;; 14-MAR-97 mk    Updated MCL information.
  94.  
  95. *** Topics Covered:
  96.  
  97. There are currently seven parts to the Lisp FAQ:
  98.  
  99.    1. Introductory Matter and Bibliography of Introductions and References
  100.    2. General Questions
  101.    3. Common Programming Pitfalls
  102.    4. Lisp Implementations and Mailing Lists
  103.    5. Object-oriented Programming in Lisp
  104.    6. FTP Archives and Resources
  105.    7. Lisp Window Systems and GUIs
  106.  
  107. All parts are posted to comp.lang.lisp. Part 5 is cross-posted to the
  108. comp.lang.clos newsgroup.  
  109.  
  110. Topics Covered (Part 1):
  111.  
  112.   [1-0]   What is the purpose of this newsgroup?
  113.   [1-1]   What is the difference between Scheme and Common Lisp?
  114.   [1-2]   Lisp books, introductions, documentation, periodicals,
  115.           journals, and conference proceedings. 
  116.   [1-3]   How can I improve my Lisp programming style and coding efficiency?
  117.   [1-4]   Where can I learn about implementing Lisp interpreters and compilers?
  118.   [1-5]   What is the "minimal" set of primitives needed for a Lisp
  119.           interpreter? 
  120.   [1-6]   What does CLOS, PCL, X3J13, CAR, CDR, ... mean? 
  121.   [1-7]   Lisp Job Postings
  122.  
  123. Topics Covered (Part 2):
  124.  
  125.   [2-1]   Is there a GNU-Emacs interface to Lisp?
  126.   [2-2]   When should I use a hash table instead of an association list?
  127.   [2-3]   What is the equivalent of EXPLODE and IMPLODE in Common Lisp?
  128.   [2-4]   Is Lisp inherently slower than more conventional languages such as C?
  129.   [2-5]   Why does Common Lisp have "#'"?
  130.   [2-6]   How do I call non-Lisp functions from Lisp?
  131.   [2-7]   Can I call Lisp functions from other languages?
  132.   [2-8]   I want to call a function in a package that might not exist at
  133.           compile time. How do I do this?  
  134.   [2-9]   What is CDR-coding?
  135.   [2-10]  What is garbage collection?
  136.   [2-11]  How do I save an executable image of my loaded Lisp system?
  137.           How do I run a Unix command in my Lisp? How do I exit Lisp?
  138.           Access environment variables?
  139.   [2-12]  I'm porting some code from a Symbolics Lisp machine to some
  140.           other platform, and there are strange characters in the code.
  141.           What do they mean?  
  142.   [2-13]  History: Where did Lisp come from?
  143.   [2-14]  How do I find the argument list of a function?
  144.           How do I get the function name from a function object?
  145.   [2-15]  How can I have two Lisp processes communicate via unix sockets?
  146.   [2-16]  How can I create a stream that acts like UNIX's /dev/null
  147.           (i.e., gobbles any output and immediately signals EOF on
  148.           input operations)?
  149.   [2-17]  Read-time conditionalization of code (#+ #- and *features*)
  150.   [2-18]  What reader macro characters are used in major Lisp systems?
  151.   [2-19]  How do I determine if a file is a directory or not? 
  152.           How do I get the current directory name from within a Lisp 
  153.           program? Is there any way to create a directory?
  154.   [2-20]  What is a "Lisp Machine" (LISPM)?
  155.   [2-21]  How do I tell if a symbol names a function and not a macro?
  156.  
  157. Common Pitfalls (Part 3):
  158.  
  159.   [3-0]  Why does (READ-FROM-STRING "foobar" :START 3) return FOOBAR
  160.          instead of BAR?  
  161.   [3-1]  Why can't it deduce from (READ-FROM-STRING "foobar" :START 3)
  162.          that the intent is to specify the START keyword parameter
  163.          rather than the EOF-ERROR-P and EOF-VALUE optional parameters?   
  164.   [3-2]  Why can't I apply #'AND and #'OR?
  165.   [3-3]  I used a destructive function (e.g. DELETE, SORT), but it
  166.          didn't seem to work.  Why? 
  167.   [3-4]  After I NREVERSE a list, it's only one element long.  After I
  168.          SORT a list, it's missing things.  What happened? 
  169.   [3-5]  Why does (READ-LINE) return "" immediately instead of waiting
  170.          for me to type a line?  
  171.   [3-6]  I typed a form to the read-eval-print loop, but nothing happened. Why?
  172.   [3-7]  DEFMACRO doesn't seem to work.
  173.          When I compile my file, LISP warns me that my macros are undefined
  174.          functions, or complains "Attempt to call <function> which is 
  175.          defined as a macro.
  176.   [3-8]  Name conflict errors are driving me crazy! (EXPORT, packages)
  177.   [3-9]  Closures don't seem to work properly when referring to the
  178.          iteration variable in DOLIST, DOTIMES, DO and LOOP.
  179.   [3-10] What is the difference between FUNCALL and APPLY?
  180.   [3-11] Miscellaneous things to consider when debugging code.
  181.   [3-12] When is it right to use EVAL?
  182.   [3-13] Why does my program's behavior change each time I use it?
  183.   [3-14] When producing formatted output in Lisp, where should you put the
  184.          newlines (e.g., before or after the line, FRESH-LINE vs TERPRI,
  185.          ~& vs ~% in FORMAT)?
  186.   [3-15] I'm using DO to do some iteration, but it doesn't terminate. 
  187.   [3-16] My program works when interpreted but not when compiled!
  188.  
  189. Lisp Implementations and Mailing Lists (Part 4):
  190.  
  191.   [4-0]   Free Common Lisp implementations.
  192.   [4-1]   Commercial Common Lisp implementations.
  193.   [4-1a]  Lisp-to-C translators
  194.   [4-2]   Scheme Implementations
  195.   [4-4]   Free Implementations of Other Lisp Dialects
  196.   [4-5]   Commercial Implementations of Other Lisp Dialects
  197.   [4-6]   What is Dylan?
  198.   [4-7]   What is Pearl Common Lisp?
  199.   [4-9]   What Lisp-related discussion groups and mailing lists exist?
  200.   [4-10]  Where can I get a copy of the ANSI Common Lisp standard?
  201.           What is ISO Lisp?
  202.  
  203. Object-oriented Programming in Lisp (Part 5):
  204.  
  205.   [5-0]   What is CLOS (PCL) and where can I get it?
  206.           How do you pronounce CLOS? What is the Meta-Object Protocol (MOP)?
  207.   [5-1]   What documentation is available about object-oriented
  208.           programming in Lisp?  
  209.   [5-2]   How do I write a function that can access defstruct slots by
  210.           name?  I would like to write something like 
  211.           (STRUCTURE-SLOT <object> '<slot-name>).   
  212.   [5-3]   How can I list all the CLOS instances in a class?
  213.   [5-4]   How can I store data and CLOS instances (with possibly circular
  214.           references) on disk so that they may be retrieved at some later
  215.           time? (Persistent Object Storage)
  216.   [5-5]   Given the name of a class, how can I get the names of its slots?
  217.   [5-6]   Free CLOS software.
  218.   [5-7]   Common CLOS Blunders
  219.  
  220. FTP Resources (Part 6):
  221.  
  222.   [6-0] General information about FTP Resources for Lisp
  223.   [6-1] Repositories of Lisp Software
  224.   [6-3] Publicly Redistributable Lisp Software
  225.   [6-6] Formatting code in LaTeX (WEB and other literate programming tools)
  226.   [6-7] Where can I get an implementation of Prolog in Lisp?
  227.   [6-8] World-Wide Web (WWW) Resources
  228.  
  229. Lisp Window Systems and GUIs (Part 7):
  230.   [7-1] How can I use the X Window System or other GUIs from Lisp?
  231.   [7-2] What Graphers/Browsers are available?
  232.  
  233. Search for \[#\] to get to question number # quickly.
  234.  
  235. *** Introduction:
  236.  
  237. Certain questions and topics come up frequently in the various network
  238. discussion groups devoted to and related to Lisp.  This file/article is
  239. an attempt to gather these questions and their answers into a convenient
  240. reference for Lisp programmers.  It (or a reference to it) is posted
  241. periodically.  The hope is that this will cut down on the user time and
  242. network bandwidth used to post, read and respond to the same questions
  243. over and over, as well as providing education by answering questions
  244. some readers may not even have thought to ask.
  245.  
  246. This is not a Lisp tutorial, nor is it an exhaustive list of all Lisp
  247. intricacies.  Lisp is a very powerful and expressive language, but with
  248. that power comes many complexities.  This list attempts to address the
  249. ones that average Lisp programmers are likely to encounter.  If you are
  250. new to Lisp, see the answer to the question "How can I learn Lisp?".
  251.  
  252. The latest version of this FAQ is available via anonymous FTP from CMU:
  253.  
  254.    To obtain the files from CMU, connect by anonymous FTP to 
  255.       ftp.cs.cmu.edu:/user/ai/pubs/faqs/lisp/  [128.2.206.173]
  256.    using username "anonymous" and password "name@host" (substitute your
  257.    email address) or via AFS in the Andrew File System directory
  258.       /afs/cs.cmu.edu/project/ai-repository/ai/pubs/faqs/lisp/
  259.    and get the files lisp_1.faq, lisp_2.faq, lisp_3.faq, lisp_4.faq,
  260.    lisp_5.faq, lisp_6.faq and lisp_7.faq.
  261.  
  262. You can also obtain a copy of the FAQ by sending a message to
  263. ai+query@cs.cmu.edu with 
  264.    Send Lisp FAQ
  265. in the message body.
  266.  
  267. The FAQ postings are also archived in the periodic posting archive on
  268.    rtfm.mit.edu:/pub/usenet/news.answers/lisp-faq/ [18.181.0.24]
  269. If you do not have anonymous ftp access, you can access the archive by
  270. mail server as well.  Send an E-mail message to
  271. mail-server@rtfm.mit.edu with "help" and "index" in the body on
  272. separate lines for more information.
  273.  
  274. An automatically generated HTML version of the Lisp FAQ is accessible by
  275. WWW as part of the AI-related FAQs Mosaic page. The URL for this
  276. resource is
  277.    http://www.cs.cmu.edu/Web/Groups/AI/html/faqs/top.html
  278. The direct URL for the Lisp FAQ is
  279.    http://www.cs.cmu.edu/Web/Groups/AI/html/faqs/lang/lisp/top.html
  280.  
  281. Unless otherwise specified, the Lisp dialect referred to is Common Lisp,
  282. as defined by "Common Lisp: the Language" (aka "CLtL1") as well as
  283. corrections (but not enhancements) from "Common Lisp: the Language, 2nd
  284. Edition" (aka "CLtL2"), both by Guy L. Steele, Jr. and published by
  285. Digital Press. Note that CLtL2 is NOT an official specification for
  286. the language; ANSI Committee X3J13 is preparing such a specification.
  287. See question [4-10] for information on the status of the ANSI
  288. specification for Common Lisp. Enhancements such as CLOS, conditions,
  289. and the LOOP macro will be referred to separately.
  290.  
  291. If you need to cite the FAQ for some reason, use the following format:
  292.    Mark Kantrowitz and Barry Margolin, "Answers to Frequently Asked
  293.    Questions about Lisp", comp.lang.lisp, <month>, <year>,
  294.    ftp.cs.cmu.edu:/user/ai/pubs/faqs/lisp/lisp_?.faq, ai+lisp-faq@cs.cmu.edu.
  295.  
  296. ----------------------------------------------------------------
  297. Subject: [1-0] What is the purpose of this newsgroup?
  298.  
  299. The newsgroup comp.lang.lisp exists for general discussion of
  300. topics related to the programming language Lisp. For example, possible
  301. topics can include (but are not necessarily limited to):
  302.    announcements of Lisp books and products
  303.    discussion of programs and utilities written in Lisp
  304.    discussion of portability issues
  305.    questions about possible bugs in Lisp implementations
  306.    problems porting an implementation to some architecture
  307. Postings should be of general interest to the Lisp community. See also
  308. question [4-9]. Postings asking for solutions to homework problems are
  309. inappropriate. 
  310.  
  311. The comp.lang.lisp newsgroup is archived in
  312.    ftp.cs.cmu.edu:/user/ai/pubs/news/comp.lang.lisp/
  313. on a weekly basis.
  314.  
  315. Every so often, somebody posts an inflammatory message, such as
  316.    My programming language is better than yours (Lisp vs. C/Prolog/Scheme). 
  317.    Loop (or Series) should/shouldn't be part of the language.
  318. These "religious" issues serve no real purpose other than to waste
  319. bandwidth. If you feel the urge to respond to such a post, please do
  320. so through a private e-mail message. 
  321.  
  322. Questions about object oriented programming in Lisp should be directed
  323. to the newsgroup comp.lang.clos. Similarly, questions about the
  324. programming language Scheme should be directed to the newsgroup
  325. comp.lang.scheme. Discussion of functional programming language issues
  326. should be directed to the newsgroup comp.lang.functional. Discussion
  327. of AI programs implemented in Lisp should sometimes be cross-posted to
  328. the newsgroup comp.ai.
  329.  
  330. ----------------------------------------------------------------
  331. Subject: [1-1] What is the difference between Scheme and Common Lisp?
  332.  
  333. Scheme is a dialect of Lisp that stresses conceptual elegance and
  334. simplicity. It is specified in R4RS and IEEE standard P1178. (See
  335. the Scheme FAQ for details on standards for Scheme.) Scheme is much
  336. smaller than Common Lisp; the specification is about 50 pages,
  337. compared to Common Lisp's 1300 page draft standard. (See question
  338. [4-10] for details on standards for Common Lisp.) Advocates of Scheme
  339. often find it amusing that the Scheme standard is shorter than the
  340. index to CLtL2. 
  341.  
  342. Scheme is often used in computer science curricula and programming
  343. language research, due to its ability to represent many programming
  344. abstractions with its simple primitives. Common Lisp is often used for
  345. real world programming because of its large library of utility
  346. functions, a standard object-oriented programming facility (CLOS), and
  347. a sophisticated condition handling system.
  348.  
  349. See the Scheme FAQ for information about object-oriented programming
  350. in Scheme. 
  351.  
  352. In Common Lisp, a simple program would look something like the
  353. following:
  354.  
  355.    (defun fact (n)
  356.      (if (< n 2)
  357.          1
  358.          (* n (fact (1- n)))))
  359.  
  360. In Scheme, the equivalent program would like like this:
  361.  
  362.    (define fact
  363.      (lambda (n)
  364.        (if (< n 2)
  365.            1
  366.          (* n (fact (- n 1))))))
  367.  
  368. Experienced Lisp programmers might write this program as follows in order
  369. to allow it to run in constant space:
  370.  
  371.    (defun fact (n)
  372.      (labels ((tail-recursive-fact (counter accumulator)
  373.                 (if (> counter n)
  374.                     accumulator
  375.                     (tail-recursive-fact (1+ counter)
  376.                                          (* counter accumulator)))))
  377.        (tail-recursive-fact 1 1)))
  378.  
  379. Whereas in Scheme the same computation could be written as follows:
  380.  
  381.    (define fact
  382.      (lambda (n)
  383.        (letrec ((tail-recursive-fact
  384.                  (lambda (counter accumulator)
  385.                    (if (> counter n)
  386.                        accumulator
  387.                      (tail-recursive-fact (+ counter 1)
  388.                                           (* counter accumulator))))))
  389.                (tail-recursive-fact 1 1))))
  390.  
  391. or perhaps (using IEEE named LETs):
  392.  
  393.    (define fact
  394.      (lambda (n)
  395.        (let loop ((counter n)
  396.                   (accumulator 1))
  397.             (if (< counter 2)
  398.                 accumulator
  399.               (loop (- counter 1)
  400.                     (* accumulator counter))))))
  401.  
  402. Some Schemes allow one to use the syntax (define (fact n) ...) instead
  403. of (define fact (lambda (n) ...)).
  404.  
  405. ----------------------------------------------------------------
  406. Subject: [1-2] Lisp books, introductions, documentation, periodicals,
  407.                journals, and conference proceedings. 
  408.  
  409. There are several good Lisp introductions and tutorials:
  410.  
  411.    1. David S. Touretzky
  412.       "Common Lisp: A Gentle Introduction to Symbolic Computation"
  413.       Benjamin/Cummings Publishers, Redwood City, CA, 1990. 592 pages.
  414.       ISBN 0-8053-0492-4 ($42.95). 
  415.            Perhaps the best tutorial introduction to the language. It has
  416.            clear and correct explanations, and covers some fairly advanced
  417.            topics. The book is an updated Common Lisp version of the 1984
  418.            edition published by Harper and Row Publishers. 
  419.  
  420.            Three free Lisp educational tools which were used in the book --
  421.            Evaltrace, DTRACE and SDRAW -- are available by anonymous ftp from
  422.               b.gp.cs.cmu.edu:/usr/dst/public/lisp/
  423.               b.gp.cs.cmu.edu:/usr/dst/public/evaltrace/
  424.        Evaltrace is a graphical notation for explaining how evaluation
  425.        works and is described in "Visualizing Evaluation in
  426.        Applicative Languages" by David S. Touretzky and Peter Lee,
  427.        CACM 45-59, October 1992. DTRACE is a "detailed trace" which
  428.        provides more information than the tracing tools provided with
  429.        most Common Lisp implementations. SDRAW is a read-eval-draw
  430.        loop that evaluates Lisp expressions and draws the result as a
  431.        cons cell diagram (for both X11 and ascii terminals). Also
  432.        available is PPMX, a tool for pretty printing macro expansions.
  433.  
  434.    2. Robert Wilensky.
  435.       "Common LISPcraft"
  436.       W. W. Norton, New York, 1986. 500 pages. ISBN 0-393-95544-3.
  437.  
  438.    3. Wade L. Hennessey.
  439.       "Common Lisp"
  440.       McGraw-Hill, New York, 1989. 395 pages. ISBN 0-07-028177-7, $26.95.
  441.            Fairly good, but jumps back and forth from the simple to the
  442.            complex rather quickly, with no clear progression in difficulty.
  443.  
  444.    4. Laurent Siklossy.
  445.       "Let's Talk LISP"
  446.       Prentice-Hall, NJ, 1976. 237 pages, ISBN 0-13-53276-2-8.
  447.            Good introduction, but quite out of date.
  448.  
  449.    5. Stuart C. Shapiro.
  450.       "Common Lisp: An Interactive Approach"
  451.       Computer Science Press/W.H. Freeman, New York, 1992. 
  452.       358 pages, ISBN 0-7167-8218-9. 
  453.          The errata for the book may be obtained by anonymous ftp from
  454.          ftp.cs.buffalo.edu:/users/shapiro/clerrata.ps
  455.  
  456. Other introductions to Lisp include:
  457.  
  458.    1. A. A. Berk.
  459.       "LISP, The Language of Artificial Intelligence"
  460.       Van Nostrand Reinhold, 1985. 160 pages, ISBN 0-44-22097-4-6.
  461.  
  462.    2. Paul Y. Gloess.
  463.       "An Alfred handy guide to Understanding LISP"
  464.       Alfred Publishers (Sherman Oaks, CA), 1982. 
  465.       64 pages, ISBN 0-88-28421-9-6, $2.95.
  466.  
  467.    3. Ward D. Maurer.
  468.       "The Programmer's Introduction to LISP"
  469.       American Elsevier, New York, 1972. 112 pages, ISBN 0-44-41957-2-6.
  470.  
  471.    4. Hank Bromley and Richard Lamson.
  472.       "LISP Lore: A Guide to Programming the LISP Machine", 2nd edition
  473.       Kluwer Academic, Boston, 1987. 337 pages, ISBN 0-89-83822-8-9, $49.95.
  474.  
  475.    5. Sharam Hekmatpour.
  476.       "Introduction to LISP and Symbol Manipulation"
  477.       Prentice Hall, New York, 1989. 303 pages, ISBN 0-13-53749-0-1, $40.
  478.  
  479.    6. Deborah G. Tatar
  480.       "A programmer's guide to Common Lisp"
  481.       Digital Press, 1987. 327 pages. ISBN 0-932376-87-8.
  482.            Good introduction on Common Lisp for programmers familiar
  483.            with other programming languages, such as FORTRAN, PASCAL, or C.
  484.  
  485.    7. Timothy Koschmann
  486.       "The Common Lisp Companion"
  487.       John Wiley & Sons, 1990. 459 pages, ISBN 0-471-503-8-8.
  488.            Targeted for those with some programming experience who wish to 
  489.            learn draft-ANSI Common Lisp, including CLOS and the CL condition 
  490.            system. Examples progress incrementally from simple numerical 
  491.            calculation all the way to a logic-programming extension to CL.
  492.   
  493. More advanced introductions to Lisp and its use in Artificial
  494. Intelligence include:
  495.  
  496.    1. Peter Norvig.
  497.       "Paradigms of AI Programming: Case Studies in Common Lisp"
  498.       Morgan Kaufmann, 1992. 946 pages. ISBN 1-55860-191-0 ($49.95).
  499.  
  500.         Provides an in-depth exposition of advanced AI programming techniques
  501.         and includes large-scale detailed examples. The book is the most
  502.         advanced AI/Common-Lisp programming text and reference currently
  503.         available, and hence is not for the complete novice.  It focuses on the
  504.         programming techniques necessary for building large AI systems,
  505.         including object-oriented programming, and has a strong performance
  506.         orientation.
  507.  
  508.         The text is marked by its use of "non-toy" examples to illustrate the
  509.         techniques. All of the examples are written in Common Lisp, and copies
  510.         of the source code are available by anonymous ftp from
  511.         unix.sri.com:/pub/norvig and on disk in Macintosh or DOS format from
  512.         the publisher. Some of the techniques described include rule-based
  513.         pattern matching (GPS, Eliza, a subset of Macsyma, the Emycin expert
  514.         system shell), constraint propagation and backtracking (Waltz
  515.         line-labelling), alpha-beta search (Othello), natural language
  516.         processing (top-down, bottom-up and chart parsing), logic-programming
  517.         (unification and Prolog), interpreters and compilers for Scheme, and
  518.         object-oriented programming (CLOS).
  519.  
  520.         The examples are also used to illustrate good programming style and
  521.         efficiency. There is a guide to trouble-shooting and debugging Lisp
  522.         programs, a style guide, and a discussion of portability problems.
  523.         Some of the efficiency techniques described include memoization,
  524.         data indexing, compilation, delaying computation, proper use of
  525.         declarations, avoiding garbage collection, and choosing and using the
  526.         correct data structure.
  527.  
  528.         The book also serves as an advanced introduction to Common Lisp, with
  529.         sections on the Loop macro, CLOS and sequences, and some coverage of 
  530.         error handling, series, and the package facility.
  531.  
  532.    2. Eugene Charniak, Christopher K. Riesbeck, Drew V. McDermott
  533.       and James R. Meehan.
  534.       "Artificial Intelligence Programming", 2nd edition.
  535.       Lawrence Erlbaum Associates (Hillsdale, NJ), 1987. 
  536.       533 pages, ISBN 0-89-85960-9-2, $29.95.
  537.  
  538.            Provides many nice code fragments, all of which are written
  539.            in Common Lisp. The first half of the book covers topics
  540.            like macros, the reader, data structures, control structures,
  541.            and defstructs. The second half of the book describes
  542.            programming techniques specific to AI, such as
  543.            discrimination nets, production systems, deductive database
  544.            retrieval, logic programming, and truth maintenance.
  545.  
  546.    3. Patrick H. Winston and Berthold K. P. Horn.
  547.       "LISP", 3rd edition.
  548.       Addison-Wesley (Reading, MA), 1989. 611 pages. ISBN 0-201-08319-1
  549.            Covers the basic concepts of the language, but also gives a lot
  550.            of detail about programming AI topics such as rule-based expert
  551.            systems, forward chaining, interpreting transition trees, 
  552.            compiling transition trees, object oriented programming,
  553.            and finding patterns in images. Not a tutorial. Has many
  554.            good examples. Source code for the examples is available by
  555.            anonymous ftp from ftp.ai.mit.edu:/pub/lisp3/. (The code runs in
  556.            Lucid, Allegro, KCL, GCLisp, MCL, Symbolics Genera. Send mail
  557.            with subject line "help" to ai3@ai.mit.edu for more information.)
  558.  
  559.    4. John R. Anderson, Albert T. Corbett, and Brian J. Reiser.
  560.       "Essential LISP"
  561.       Addison-Wesley (Reading, MA), 1987. 
  562.       352 pages, ISBN 0-20-11114-8-9, $23.95.
  563.            Concentrates on how to use Lisp with iteration and recursion.
  564.  
  565.    5. Robert D. Cameron and Anthony H. Dixon
  566.       "Symbolic Computing with Lisp"
  567.       Prentice-Hall, 1992, 326 pages. ISBN 0-13-877846-9.
  568.            The book is intended primarily as a third-year computer science
  569.            text. In terms of programming techniques, it emphasizes recursion
  570.            and induction, data abstraction, grammar-based definition of Lisp
  571.            data structures and functional programming style. It uses
  572.            two Lisp languages: 
  573.                 (1) a purely functional subset of Lisp called Small Lisp and
  574.                 (2) Common Lisp.
  575.            An MS-DOS interpreter for Small Lisp (including source) is
  576.            provided with the book.  It considers applications of Lisp
  577.            to formal symbolic data domains: algebraic expressions,
  578.            logical formulas, grammars and programming languages. 
  579.  
  580.    6. Tony Hasemer and John Domingue.
  581.       "Common Lisp Programming for Artificial Intelligence"
  582.       Addison-Wesley, Reading, MA, 1989. 444 pages, ISBN 0-20-11757-9-7.
  583.  
  584.      This book presents an introduction to Artificial Intelligence
  585.      with an emphasis on the role of knowledge representation. Three
  586.      chapters focus on object-oriented programming, including the
  587.      construction and use of a subset of CLOS.
  588.  
  589.      The authors' research into the problems faced by novice Lisp
  590.      users influenced the content and style of the book. (The authors
  591.      are members of the Human Cognition Research Laboratory at the
  592.      Open University in the United Kingdom.) The book employs a
  593.      tutorial approach, especially in areas that students often find
  594.      difficult, such as recursion.  Early and progressive treatment of
  595.      the evaluator promotes understanding of program execution.
  596.      Hands-on exercises are used to reinforce basic concepts.
  597.  
  598.      The book assumes no prior knowledge of Lisp or AI and is a
  599.      suitable textbook for students in Cognitive Science, Computer
  600.      Science and other disciplines taking courses in Lisp or AI
  601.      programming as well as being invaluable for professional
  602.      programmers who are learning Lisp for developing AI applications.
  603.  
  604.    7. Steven Tanimoto
  605.       "The Elements of Artificial Intelligence Using Common Lisp", 2nd edition
  606.       Computer Science Press, New York, 1995.
  607.       562 pages, ISBN 0-71-67826-9-3, (ISBN 0-71-67823-0-8, 1990, $48).
  608.  
  609.    8. Patrick R. Harrison
  610.       "Common Lisp and Artificial Intelligence"
  611.       Prentice Hall, Englewood Clifs, NJ, 1990. 
  612.       244 pages, ISBN 0-13-1552430, $22.50.
  613.  
  614.    9. Paul Graham
  615.       "On Lisp: Advanced Techniques for Common Lisp"
  616.       Prentice Hall, Englewood Clifs, NJ, 1994. 413 pages, ISBN 0-13-030552-9.
  617.          Emphasizes a bottom-up style of writing programs, which he
  618.          claims is natural in Lisp and has advantages over the
  619.          traditional way of writing programs in C and Pascal.
  620.          Also has in-depth sections on writing macros with several
  621.          nice examples. Source code is available by anonymous ftp from
  622.             ftp.das.harvard.edu:/pub/onlisp/ 
  623.          as a single 56kb file.
  624.  
  625.   10. John A. Moyne
  626.       "Lisp: A first language for computing"
  627.        Van Nostrand Reinhold, New York, 1991. 278 pages, ISBN 0442004265.
  628.  
  629. General Lisp reference books include:
  630.  
  631.    1. ANSI/X3J13
  632.       Programming Language Common Lisp (ANSI/X3.226-1994)
  633.       American National Standards Institute
  634.       11 West 42nd Street, New York, NY 10036.
  635.       http://www.ansi.org/
  636.  
  637.    2. Kent M. Pitman
  638.       Common Lisp HyperSpec (TM)
  639.       Harlequin, Inc., 1996.
  640.       This is an HTML-only document available via the web.
  641.       Available for browsing from 
  642.      http://www.harlequin.com/books/HyperSpec/FrontMatter/
  643.       Available free for download (subject to some legal restrictions) from
  644.      http://www.harlequin.com/books/HyperSpec/
  645.       Includes text from ANSI/X3.226-1994 and other design rationales.
  646.  
  647.    3. Guy L. Steele
  648.       "Common Lisp: The Language" [CLtL1]
  649.       Digital Press, 1984. 465 pages. ISBN 0-932376-41-X.
  650.  
  651.    4. Guy L. Steele
  652.       "Common Lisp: The Language, 2nd Edition" [CLtL2]
  653.       Digital Press, 1990. 1029 pages, ISBN 1-55558-041-6 paperbound ($39.95).
  654.  
  655.       [Butterworth-Heinemann, the owners of Digital Press, have made
  656.        the LaTeX sources to this book available by anonymous FTP from
  657.           cambridge.apple.com:/pub/CLTL/ 
  658.        A copy of the distribution is also available from
  659.           ftp.cs.cmu.edu:/user/ai/lang/lisp/doc/cltl/
  660.        The paperbound version of the book is, of course, available at
  661.        fine bookstores, or contact them directly at Digital Press, 
  662.        225 Wildwood Street, Woburn, MA 01801, call 800-366-2665
  663.        (617-928-2527), or fax 800-446-6520 (617-933-6333). A copy of
  664.        the Digital Press book catalog is available from the same FTP location.]
  665.  
  666.        A html version, produced using latex2html on the latex sources,
  667.        is accessible via the URL:
  668.            http://www.cs.cmu.edu/Web/Groups/AI/html/cltl/cltl2.html
  669.  
  670.    5. Franz Inc. 
  671.       "Common Lisp: The Reference"
  672.       Addison-Wesley, Reading, MA 1988. ISBN 0-201-11458-5
  673.            Entries on Lisp (CLtL1) functions in alphabetical order.
  674.  
  675.    6. Rosemary Simpson
  676.       "Common Lisp, the Index"
  677.       Franz Inc., Berkeley, CA, 1987. 71 pages, $4.95. 
  678.            A cross-referenced index to Steele's book, 1st edition.
  679.  
  680. Lisp periodicals include:
  681.         
  682.    1. LISP Pointers.
  683.       Published by ACM SIGPLAN six times a year. Volume 1, Number 1
  684.       was April-May 1987. 
  685.       Subscriptions: ACM Members $12; ACM Student Members $7; Non-ACM
  686.       members $25. Mail checks payable to the ACM to ACM Inc., PO Box
  687.       12115, Church Street Station, New York, NY 10249.
  688.  
  689.    2. LISP and Symbolic Computation, Kluwer Academic Press. Volume 1
  690.       was published in 1989. (Robert Kessler <kessler@cons.cs.utah.edu>
  691.       and Carolyn Talcott <clt@sail.stanford.edu> are the editors).
  692.       ISSN 0892-4635.
  693.       Subscriptions: Institutions $169; Individuals $80. Add $8 for
  694.       air mail. Kluwer Academic Publishers, PO Box 322, 3300 AH Dordrecht, 
  695.       The Netherlands, or Kluwer Academic Publishers, PO Box 358, Accord
  696.       Station, Hingham, MA 02018-0358. 
  697.  
  698.       A full table of contents of all published issues, aims and scope, and
  699.       instructions for authors are available by anonymous ftp from
  700.          ftp.std.com:/Kluwer/journals/
  701.       as the files lisp.toc and lisp.inf.
  702.  
  703.    3. Proceedings of the biannual ACM Lisp and Functional Programming
  704.       Conference. (First one was in 1980.)
  705.  
  706.    4. Proceedings of the annual Lisp Users and Vendors Conference.
  707.  
  708. Implementation-specific questions:
  709.  
  710.    1. Lucid. See the wizards.doc file that comes with the Lucid
  711.       release. It describes functions, macros, variables and constants that
  712.       are not official parts of the product and are not supported.
  713.       Constructs described in this file include: the interrupt facility, the
  714.       source file recording facility, the resource facility, multitasking,
  715.       writing your own streams, lisp pipes, i/o buffers, the compiler,
  716.       floating-point functions, memory management, debugger information, the
  717.       window tool kit, extensions to the editor, the foreign function
  718.       interface, clos information, delivery toolkit information, and Lucid
  719.       lisp training classes. The wizards.doc file also covers i/o
  720.       constructs, functions for dealing with DEFSTRUCT, functions and
  721.       constants for dealing with procedure objects, functions and constants
  722.       for dealing with code objects, function for mapping objects,
  723.       additional keyword argument to DISKSAVE, function used in the
  724.       implementation of arrays, function for monitor-specific behavior for a
  725.       process, additional keyword argument to RUN-PROGRAM, and load-time
  726.       evaluation.
  727.  
  728. Many books on Scheme are worth reading even if you use Common Lisp,
  729. because many of the issues are similar. Scheme is a simpler language
  730. to learn, so it is often used in introductory computer science
  731. classes.  See the Scheme FAQ for a list of introductions and
  732. references for Scheme. The two key introductions are Abelson and
  733. Sussman's "Structure and Interpretation of Computer Programs" and 
  734. Friedman and Felleisen's "The Little LISPer". 
  735.  
  736. Special Topics:
  737.  
  738.    Garbage Collection:
  739.  
  740.       Wilson, Paul R., "Uniprocessor Garbage Collection Techniques"
  741.       Proceedings of the 1992 International Workshop on Memory Management.
  742.       Springer Lecture Notes #637. Surveys garbage collection techniques. 
  743.       Includes an excellent bibliography. Available by anonymous ftp from
  744.          cs.utexas.edu:/pub/garbage/gcsurvey.ps.
  745.       The BibTeX format of the bibliography is also available in this
  746.       directory, along with several other papers. Contact wilson@cs.utexas.edu
  747.       for more info.
  748.  
  749. ----------------------------------------------------------------
  750. Subject: [1-3] How can I improve my Lisp programming style and 
  751.                coding efficiency?
  752.  
  753. There are several books about Lisp programming style, including:
  754.    
  755.    1. Molly M. Miller and Eric Benson
  756.       "Lisp Style and Design"
  757.       Digital Press, 1990. 214 pages, ISBN 1-55558-044-0, $26.95.
  758.            How to write large Lisp programs and improve Lisp programming 
  759.            style. Uses the development of Lucid CL as an example. 
  760.  
  761.    2. Robin Jones, Clive Maynard, and Ian Stewart.
  762.       "The Art of Lisp Programming"
  763.       Springer-Verlag, 1989. 169 pages, ISBN 0-387-19568-8 ($33).
  764.  
  765.    3. W. Richard Stark.
  766.       "LISP, Lore, and Logic: An Algebraic View of LISP
  767.        Programming, Foundations, and Applications"
  768.       Springer-Verlag, 1990. 278 pages. ISBN 0-387-97072-X paper ($42).
  769.            Self-modifying code, self-reproducing programs, etc.
  770.  
  771.    4. CMU CL User's Manual, Chapter 7, (talks about writing
  772.       efficient code). It is available by anonymous ftp from any CMU CS 
  773.       machine (e.g., ftp.cs.cmu.edu [128.2.206.173]) as the file
  774.         /afs/cs.cmu.edu/project/clisp/docs/cmu-user/cmu-user.ps 
  775.       [when getting this file by anonymous ftp, one must cd to 
  776.       the directory in one atomic operation, as some of the superior
  777.       directories on the path are protected from access by anonymous ftp.]
  778.  
  779.    5. See also Norvig's book, SICP (Abelson & Sussman), SAP
  780.       (Springer and Friedman).
  781.  
  782.    6. Hallvard Tretteberg's Lisp Style Guide is available by anonymous
  783.       ftp in ftp.think.com:/public/think/lisp/style-guide.text. There is
  784.       a fair bit of overlap between Hallvard's style guide and the notes
  785.       below and in part 3 of this FAQ.
  786.  
  787.    7. Rajeev Sangal
  788.       "Programming Paradigms in Lisp"
  789.       McGraw-Hill, 1991. ISBN 0-07-054666-5.
  790.  
  791.    8. Rodney A. Brooks.
  792.       "Programming in Common Lisp"
  793.       John Wiley & Sons, New York, 1985. 303 pages. ISBN 0-471-81888-7.
  794.       Chapter 5 discusses Lisp programming style.
  795.  
  796. Here are some general suggestions/notes about improving Lisp
  797. programming style, readability, correctness and efficiency:
  798.  
  799.    General Programming Style Rules:
  800.  
  801.       - Write short functions, where each function provides a single,
  802.         well-defined operation. Small functions are easier to
  803.         read, write, test, debug, and understand.
  804.  
  805.       - Use descriptive variable and function names. If it isn't clear
  806.         from the name of a function or variable what its purpose is,
  807.         document it with a documentation string and a comment. In fact,
  808.         even if the purpose is evident from the name, it is still worth
  809.         documenting your code.
  810.  
  811.       - Don't write Pascal (or C) code in Lisp. Use the appropriate
  812.         predefined functions -- look in the index to CLtL2, or use the
  813.         APROPOS and DESCRIBE functions. Don't put a close parenthesis
  814.         on a line by itself -- this can really irritate programmers
  815.         who grew up on Lisp. Lisp-oriented text editors include tools
  816.         for ensuring balanced parentheses and for moving across 
  817.         pairs of balanced parentheses. You don't need to stick
  818.         comments on close parentheses to mark which expression they close.
  819.  
  820.       - Use proper indentation -- you should be able to understand
  821.         the structure of your definitions without noticing the parentheses. 
  822.         In general, the way one indents a form is controlled by the
  823.         first symbol of the form. In DEFUNs, for example, one puts the
  824.         symbol DEFUN, the function name, and the argument list all on
  825.         the same line. If the argument list is too long, one can break
  826.         it at one of the lambda keywords. Following the argument list,
  827.         one inserts a carriage return and lists the expressions in the
  828.         body of the definition, with each form starting on its own
  829.         line indented three spaces relative to the open parenthesis of
  830.         the parent (in this case the DEFUN). This general style -- of
  831.         putting all the significant elements of a form on a single
  832.         line, followed by a carriage return and the indented body --
  833.         holds for many Lisp constructs. There are, of course, variations,
  834.         such as keeping the first clause on the same line as the COND
  835.         or CASE symbol, and the rules are relaxed in different ways to
  836.         keep line lengths to a manageable size. If you find yourself having
  837.         trouble fitting everything in even with line breaking and
  838.         relaxing the rules, either your function names are too long or your
  839.         code isn't very modular. You should perceive this as a signal that
  840.         you need to break up your big definitions into smaller chunks, each
  841.         with a clearly defined purpose, and possibly replace long function
  842.         names with concise but apt shorter ones.
  843.  
  844.       - Use whitespace appropriately. Use whitespace to separate
  845.         semantically distinct code segments, but don't use too much
  846.         whitespace. For example,
  847.            GOOD: 
  848.               (defun foo (x y)
  849.                 (let ((z (+ x y 10)))
  850.                   (* z z)))
  851.  
  852.            BAD: 
  853.               (defun foo(x y)(let((z(+ x y 10)))(* z z)))
  854.  
  855.               (defun foo ( x  y )
  856.                 (let ( ( z (+ x y 10) ) )
  857.                   ( * z z )
  858.                   )
  859.                 )    
  860.          Although the Lisp reader and compiler don't care which you
  861.          use, most experienced Lisp programmers find the first example 
  862.          much easier to read than the last two.
  863.  
  864.        - Don't use line lengths greater than 80 characters. People who
  865.          write code using Zmacs on Symbolics Lisp Machines are notoriously
  866.          guilty of violating this rule, because the CPT6 font allows
  867.          one to squeeze a tremendous amount of code on the display,
  868.          especially if one spreads the code out horizontally. This
  869.          makes it more difficult to read when printed out or read on
  870.          an 80x24 xterm window. In fact, use a line length of 72 characters
  871.          because it leaves a strip of white space at the edge of the window.
  872.  
  873.    The following functions often abused or misunderstood by novices. 
  874.    Think twice before using any of these functions.
  875.  
  876.       - EVAL. Novices almost always misuse EVAL. When experts use
  877.         EVAL, they often would be better off using APPLY, FUNCALL, or
  878.         SYMBOL-VALUE. Use of EVAL when defining a macro should set off
  879.         a warning bell -- macro definitions are already evaluated
  880.         during expansion. See also the answer to question 3-12.
  881.         The general rule of thumb about EVAL is: if you think you need
  882.         to use EVAL, you're probably wrong.
  883.  
  884.       - PROGV. PROGV binds dynamic variables and is often misused in
  885.         conjunction with EVAL, which uses the dynamic environment. 
  886.         In general, avoid unnecessary use of special variables.
  887.         PROGV is mainly for writing interpreters for languages embedded
  888.         in Lisp. If you want to bind a list of values to a list of
  889.         lexical variables, use
  890.             (MULTIPLE-VALUE-BIND (..) (VALUES-LIST ..) ..)
  891.         or
  892.             (MULTIPLE-VALUE-SETQ (..) (VALUES-LIST ..))
  893.         instead. Most decent compilers can optimize this expression. 
  894.         However, use of this idiom is not to be encouraged unless absolutely
  895.         necessary.
  896.  
  897.       - CATCH and THROW. Often a named BLOCK and RETURN-FROM are
  898.         more appropriate. Use UNWIND-PROTECT when necessary.
  899.  
  900.       - Destructive operations, such as NCONC, SORT, DELETE,
  901.         RPLACA, and RPLACD, should be used carefully and sparingly.
  902.         In general, trust the garbage collector: allocate new
  903.         data structures when you need them.
  904.  
  905.    To improve the readability of your code,
  906.  
  907.       - Don't use any C{A,D}R functions with more than two
  908.         letters between the C and the R. When nested, they become
  909.         hard to read. If you have complex data structures, you
  910.         are often better off describing them with a DEFSTRUCT,
  911.         even if the type is LIST. The data abstraction afforded by
  912.         DEFSTRUCT makes the code much more readable and its purpose
  913.         clearer. If you must use C{A,D}R, try to use
  914.         DESTRUCTURING-BIND instead, or at least SECOND, THIRD, 
  915.         NTH, NTHCDR, etc.
  916.  
  917.       - Use COND instead of IF and PROGN. In general, don't use PROGN if
  918.         there is a way to write the code within an implicit
  919.         PROGN. For example, 
  920.            (IF (FOO X)
  921.                (PROGN (PRINT "hi there") 23)
  922.                34)
  923.         should be written using COND instead.
  924.  
  925.       - Never use a 2-argument IF or a 3-argument IF with a second
  926.         argument of NIL unless you want to emphasize the return value;
  927.         use WHEN and UNLESS instead. You will want to emphasize the
  928.         return value when the IF clause is embedded within a SETQ,
  929.         such as (SETQ X (IF (EQ Y Z) 2 NIL)). If the second argument 
  930.         to IF is the same as the first, use OR instead: (OR P Q) rather
  931.         than (IF P P Q). Use UNLESS instead of (WHEN (NOT ..) ..)
  932.         but not instead of (WHEN (NULL ..) ..).
  933.  
  934.       - Use COND instead of nested IF statements. Be sure to check for
  935.         unreachable cases, and eliminate those cond-clauses.
  936.  
  937.       - Use backquote, rather than explicit calls to LIST, CONS, and
  938.         APPEND, whenever writing a form which produces a Lisp form, but
  939.         not as a general substitute for LIST, CONS and APPEND. LIST, 
  940.         CONS and APPEND usually allocate new storage, but lists produced
  941.         by backquote may involve destructive modification (e.g., ,.).
  942.  
  943.       - Make the names of special (global) variables begin and end
  944.         with an asterisk (*): (DEFVAR *GLOBAL-VARIABLE*)   
  945.         Some programmers will mark the beginning and end of an internal
  946.         global variable with a percent (%) or a period (.).
  947.         Make the names of constants begin and end with a plus (+):
  948.         (DEFCONSTANT +E+ 2.7182818)
  949.         This helps distinguish them from lexical variables. Some people
  950.         prefer to use macros to define constants, since this avoids
  951.         the problem of accidentally trying to bind a symbol declared
  952.         with defconstant.
  953.  
  954.       - If your program is built upon an underlying substrate which is
  955.         implementation-dependent, consider naming those functions and
  956.         macros in a way that visually identifies them, either by placing
  957.         them in their own package, or prepending a character like a %, ., 
  958.         or ! to the function name. Note that many programmers use the
  959.         $ as a macro character for slot access, so it should be avoided
  960.         unless you're using it for that purpose.
  961.  
  962.       - Don't use property lists. Instead, use an explicit hash table.
  963.         This helps avoid problems caused by the symbol being in the wrong
  964.         package, accidental reuse of property keys from other
  965.         programs, and allows you to customize the structure of the table. 
  966.  
  967.       - Use the most specific construct that does the job. This lets
  968.         readers of the code see what you intended when writing the code.
  969.         For example, don't use SETF if SETQ will do (e.g., for lexical
  970.         variables). Using SETQ will tell readers of your code that you
  971.         aren't doing anything fancy. Likewise, don't use EQUAL where EQ
  972.         will do. Use the most specific predicate to test your conditions. 
  973.         
  974.       - If you intend for a function to be a predicate, have it return T
  975.         for true, not just non-NIL. If there is nothing worth returning
  976.         from a function, returning T is conventional. But if a function
  977.         is intended to be more than just a predicate, it is better to 
  978.         return a useful value. (For example, this is one of the differences
  979.         between MEMBER and FIND.)
  980.  
  981.       - When NIL is used as an empty list, use () in your code. When NIL
  982.         is used as a boolean, use NIL. Similarly, use NULL to test for an
  983.         empty list, NOT to test a logical value. Use ENDP to test for the
  984.         end of a list, not NULL.
  985.  
  986.       - Don't use the &AUX lambda-list keyword. It is always clearer to
  987.         define local variables using LET or LET*.
  988.  
  989.       - When using RETURN and RETURN-FROM to exit from a block, don't
  990.         use (VALUES ..) when returning only one value, except if you
  991.         are using it to suppress extra multiple values from the first
  992.         argument. 
  993.  
  994.       - If you want a function to return no values (i.e., equivalent to
  995.         VOID in C), use (VALUES) to return zero values. This signals
  996.         to the reader that the function is used mainly for side-effects.
  997.  
  998.       - (VALUES (VALUES 1 2 3)) returns only the first value, 1.
  999.         You can use (VALUES (some-multiple-value-function ..)) to suppress
  1000.         the extra multiple values from the function. Use MULTIPLE-VALUE-PROG1
  1001.         instead of PROG1 when the multiple values are significant.
  1002.  
  1003.       - When using MULTIPLE-VALUE-BIND and DESTRUCTURING-BIND, don't rely
  1004.         on the fact that NIL is used when values are missing. This is
  1005.         an error in some implementations of DESTRUCTURING-BIND. Instead,
  1006.         make sure that your function always returns the proper number of
  1007.         values.
  1008.  
  1009.       - Type the name of external symbols, functions, and variables
  1010.         from the COMMON-LISP package in uppercase. This will allow your
  1011.         code to work properly in a case-sensitive version of Common Lisp,
  1012.         since the print-names of symbols in the COMMON-LISP package
  1013.         are uppercase internally. (However, not everybody feels that
  1014.         being nice to case-sensitive Lisps is a requirement, so this
  1015.         isn't an absolute style rule, just a suggestion.)
  1016.  
  1017.     Lisp Idioms:
  1018.  
  1019.       - MAPCAN is used with a function to return a variable number of
  1020.         items to be included in an output list. When the function returns zero
  1021.         or one items, the function serves as a filter. For example,
  1022.            (mapcan #'(lambda (x) (when (and (numberp x) (evenp x)) (list x)))
  1023.                    '(1 2 3 4 x 5 y 6 z 7))
  1024.  
  1025.     Documentation:
  1026.  
  1027.       - Comment your code. Use three semicolons in the left margin before
  1028.         the definition for major explanations. Use two semicolons that
  1029.         float with the code to explain the routine that follows. Two
  1030.         semicolons may also be used to explain the following line when the
  1031.         comment is too long for the single semicolon treatment. Use
  1032.         a single semicolon to the right of the code to explain a particular
  1033.         line with a short comment. The number of semicolons used roughly
  1034.         corresponds with the length of the comment. Put at least one blank
  1035.         line before and after top-level expressions.
  1036.  
  1037.       - Include documentation strings in your code. This lets users
  1038.         get help while running your program without having to resort to
  1039.         the source code or printed documentation. 
  1040.  
  1041.    Issues related to macros:
  1042.  
  1043.       - Never use a macro instead of a function for efficiency reasons.
  1044.         Declaim the function as inline -- for example, 
  1045.           (DECLAIM (INLINE ..))
  1046.         This is *not* a magic bullet -- be forewarned that inline
  1047.         expansions can often increase the code size dramatically. INLINE
  1048.         should be used only for short functions where the tradeoff is
  1049.         likely to be worthwhile: inner loops, types that the compiler
  1050.         might do something smart with, and so on.
  1051.  
  1052.       - When defining a macro that provides an implicit PROGN, use the
  1053.         &BODY lambda-list keyword instead of &REST.
  1054.  
  1055.       - Use gensyms for bindings within a macro, unless the macro lets
  1056.         the user explicitly specify the variable. For example:
  1057.             (defmacro foo ((iter-var list) body-form &body body)
  1058.               (let ((result (gensym "RESULT")))
  1059.                 `(let ((,result nil))
  1060.                    (dolist (,iter-var ,list ,result)
  1061.                      (setq ,result ,body-form)
  1062.                      (when ,result
  1063.                         ,@body)))))        
  1064.         This avoids errors caused by collisions during macro expansion
  1065.         between variable names used in the macro definition and in the
  1066.         supplied body.
  1067.  
  1068.       - Use a DO- prefix in the name of a macro that does some kind of
  1069.         iteration, WITH- when the macro establishes bindings, and
  1070.         DEFINE- or DEF- when the macro creates some definitions. Don't
  1071.         use the prefix MAP- in macro names, only in function names.
  1072.  
  1073.       - Don't create a new iteration macro when an existing function
  1074.         or macro will do.
  1075.  
  1076.       - Don't define a macro where a function definition will work just
  1077.         as well -- remember, you can FUNCALL or MAPCAR a function but 
  1078.         not a macro.
  1079.  
  1080.       - The LOOP and SERIES macros generate efficient code. If you're
  1081.         writing a new iteration macro, consider learning to use one
  1082.         of them instead.
  1083.   
  1084.    File Modularization:
  1085.  
  1086.       - If your program involves macros that are used in more than one
  1087.         file, it is generally a good idea to put such macros in a separate
  1088.         file that gets loaded before the other files. The same things applies
  1089.         to primitive functions. If a macro is complicated, the code that
  1090.         defines the macro should be put into a file by itself. In general, if
  1091.         a set of definitions form a cohesive and "independent" whole, they
  1092.         should be put in a file by themselves, and maybe even in their own
  1093.         package. It isn't unusual for a large Lisp program to have files named
  1094.         "site-dependent-code", "primitives.lisp", and "macros.lisp". If a file
  1095.         contains primarily macros, put "-macros" in the name of the file.
  1096.  
  1097.    Stylistic preferences:
  1098.  
  1099.       - Use (SETF (CAR ..) ..) and (SETF (CDR ..) ..) in preference to
  1100.         RPLACA and RPLACD. Likewise (SETF (GET ..) ..) instead of PUT.
  1101.  
  1102.       - Use INCF, DECF, PUSH and POP instead instead of the corresponding
  1103.         SETF forms.
  1104.  
  1105.       - Many programmers religiously avoid using CATCH, THROW, BLOCK,
  1106.         PROG, GO and TAGBODY.  Tags and go-forms should only be necessary
  1107.         to create extremely unusual and complicated iteration constructs. In
  1108.         almost every circumstance, a ready-made iteration construct or
  1109.         recursive implementation is more appropriate.
  1110.  
  1111.       - Don't use LET* where LET will do. Don't use LABELS where FLET
  1112.         will do. Don't use DO* where DO will do.
  1113.  
  1114.       - Don't use DO where DOTIMES or DOLIST will do.
  1115.  
  1116.       - If you like using MAPCAR instead of DO/DOLIST, use MAPC when
  1117.         no result is needed -- it's more efficient, since it doesn't
  1118.         cons up a list. If a single cumulative value is required, use
  1119.         REDUCE. If you are seeking a particular element, use FIND,
  1120.         POSITION, or MEMBER.
  1121.  
  1122.       - If using REMOVE and DELETE to filter a sequence, don't use the
  1123.         :test-not keyword or the REMOVE-IF-NOT or DELETE-IF-NOT functions.
  1124.         Use COMPLEMENT to complement the predicate and the REMOVE-IF
  1125.         or DELETE-IF functions instead.
  1126.  
  1127.       - Use complex numbers to represent points in a plane.
  1128.  
  1129.       - Don't use lists where vectors are more appropriate. Accessing the
  1130.         nth element of a vector is faster than finding the nth element
  1131.         of a list, since the latter requires pointer chasing while the
  1132.         former requires simple addition. Vectors also take up less space
  1133.         than lists. Use adjustable vectors with fill-pointers to
  1134.         implement a stack, instead of a list -- using a list continually
  1135.         conses and then throws away the conses.
  1136.  
  1137.       - When adding an entry to an association list, use ACONS, not
  1138.         two calls to CONS. This makes it clear that you're using an alist.
  1139.  
  1140.       - If your association list has more than about 10 entries in it,
  1141.         consider using a hash table. Hash tables are often more efficient.
  1142.         (See also [2-2].)
  1143.  
  1144.       - When you don't need the full power of CLOS, consider using
  1145.         structures instead. They are often faster, take up less space, and
  1146.         easier to use.
  1147.  
  1148.       - Use PRINT-UNREADABLE-OBJECT when writing a print-function.
  1149.  
  1150.       - Use WITH-OPEN-FILE instead of OPEN and CLOSE.
  1151.  
  1152.       - When a HANDLER-CASE clause is executed, the stack has already
  1153.         unwound, so dynamic bindings that existed when the error
  1154.         occured may no longer exist when the handler is run. Use
  1155.         HANDLER-BIND if you need this. 
  1156.  
  1157.       - When using CASE and TYPECASE forms, if you intend for the form
  1158.         to return NIL when all cases fail, include an explicit OTHERWISE
  1159.         clause. If it would be an error to return NIL when all cases
  1160.         fail, use ECASE, CCASE, ETYPECASE or CTYPECASE instead.
  1161.  
  1162.       - Use local variables in preference to global variables whenever
  1163.         possible. Do not use global variables in lieu of parameter passing.
  1164.         Global variables can be used in the following circumstances:
  1165.           *  When one function needs to affect the operation of
  1166.              another, but the second function isn't called by the first.
  1167.              (For example, *load-pathname* and *break-on-warnings*.)
  1168.           *  When a called function needs to affect the current or future
  1169.              operation of the caller, but it doesn't make sense to accomplish
  1170.              this by returning multiple values.
  1171.           *  To provide hooks into the mechanisms of the program.
  1172.              (For example, *evalhook*, *, /, and +.)
  1173.           *  Parameters which, when their value is changed, represent a
  1174.              major change to the program.
  1175.              (For example, *print-level* and *print-readably*.)
  1176.           *  For state that persists between invocations of the program.
  1177.              Also, for state which is used by more than one major program.
  1178.              (For example, *package*, *readtable*, *gensym-counter*.)
  1179.           *  To provide convenient information to the user.
  1180.              (For example, *version* and *features*.)
  1181.           *  To provide customizable defaults. 
  1182.              (For example, *default-pathname-defaults*.)
  1183.           *  When a value affects major portions of a program, and passing
  1184.              this value around would be extremely awkward. (The example
  1185.              here is output and input streams for a program. Even when
  1186.              the program passes the stream around as an argument, if you
  1187.              want to redirect all output from the program to a different
  1188.              stream, it is much easier to just rebind the global variable.)
  1189.  
  1190.       - Beginning students, especially ones accustomed to programming
  1191.         in C, Pascal, or Fortran, tend to use global variables to hold or pass
  1192.         information in their programs. This style is considered ugly by
  1193.         experienced Lisp programmers. Although assignment statements can't
  1194.         always be avoided in production code, good programmers take advantage
  1195.         of Lisp's functional programming style before resorting to SETF and
  1196.         SETQ. For example, they will nest function calls instead of using a
  1197.         temporary variable and use the stack to pass multiple values. When
  1198.         first learning to program in Lisp, try to avoid SETF/SETQ and their
  1199.         cousins as much as possible. And if a temporary variable is necessary,
  1200.         bind it to its first value in a LET statement, instead of letting it
  1201.         become a global variable by default. (If you see lots of compiler
  1202.         warnings about declaring variables to be special, you're probably
  1203.         making this mistake. If you intend a variable to be global, it should
  1204.         be defined with a DEFVAR or DEFPARAMETER statement, not left to the
  1205.         compiler to fix.)
  1206.  
  1207.    Correctness and efficiency issues:
  1208.  
  1209.       - In CLtL2, IN-PACKAGE does not evaluate its argument. Use defpackage
  1210.         to define a package and declare the external (exported)
  1211.         symbols from the package. 
  1212.  
  1213.       - The ARRAY-TOTAL-SIZE-LIMIT may be as small as 1024, and the
  1214.         CALL-ARGUMENTS-LIMIT may be as small as 50. 
  1215.  
  1216.       - Novices often mistakenly quote the conditions of a CASE form.
  1217.         For example, (case x ('a 3) ..) is incorrect. It would return
  1218.         3 if x were the symbol QUOTE. Use (case x (a 3) ..) instead.
  1219.  
  1220.       - Avoid using APPLY to flatten lists. Although 
  1221.            (apply #'append list-of-lists)
  1222.         may look like a call with only two arguments, it becomes a 
  1223.         function call to APPEND, with the LIST-OF-LISTS spread into actual
  1224.         arguments. As a result it will have as many arguments as there are
  1225.         elements in LIST-OF-LISTS, and hence may run into problems with the
  1226.         CALL-ARGUMENTS-LIMIT. Use REDUCE or MAPCAN instead:  
  1227.            (reduce #'append list-of-lists :from-end t)
  1228.            (mapcan #'copy-list list-of-lists)
  1229.         The second will often be more efficient (see note below about choosing
  1230.         the right algorithm). Beware of calls like (apply f (mapcar ..)).
  1231.  
  1232.       - NTH must cdr down the list to reach the elements you are
  1233.         interested in. If you don't need the structural flexibility of
  1234.         lists, try using vectors and the ELT function instead.
  1235.  
  1236.       - CASE statements can be vectorized if the keys are consecutive
  1237.         numbers. Such CASE statements can still have OTHERWISE clauses.
  1238.         To take advantage of this without losing readability, use #. with 
  1239.         symbolic constants:
  1240.  
  1241.             (eval-when (compile load eval)
  1242.                (defconstant RED 1)
  1243.                (defconstant GREEN 2)
  1244.                (defconstant BLUE 3))
  1245.  
  1246.             (case color
  1247.               (#.RED   ...)
  1248.               (#.GREEN ...)
  1249.               (#.BLUE  ...)
  1250.               ...)
  1251.  
  1252.       - Don't use quoted constants where you might later destructively
  1253.         modify them. For example, instead of writing '(c d) in
  1254.            (defun foo ()
  1255.              (let ((var '(c d)))
  1256.                ..))
  1257.         write (list 'c 'd) instead. Using a quote here can lead to
  1258.         unexpected results later. If you later destructively modify the 
  1259.         value of var, this is self-modifying code! Some Lisp compilers
  1260.         will complain about this, since they like to make constants
  1261.         read-only. Modifying constants has undefined results in ANSI CL.
  1262.         See also the answer to question [3-13].
  1263.  
  1264.         Similarly, beware of shared list structure arising from the use
  1265.         of backquote. Any sublist in a backquoted expression that doesn't
  1266.         contain any commas can share with the original source structure.
  1267.  
  1268.       - Don't proclaim unsafe optimizations, such as
  1269.            (proclaim '(optimize (safety 0) (speed 3) (space 1))) 
  1270.         since this yields a global effect. Instead, add the
  1271.         optimizations as local declarations to small pieces of
  1272.         well-tested, performance-critical code:
  1273.            (defun well-tested-function ()
  1274.               (declare (optimize (safety 0) (speed 3) (space 1)))
  1275.              ..)
  1276.         Such optimizations can remove run-time type-checking; type-checking
  1277.         is necessary unless you've very carefully checked your code
  1278.         and added all the appropriate type declarations.
  1279.  
  1280.       - Some programmers feel that you shouldn't add declarations to
  1281.         code until it is fully debugged, because incorrect
  1282.         declarations can be an annoying source of errors. They recommend
  1283.         using CHECK-TYPE liberally instead while you are developing the code.
  1284.         On the other hand, if you add declarations to tell the
  1285.         compiler what you think your code is doing, the compiler can
  1286.         then tell you when your assumptions are incorrect.
  1287.         Declarations also make it easier for another programmer to read
  1288.         your code. 
  1289.  
  1290.       - Declaring the type of variables to be FIXNUM does not
  1291.         necessarily mean that the results of arithmetic involving the 
  1292.         fixnums will be a fixnum; it could be a BIGNUM. For example,
  1293.            (declare (type fixnum x y))
  1294.            (setq z (+ (* x x) (* y y)))
  1295.         could result in z being a BIGNUM. If you know the limits of your
  1296.         numbers, use a declaration like
  1297.            (declare (type (integer 0 100) x y))
  1298.         instead, since most compilers can then do the appropriate type
  1299.         inference, leading to much faster code.
  1300.  
  1301.       - Don't change the compiler optimization with an OPTIMIZE
  1302.         proclamation or declaration until the code is fully debugged
  1303.         and profiled.  When first writing code you should say 
  1304.         (declare (optimize (safety 3))) regardless of the speed setting.
  1305.  
  1306.       - Depending on the optimization level of the compiler, type
  1307.         declarations are interpreted either as (1) a guarantee from
  1308.         you that the variable is always bound to values of that type,
  1309.         or (2) a desire that the compiler check that the variable is
  1310.         always bound to values of that type. Use CHECK-TYPE if (2) is
  1311.         your intention.
  1312.  
  1313.       - If you get warnings about unused variables, add IGNORE
  1314.         declarations if appropriate or fix the problem. Letting such
  1315.         warnings stand is a sloppy coding practice.
  1316.  
  1317.    To produce efficient code,
  1318.  
  1319.       - choose the right algorithm. For example, consider seven possible
  1320.         implementations of COPY-LIST:
  1321.  
  1322.            (defun copy-list (list)
  1323.              (let ((result nil))
  1324.                (dolist (item list result)
  1325.                  (setf result (append result (list item))))))
  1326.  
  1327.            (defun copy-list (list)
  1328.              (let ((result nil))
  1329.                (dolist (item list (nreverse result))
  1330.                  (push item result))))
  1331.  
  1332.            (defun copy-list (list)
  1333.              (mapcar #'identity list))
  1334.  
  1335.            (defun copy-list (list)
  1336.              (let ((result (make-list (length list))))
  1337.                (do ((original list (cdr original))
  1338.                     (new result (cdr new)))
  1339.                    ((null original) result)
  1340.                  (setf (car new) (car original)))))
  1341.  
  1342.            (defun copy-list (list)
  1343.              (when list
  1344.                (let* ((result (list (car list)))
  1345.                       (tail-ptr result))
  1346.                  (dolist (item (cdr list) result)
  1347.                    (setf (cdr tail-ptr) (list item))
  1348.                    (setf tail-ptr (cdr tail-ptr))))))
  1349.         
  1350.             (defun copy-list (list)
  1351.               (loop for item in list collect item))
  1352.  
  1353.             (defun copy-list (list)
  1354.               (if (consp list) 
  1355.                   (cons (car list)
  1356.                         (copy-list (cdr list)))
  1357.                   list))
  1358.  
  1359.         The first uses APPEND to tack the elements onto the end of the list.
  1360.         Since APPEND must traverse the entire partial list at each step, this
  1361.         yields a quadratic running time for the algorithm.  The second
  1362.         implementation improves on this by iterating down the list twice; once
  1363.         to build up the list in reverse order, and the second time to reverse
  1364.         it. The efficiency of the third depends on the Lisp implementation,
  1365.         but it is usually similar to the second, as is the fourth.  The fifth
  1366.         algorithm, however, iterates down the list only once. It avoids the
  1367.         extra work by keeping a pointer (reference) to the last cons of the 
  1368.         list and RPLACDing onto the end of that. Use of the fifth algorithm 
  1369.         may yield a speedup. Note that this contradicts the earlier dictum to
  1370.         avoid destructive functions. To make more efficient code one might
  1371.         selectively introduce destructive operations in critical sections of
  1372.         code. Nevertheless, the fifth implementation may be less efficient in
  1373.         Lisps with cdr-coding, since it is more expensive to RPLACD cdr-coded
  1374.         lists. Depending on the implementation of nreverse, however,
  1375.         the fifth and second implementations may be doing the same
  1376.         amount of work. The sixth example uses the Loop macro, which usually
  1377.         expands into code similar to the third. The seventh example copies
  1378.         dotted lists, and runs in linear time, but isn't tail-recursive. 
  1379.  
  1380.         There is a long-running discussion of whether pushing items
  1381.     onto a list and then applying NREVERSE to the result is faster or
  1382.     slower than the alternatives. According to Richard C. Waters (Lisp
  1383.     Pointers VI(4):27-34, October-December 1993), the NREVERSE strategy is
  1384.     slightly faster in most Lisp implementations. But the speed difference
  1385.     either way isn't much, so he argues that one should pursue the option
  1386.     that yields the clearest and simplest code, namely using NREVERSE.
  1387.  
  1388.         Here's code for a possible implementation of NREVERSE. As is
  1389.         evident, most of the alternatives to using NREVERSE involve
  1390.         essentially the same code, just reorganized. 
  1391.  
  1392.        (defun nreverse (list)
  1393.          ;; REVERSED is the partially reversed list, 
  1394.          ;; CURRENT is the current cons cell, which will be reused, and
  1395.          ;; REMAINING are the cons cells which have not yet been reversed.
  1396.          (do* ((reversed nil)        
  1397.            (current list remaining)
  1398.            (remaining (cdr current) (cdr current)))
  1399.          ((null current)
  1400.           reversed)
  1401.            ;; Reuse the cons cell at the head of the list:
  1402.            ;;    reversed := ((car remaining) . reversed)
  1403.            (setf (cdr current) reversed)
  1404.            (setf reversed current)))
  1405.  
  1406.       - use type declarations liberally in time-critical code, but
  1407.         only if you are a seasoned Lisp programmer. Appropriate type
  1408.         declarations help the compiler generate more specific and
  1409.         optimized code. It also lets the reader know what assumptions
  1410.         were made. For example, if you only use fixnum arithmetic,
  1411.         adding declarations can lead to a significant speedup. If you
  1412.         are a novice Lisp programmer, you should use type declarations
  1413.         sparingly, as there may be no checking to see if the
  1414.         declarations are correct, and optimized code can be harder to
  1415.         debug. Wrong declarations can lead to errors in otherwise
  1416.         correct code, and can limit the reuse of code in other
  1417.         contexts. Depending on the Lisp compiler, it may also 
  1418.         be necessary to declare the type of results using THE, since
  1419.         some compilers don't deduce the result type from the inputs.
  1420.  
  1421.       - check the code produced by the compiler by using the
  1422.         disassemble function
  1423.  
  1424. ----------------------------------------------------------------
  1425. Subject: [1-4] Where can I learn about implementing Lisp interpreters 
  1426.                and compilers?
  1427.  
  1428. Books about Lisp implementation include:
  1429.  
  1430.    1. John Allen
  1431.       "Anatomy of Lisp"
  1432.       McGraw-Hill, 1978. 446 pages. ISBN 0-07-001115-X
  1433.            Discusses some of the fundamental issues involved in
  1434.            the implemention of Lisp.  
  1435.  
  1436.    2. Samuel Kamin
  1437.       "Programming Languages, An Interpreter-Based Approach"
  1438.       Addison-Wesley, Reading, Mass., 1990. ISBN 0-201-06824-9
  1439.            Includes sources to several interpreters for Lisp-like languages.
  1440.            The source for the interpreters in the book is available
  1441.            by anonymous FTP from 
  1442.               a.cs.uiuc.edu:/pub/kamin/kamin.distr/
  1443.           Tim Budd reimplemented the interpreters in C++, and has made
  1444.           them available by anonymous ftp from 
  1445.               cs.orst.edu:/pub/budd/kamin/
  1446.  
  1447.    3. Sharam Hekmatpour
  1448.       "Lisp: A Portable Implementation"
  1449.       Prentice Hall, 1985. ISBN 0-13-537490-X.
  1450.            Describes a portable implementation of a small dynamic
  1451.            Lisp interpreter (including C source code). 
  1452.  
  1453.    4. Peter Henderson
  1454.       "Functional Programming: Application and Implementation"
  1455.       Prentice-Hall (Englewood Cliffs, NJ), 1980. 355 pages.
  1456.  
  1457.    5. Peter M. Kogge
  1458.       "The Architecture of Symbolic Computers"
  1459.       McGraw-Hill, 1991. ISBN 0-07-035596-7.
  1460.            Includes sections on memory management, the SECD and
  1461.            Warren Abstract Machines, and overviews of the various
  1462.            Lisp Machine architectures.
  1463.    
  1464.    6. Daniel P. Friedman, Mitchell Wand, and Christopher T. Haynes
  1465.       "Essentials of Programming Languages"
  1466.       MIT Press, 1992, 536 pages. ISBN 0-262-06145-7.
  1467.            Teaches fundamental concepts of programming language
  1468.            design by using small interpreters as examples. Covers
  1469.            most of the features of Scheme. Includes a discussion
  1470.            of parameter passing techniques, object oriented languages,
  1471.            and techniques for transforming interpreters to allow
  1472.            their implementation in terms of any low-level language.
  1473.            Also discusses scanners, parsers, and the derivation of
  1474.            a compiler and virtual machine from an interpreter.
  1475.            Includes a few chapters on converting code into a
  1476.            continuation passing style.
  1477.            Source files available by anonymous ftp from 
  1478.               cs.indiana.edu:/pub/eopl/ [129.79.254.191].
  1479.  
  1480.    7. Peter Lee, editor, "Topics in Advanced Language Implementation",
  1481.       The MIT Press, Cambridge, Mass., 1991.
  1482.            Articles relevant to the implementation of functional
  1483.            programming languages.
  1484.  
  1485.    8. Also see the proceedings of the biannual ACM Lisp and Functional
  1486.       Programming conferences, the implementation notes for CMU Common Lisp,
  1487.       Norvig's book, and SICP (Abelson & Sussman).
  1488.  
  1489.    9. Christian Queinnec
  1490.       "Les Langages Lisp"
  1491.       InterEditions (in French), 1994. 500 pages.
  1492.       ISBN 2-7296-0549-5, 61-2448-1. (?)
  1493.       Cambridge University Press (in English), 1996.
  1494.       ISBN 0-521-56247-3. 
  1495.  
  1496.       The book covers Lisp, Scheme and other related dialects,
  1497.       their interpretation, semantics and compilation.
  1498.  
  1499.       All of the programs described in the book are available by
  1500.       anonymous ftp from
  1501.          ftp.inria.fr:/INRIA/Projects/icsla/Books/LiSP94Sep05.tar.gz
  1502.       For more information, see the book's URL
  1503.          file://ftp.inria.fr/INRIA/Projects/icsla/WWW/LiSP.html
  1504.       or contact the author at Christian.Queinnec@inria.fr
  1505.  
  1506. ----------------------------------------------------------------
  1507. Subject: [1-5] What is the "minimal" set of primitives needed for a Lisp
  1508.                interpreter? 
  1509.  
  1510. Many Lisp functions can be defined in terms of other Lisp functions.
  1511. For example, CAAR can be defined in terms of CAR as
  1512.    (defun caar (list) (car (car list)))
  1513. It is then natural to ask whether there is a "minimal" or smallest set
  1514. of primitives necessary to implement the language. 
  1515.  
  1516. There is no single "best" minimal set of primitives; it all depends on
  1517. the implementation. For example, even something as basic as numbers
  1518. need not be primitive, and can be represented as lists. One possible
  1519. set of primitives might include CAR, CDR, and CONS for manipulation of
  1520. S-expressions, READ and PRINT for the input/output of S-expressions
  1521. and APPLY and EVAL for the guts of an interpreter.  But then you might
  1522. want to add LAMBDA for functions, EQ for equality, COND for
  1523. conditionals, SET for assignment, and DEFUN for definitions. QUOTE
  1524. might come in handy as well. If you add more specialized datatypes,
  1525. such as integers, floats, arrays, characters, and structures, you'll
  1526. need to add primitives to construct and access each.
  1527.  
  1528. AWKLisp is a Lisp interpreter written in awk, available by anonymous
  1529. ftp from ftp.cs.cmu.edu:/user/ai/lang/lisp/impl/awk/. It has thirteen
  1530. built-in functions: CAR, CDR, CONS, EQ, ATOM, SET, EVAL, ERROR, QUOTE,
  1531. COND, AND, OR, LIST. 
  1532.  
  1533. A more practical notion of a "minimal" set of primitives might be to
  1534. look at the implementation of Scheme. While many Scheme functions can
  1535. be derived from others, the language is much smaller than Common Lisp.
  1536. See Dybvig's PhD thesis, 
  1537.    R. Kent Dybvig, "Three Implementation Models for Scheme", Department
  1538.    of Computer Science Technical Report #87-011, University of North
  1539.    Carolina at Chapel Hill, Chapel Hill, North Carolina, April 1987.
  1540. for a justification of a particularly practical minimal set of
  1541. primitives for Scheme.
  1542.  
  1543. In a language like Common Lisp, however, there are a lot of low-level
  1544. primitive functions that cannot be written in terms of the others,
  1545. such as GET-UNIVERSAL-TIME, READ-CHAR, WRITE-CHAR, OPEN, and CLOSE,
  1546. for starters.  Moreover, real Common Lisp implementations are often
  1547. built upon primitives that aren't part of the language, per se, and
  1548. certainly not intended to be user-accessible, such as SYS:%POINTER-REF.
  1549.  
  1550. Beside the references listed in [1-4], some other relevant references
  1551. include:  
  1552.  
  1553.     McCarthy, John, "Recursive Functions of Symbolic Expressions and
  1554.     their Computation by Machine, Part I", CACM 3(4):185-195, April 1960.
  1555.        [Defines five elementary functions on s-expressions.]
  1556.  
  1557.     McCarthy, John, "A Micro-Manual for Lisp -- not the whole Truth",
  1558.     ACM SIGPLAN Notices, 13(8):215-216, August 1978.
  1559.        [Defines the Lisp programming language in 10 rules and gives
  1560.         a small interpreter (eval) written in this Lisp.]
  1561.  
  1562.     McCarthy, John, et al., "LISP 1.5 Programmer's Manual", 2nd edition,
  1563.     MIT Press, 1965, ISBN 0-262-13011-4 (paperback).  
  1564.        [Gives five basic functions, CAR, CDR, CONS, EQ, and ATOM.
  1565.         Using composition, conditional expressions (COND), and
  1566.         recursion, LAMBDA, and QUOTE, these basic functions may be used
  1567.         to construct the entire class of computable functions of
  1568.         S-expressions. Gives the functions EVAL and APPLY in
  1569.         M-expression syntax.] 
  1570.  
  1571.     Abelson and Sussman's SICP, especially chapters 4 and 5 on the
  1572.     implementation of meta-circular and explicit-control evaluators.
  1573.  
  1574.     Steele and Gabriel's "The Evolution of LISP".
  1575.  
  1576. ----------------------------------------------------------------
  1577. Subject: [1-6]  What does CLOS, PCL, X3J13, CAR, CDR, ... mean? 
  1578.  
  1579. Glossary of acronyms:
  1580.    CAR             Originally meant "Contents of Address portion of Register",
  1581.                    which is what CAR actually did on the IBM 704.
  1582.    CDR             Originally meant "Contents of Decrement portion of 
  1583.                    Register", which is what CDR actually did
  1584.                    on the IBM 704. Pronounced "Cudder" /kUdd@r/ (as in "a cow
  1585.                    chews its cdr"). The first syllable is pronounced
  1586.                    like "could". 
  1587.    LISP            Originally from "LISt Processing"
  1588.    GUI             Graphical User Interface
  1589.    CLOS            Common Lisp Object System. The object oriented
  1590.                    programming standard for Common Lisp. Based on
  1591.                    Symbolics FLAVORS and Xerox LOOPS, among others.
  1592.                    Pronounced either as "See-Loss" or "Closs". See also PCL.
  1593.    PCL             Portable Common Loops. A portable CLOS implementation.
  1594.                    Available by anonymous ftp from parcftp.xerox.com:pcl/.
  1595.    LOOPS           Lisp Object Oriented Programming System. A predecessor
  1596.                    to CLOS on Xerox Lisp machines.
  1597.    X3J13           Subcommittee of the ANSI committee X3 which is
  1598.                    working on the ANSI Standardization of Common Lisp.
  1599.    ANSI            American National Standards Institute
  1600.    dpANS           draft proposed American National Standard (what an ANS
  1601.                    is called while it's in the public review stage of
  1602.                    standardization).
  1603.    CL              Common Lisp
  1604.    SC22/WG16       The full name is ISO/IEC JTC 1/SC 22/WG 16. It stands
  1605.                    for International Organization for Standardization/
  1606.                    International Electrotechnical Commission, Joint
  1607.                    Technical Committee 1 Subcommittee 22 (full name
  1608.                    "Information Technology -- Programming Languages
  1609.                    and their Environments"), Working Group 16.  This
  1610.                    long-winded name is the ISO working group working
  1611.                    on an international Lisp standard, (i.e., the ISO
  1612.                    analogue to X3J13). 
  1613.    CLtL1           First edition of Guy Steele's book, 
  1614.                    "Common Lisp the Language". 
  1615.    CLtL2           Second edition of Guy Steele's book,
  1616.                    "Common Lisp the Language". 
  1617.  
  1618. ----------------------------------------------------------------
  1619. Subject: [1-7] Lisp Job Postings
  1620.  
  1621. The LISP-JOBS mailing list exists to help programmers find Lisp
  1622. programming positions, and to help companies with Lisp programming
  1623. positions find capable Lisp programmers. (Lisp here means Lisp-like
  1624. languages, including Scheme.)
  1625.  
  1626. Material appropriate for the list includes Lisp job announcements and
  1627. should be sent to ai+lisp-jobs@cs.cmu.edu. Resumes should NOT be sent to
  1628. the list. 
  1629.  
  1630. [Note: The 'ai+' part of the mailing list name is used for directing
  1631. submissions to the appropriate mail-server. The list is NOT restricted
  1632. to AI-related Lisp jobs -- all Lisp job announcements are welcome.]
  1633.  
  1634. As a matter of policy, the contents of this mailing list is
  1635. considered confidential and will not be disclosed to anybody.
  1636.  
  1637. To subscribe, send a message to ai+query@cs.cmu.edu with
  1638.    subscribe lisp-jobs <First Name> <Last Name>, <Affiliation/Organization>
  1639. in the message body. 
  1640.  
  1641. (If your mailer objects to the "+", send subscription requests to
  1642. "ai+query"@cs.cmu.edu, job announcements to "ai+lisp-jobs"@cs.cmu.edu, etc.)  
  1643.  
  1644. For help on using the query server, send mail to ai+query@cs.cmu.edu with
  1645.    help
  1646. in the message body.
  1647.  
  1648. Job postings sent to the list are automatically archived in
  1649.    ftp.cs.cmu.edu:/user/ai/jobs/lisp/
  1650.  
  1651. If you have any other questions, please send them to ai+@cs.cmu.edu
  1652.  
  1653. ----------------------------------------------------------------
  1654.  
  1655. ;;; *EOF*
  1656.