__________________________________________________________________________ From: mkant+@cs.cmu.edu (Mark Kantrowitz) Newsgroups: comp.lang.lisp,news.answers Subject: FAQ: Lisp Frequently Asked Questions 1/6 [Monthly posting] Message-ID: Date: 13 Nov 92 09:01:41 GMT Approved: news-answers-request@MIT.Edu Archive-name: lisp-faq/part1 Last-Modified: Thu Nov 5 19:30:40 1992 by Mark Kantrowitz Version: 1.27 ;;; **************************************************************** ;;; Answers to Frequently Asked Questions about Lisp *************** ;;; **************************************************************** ;;; Written by Mark Kantrowitz and Barry Margolin ;;; lisp-faq-1.text -- 60654 bytes This post contains Part 1 of the Lisp FAQ. If you think of questions that are appropriate for this FAQ, or would like to improve an answer, please send email to us at lisp-faq@think.com. Note that the lisp-faq mailing list is for discussion of the content of the FAQ posting. It is not the place to ask questions about Lisp; use either the common-lisp@ai.sri.com mailing list or the comp.lang.lisp newsgroup for that. If a question appears frequently in one of those forums, it will get added to the FAQ list. There are currently five parts to the Lisp FAQ: 1. Introductory Matter and Bibliography of Introductions and References 2. General Questions 3. Common Programming Pitfalls 4. Lisp/Scheme Implementations and Mailing Lists 5. CLOS and PCL Questions 6. FTP Archives and Resources Part 4 is cross-posted to the comp.lang.scheme newsgroup. Part 5 is cross-posted to the comp.lang.clos newsgroup. Topics Covered (Part 1): [1-0] What is the purpose of this newsgroup? [1-1] What documentation is available on Lisp? How can I learn Lisp? [1-2] How can I improve my Lisp programming style and coding efficiency? [1-3] Where can I learn about implementing Lisp interpreters and compilers? [1-4] What does CLOS, PCL, X3J13, CAR, CDR, ... mean? [1-5] Where can I get a copy of the draft ANSI standard for Common Lisp? [1-6] Lisp Job Postings Topics Covered (Part 2): [2-1] Is there a GNU-Emacs interface to Lisp? [2-3] What is the equivalent of EXPLODE and IMPLODE in Common Lisp? [2-4] Is Lisp inherently slower than more conventional languages such as C? [2-5] Why does Common Lisp have "#'"? [2-6] How do I call non-Lisp functions from Lisp? [2-7] Can I call Lisp functions from other languages? [2-8] I want to call a function in a package that might not exist at compile time. How do I do this? [2-9] What is CDR-coding? [2-10] What is garbage collection? [2-11] How do I save an executable image of my loaded Lisp system? How do I run a Unix command in my Lisp? How do I get the current directory name from within a Lisp program? [2-12] I'm porting some code from a Symbolics Lisp machine to some other platform, and there are strange characters in the code. What do they mean? [2-13] History: Where did Lisp come from? [2-14] How do I find the argument list of a function? How do I get the function name from a function object? [2-15] How can I have two Lisp processes communicate via unix sockets? Common Pitfalls (Part 3): [3-0] Why does (READ-FROM-STRING "foobar" :START 3) return FOOBAR instead of BAR? [3-1] Why can't it deduce from (READ-FROM-STRING "foobar" :START 3) that the intent is to specify the START keyword parameter rather than the EOF-ERROR-P and EOF-VALUE optional parameters? [3-2] Why can't I apply #'AND and #'OR? [3-3] I used a destructive function (e.g. DELETE, SORT), but it didn't seem to work. Why? [3-4] After I NREVERSE a list, it's only one element long. After I SORT a list, it's missing things. What happened? [3-5] Why does (READ-LINE) return "" immediately instead of waiting for me to type a line? [3-6] I typed a form to the read-eval-print loop, but nothing happened. Why? [3-7] DEFMACRO doesn't seem to work. When I compile my file, LISP warns me that my macros are undefined functions, or complains "Attempt to call which is defined as a macro. [3-8] Name conflict errors are driving me crazy! (EXPORT, packages) [3-9] Closures don't seem to work properly when referring to the iteration variable in DOLIST, DOTIMES and DO. [3-10] What is the difference between FUNCALL and APPLY? [3-11] Miscellaneous things to consider when debugging code. [3-12] When is it right to use EVAL? [3-13] Why does my program's behavior change each time I use it? [3-14] When producing formatted output in Lisp, where should you put the newlines (e.g., before or after the line, FRESH-LINE vs TERPRI, ~& vs ~% in FORMAT)? [3-15] I'm using DO to do some iteration, but it doesn't terminate. Lisp/Scheme Implementations and Mailing Lists (Part 4): [4-0] Free Lisp implementations. [4-1] Commercial Lisp implementations. [4-2] Free Scheme implementations. [4-3] Commercial Scheme implementations. [4-4] Other Commercial Lisp-like Language implementations. [4-5] Where can I get an implementation of Prolog in Lisp? [4-6] What is Dylan? [4-7] What Lisp-related discussion groups and mailing lists exist? [4-8] What are R4RS and IEEE P1178? [4-9] How do I do object-oriented programming in Scheme? CLOS Questions (Part 5): [5-0] What is CLOS (PCL) and where can I get it? How do you pronounce CLOS? [5-1] What documentation is available about object-oriented programming in Lisp? [5-2] How I write a function that can access defstruct slots by name? I would like to write something like (STRUCTURE-SLOT '). [5-3] How can I list all the CLOS instances in a class? [5-4] How can I store data and CLOS instances (with possibly circular references) on disk so that they may be retrieved at some later time? [5-5] Given the name of a class, how can I get the names of its slots? FTP Resources (Part 6): [6-0] General information about FTP Resources for Lisp and Scheme [6-1] Repositories of Lisp Software [6-2] Repositories of Scheme Software [6-3] Publicly Redistributable Lisp Software [6-4] Publicly Redistributable Scheme Software [6-5] How can I use the X Window System or other GUIs from Lisp? [6-6] Formatting code in LaTeX Search for [#] to get to question number # quickly. Introduction: Certain questions and topics come up frequently in the various network discussion groups devoted to and related to Lisp. This file/article is an attempt to gather these questions and their answers into a convenient reference for Lisp programmers. It (or a reference to it) is posted periodically. The hope is that this will cut down on the user time and network bandwidth used to post, read and respond to the same questions over and over, as well as providing education by answering questions some readers may not even have thought to ask. This is not a Lisp tutorial, nor is it an exhaustive list of all Lisp intricacies. Lisp is a very powerful and expressive language, but with that power comes many complexities. This list attempts to address the ones that average Lisp programmers are likely to encounter. If you are new to Lisp, see the answer to the question "How can I learn Lisp?". The latest version of this file is available via anonymous FTP from CMU and Thinking Machines: To obtain the files from CMU, connect by anonymous ftp to any CMU CS machine (e.g., ftp.cs.cmu.edu [128.2.206.173]), using username "anonymous" and password "name@host". The files lisp-faq-1.text, lisp-faq-2.text, lisp-faq-3.text, lisp-faq-4.text and lisp-faq-5.text are located in the directory /afs/cs.cmu.edu/user/mkant/Public/Lisp-Utilities/ [Note: You must cd to this directory in one atomic operation, as some of the superior directories on the path are protected from access by anonymous ftp.] If your site runs the Andrew File System, you can just cp the files directly without bothering with FTP. To obtain the files from Thinking Machines, ftp them from ftp.think.com, in the directory /public/think/lisp/. The file faq.text contains all the parts of the FAQ in one file. In addition, specific versions of the FAQ are available as faq-.text. Unless otherwise specified, the Lisp dialect referred to is Common Lisp, as defined by "Common Lisp: the Language" (aka "CLtL1") as well as corrections (but not enhancements) from "Common Lisp: the Language, 2nd Edition" (aka "CLtL2"), both by Guy L. Steele, Jr. and published by Digital Press. Note that CLtL2 is NOT an official specification for the language; ANSI Committee X3J13 is preparing such a specification. See question [1-5] for information on the status of the ANSI specification for Common Lisp. Enhancements such as CLOS, conditions, and the LOOP macro will be referred to separately. ---------------------------------------------------------------- [1-0] What is the purpose of this newsgroup? The newsgroup comp.lang.lisp exists for general discussion of topics related to the programming language Lisp. For example, possible topics can include (but are not necessarily limited to): announcements of Lisp books and products discussion of programs and utilities written in Lisp discussion of portability issues questions about possible bugs in Lisp implementations problems porting an implementation to some architecture Postings should be of general interest to the Lisp community. See also question [4-7]. Questions about object oriented programming in Lisp should be directed to the newsgroup comp.lang.clos. Similarly, questions about the programming language Scheme should be directed to the newsgroup comp.lang.scheme. Discussion of functional programming language issues should be directed to the newsgroup comp.lang.functional. Discussion of AI programs implemented in Lisp should sometimes be cross-posted to the newsgroup comp.ai. ---------------------------------------------------------------- [1-1] What documentation is available on Lisp? How can I learn Lisp? There are several good Lisp introductions and tutorials: 1. David S. Touretzky "Common Lisp: A Gentle Introduction to Symbolic Computation" Benjamin/Cummings Publishers, 1990. 384 pages. Perhaps the best tutorial introduction to the language. It has clear and correct explanations, and covers some fairly advanced topics. The book is an updated Common Lisp version of the 1984 edition published by Harper and Row Publishers. Three free Lisp educational tools which were used in the book -- Evaltrace, DTRACE and SDRAW -- are available by anonymous ftp from b.gp.cs.cmu.edu:/usr/dst/public/{lisp,evaltrace}. Evaltrace is a graphical notation for explaining how evaluation works and is described in "Visualizing Evaluation in Applicative Languages" by David S. Touretzky and Peter Lee, CACM 45-59, October 1992. DTRACE is a "detailed trace" which provides more information than the tracing tools provided with most Common Lisp implementations. SDRAW is a program that draws cons cell structures both for X11 and ascii terminals. 2. Robert Wilensky "Common LISPcraft" W. W. Norton, 1986. 385 pages. 3. Wade L. Hennessey "Common Lisp" McGraw-Hill, 1989. 395 pages. Fairly good, but jumps back and forth from the simple to the complex rather quickly, with no clear progression in difficulty. 4. Laurent Siklossy "Let's Talk LISP" Prentice-Hall, NJ, 1976. 237 pages. Good introduction, but quite out of date. 5. Stuart C. Shapiro "Common Lisp: An Interactive Approach" Computer Science Press/W.H. Freeman, New York, 1992. ISBN 0-7167-8218-9 Other introductions to Lisp include: 1. A. A. Berk. "LISP, The Language of Artificial Intelligence" Van Nostrand Reinhold, 1985. 160 pages. 2. Paul Y. Gloess. "An Alfred handy guide to Understanding LISP" Alfred Publishers (Sherman Oaks, CA), 1982. 64 pages. 3. Ward D. Maurer. "The Programmer's Introduction to LISP" American Elsevier, 1972. 112 pages. 4. Hank Bromley and Richard Lamson. "LISP Lore: A Guide to Programming the LISP Machine" Kluwer Academic (Boston), 1987. 337 pages. 5. Sharam Hekmatpour. "Introduction to LISP and Symbol Manipulation" Prentice Hall (New York), 1988. 303 pages. 6. Deborah G. Tatar "A programmer's guide to Common Lisp" Digital Press, 1987. 327 pages. ISBN 0-932376-87-8. Good introduction on Common Lisp. 7. Timothy Koschmann "The Common Lisp Companion" John Wiley & Sons, 1990. Targeted for those with some programming experience who wish to learn draft-ANSI Common Lisp, including CLOS and the CL condition system. Examples progress incrementally from simple numerical calculation all the way to a logic-programming extension to CL. More advanced introductions to Lisp and its use in Artificial Intelligence include: 1. Peter Norvig. "Paradigms of AI Programming: Case Studies in Common Lisp" Morgan Kaufmann, 1992. 946 pages. ISBN 1-55860-191-0. Provides an in-depth exposition of advanced AI programming techniques and includes large-scale detailed examples. The book is the most advanced AI/Common-Lisp programming text and reference currently available, and hence is not for the complete novice. It focuses on the programming techniques necessary for building large AI systems, including object-oriented programming, and has a strong performance orientation. The text is marked by its use of "non-toy" examples to illustrate the techniques. All of the examples are written in Common Lisp, and copies of the source code are available by anonymous ftp from unix.sri.com:pub/norvig and on disk in Macintosh or DOS format from the publisher. Some of the techniques described include rule-based pattern matching (GPS, Eliza, a subset of Macsyma, the Emycin expert system shell), constraint propagation and backtracking (Waltz line-labelling), alpha-beta search (Othello), natural language processing (top-down, bottom-up and chart parsing), logic-programming (unification and Prolog), interpreters and compilers for Scheme, and object-oriented programming (CLOS). The examples are also used to illustrate good programming style and efficiency. There is a guide to trouble-shooting and debugging Lisp programs, a style guide, and a discussion of portability problems. Some of the efficiency techniques described include memoization, data indexing, compilation, delaying computation, proper use of declarations, avoiding garbage collection, and choosing and using the correct data structure. The book also serves as an advanced introduction to Common Lisp, with sections on the Loop macro, CLOS and sequences, and some coverage of error H~r}ndling, series, and the package facility. /hand }i 2. Eugene Charniak, Christopher K. Riesbeck, Drew V. McDermott and James R. Meehan. "Artificial Intelligence Programming", 2nd edition. Lawrence Erlbaum Associates (Hillsdale, NJ), 1987. 533 pages. Provides many nice code fragments, all of which are written in Common Lisp. The first half of the book covers topics like macros, the reader, data structures, control structures, and defstructs. The second half of the book describes programming techniques specific to AI, such as discrimination nets, production systems, deductive database retrieval, logic programming, and truth maintenance. 3. Patrick H. Winston and Berthold K. P. Horn. "LISP", 3rd edition. Addison-Wesley (Reading, MA), 1989. 611 pages. ISBN 0-201-08319-1 Covers the basic concepts of the language, but also gives a lot of detail about programming AI topics such as rule-based expert systems, forward chaining, interpreting transition trees, compiling transition trees and finding patterns in images. Not a tutorial. Has many good examples. 4. Rodney A. Brooks. "Programming in Common Lisp" Wiley, 1985. 303 pages. 5. John R. Anderson, Albert T. Corbett, and Brian J. Reiser. "Essential LISP" Addison-Wesley (Reading, MA), 1987. 352 pages. Concentrates on how to use Lisp with iteration and recursion. 6. Robert D. Cameron and Anthony H. Dixon "Symbolic Computing with Lisp" Prentice-Hall, 1992, 326 pages. ISBN 0-13-877846-9. The book is intended primarily as a third-year computer science text. In terms of programming techniques, it emphasizes recursion and induction, data abstraction, grammar-based definition of Lisp data structures and functional programming style. It uses two Lisp languages: (1) a purely functional subset of Lisp called Small Lisp and (2) Common Lisp. An MS-DOS interpreter for Small Lisp (including source) is provided with the book. It considers applications of Lisp to formal symbolic data domains: algebraic expressions, logical formulas, grammars and programming languages. 7. Hasemer and Domingue. "Common Lisp Programming for Artificial Intelligence" Addison-Wesley, 1989. 8. Steven Tanimoto "The Elements of Artificial Intelligence: An Introduction Using Lisp" Computer Science Press, Rockville, MD, 1987, 530 pages. 9. Patrick R. Harrison "Common Lisp and Artificial Intelligence" Prentice Hall, 1990. ISBN 0-13-155243 10. Rajeev Sangal "Programming Paradigms in Lisp" McGraw-Hill, 1991. ISBN 0-07-054666-5. General Lisp reference books include: 1. Guy L. Steele "Common Lisp: The Language" [CLtL1] Digital Press, 1984. 465 pages. ISBN 0-932376-41-X. 2. Guy L. Steele "Common Lisp: The Language, 2nd Edition" [CLtL2] Digital Press, 1990. 1029 pages. ISBN 1-55558-041-6. 3. Franz Inc. "Common Lisp: The Reference" Addison-Wesley, Reading, MA 1988. ISBN 0-201-11458-5 Entries on lisp functions in alphabetical order. 4. K. Dybvig. "The Scheme programming language" Prentice Hall, 1987. Good reference for Scheme. Lisp periodicals include: 1. LISP Pointers. Published by ACM SIGPLAN six times a year. Volume 1, Number 1 was April-May 1987. 2. LISP and Symbolic Computation, Kluwer Academic Press. Volume 1 was published in 1989. (jlz@lucid.com is the editor). ISSN 0892-4635. Subscriptions: Institutions $169; Individuals $80. Add $8 for air mail. Kluwer Academic Publishers, PO Box 322, 3300 AH Dordrecht, The Netherlands, or Kluwer Academic Publishers, PO Box 358, Accord Station, Hingham, MA 02018-0358. 3. Proceedings of the biannual ACM Lisp and Functional Programming Conference. (First one was in 1980.) 4. Proceedings of the annual Lisp Users and Vendors Conference. Implementation-specific questions: 1. Lucid. See the wizards.doc file that comes with the Lucid release. It describes functions, macros, variables and constants that are not official parts of the product and are not supported. Constructs described in this file include: the interrupt facility, the source file recording facility, the resource facility, multitasking, writing your own streams, lisp pipes, i/o buffers, the compiler, floating-point functions, memory management, debugger information, the window tool kit, extensions to the editor, the foreign function interface, clos information, delivery toolkit information, and Lucid lisp training classes. The wizards.doc file also covers i/o constructs, functions for dealing with DEFSTRUCT, functions and constants for dealing with procedure objects, functions and constants for dealing with code objects, function for mapping objects, additional keyword argument to DISKSAVE, function used in the implementation of arrays, function for monitor-specific behavior for a process, additional keyword argument to RUN-PROGRAM, and load-time evaluation. Introductions to Scheme (Many books on Scheme are worth reading even if you use Common Lisp, because many of the issues are similar): 1. Harold Abelson and Gerald Jay Sussman, with Julie Sussman. "Structure and Interpretation of Computer Programs" MIT Press (Cambridge, MA) and McGraw-Hill (New York), 1985. 542 pages. ISBN 0-262-01077-1 Starts off introductory, but rapidly gets into powerful Lisp-particular constructs, such as using closures and engines, building interpreters, compilers and object-oriented systems. 2. Daniel P. Friedman and M. Felleisen. "The Little LISPer" MIT Press (Cambridge, MA), 1987. ISBN 0-262-56038-0. Science Research Associates (Chicago), 3rd ed, 1989. 206 pages. Good for a quick introduction. Uses Scheme instead of Common Lisp. (SRA edition uses a dialect of Scheme with footnotes about translating to Scheme or Common Lisp. The MIT Press edition is in Scheme without the footnotes.) 3. George Springer and Daniel P. Friedman "Scheme and the Art of Programming" MIT Press and McGraw Hill, 1990, 596 pages. Introduces basic concepts of programming in Scheme. Also deals with object oriented programming, co-routining, continuations. 4. Wolfgang Kreutzer and Bruce McKenzie "Programming for Artificial Intelligence: Methods, Tools and Applications" Addison-Wesley (Reading, MA), 1990. 682 pages. ISBN 0-201-41621-2. Discusses Scheme, Prolog, and Smalltalk, gives an overview of the history and philosophy of AI, surveys three major programming paradigms (procedural, declarative, and object-oriented), and metaphors to AI programming. 5. Smith "Introduction to Scheme" 1988. Focuses on PC Scheme. 6. Michael Eisenberg "Programming in Scheme" Scientific Press (Redwood City, CA), 1988. 304 pages. 7. The Ken Dickey article, "The Scheme Programming Language", in COMPUTER LANGUAGES magazine, and the Revised^4 Report on the Algorithmic Language Scheme, both of which are available by anonymous ftp from the scheme archive at nexus.yorku.ca. 8. Two articles in BYTE Magazine, February 1988, by Abelson and Sussman, and Clinger. 9. The Info files from the MIT Scheme implementation. Special Topics: Garbage Collection: Wilson, Paul R., "Uniprocessor Garbage Collection Techniques" Proceedings of the 1992 International Workshop on Memory Management. Surveys garbage collection techniques. Available by anonymous ftp from cs.utexas.edu:pub/garbage/gcsurvey.ps. Contact wilson@cs.utexas.edu for more info. ---------------------------------------------------------------- [1-2] How can I improve my Lisp programming style and coding efficiency? There are several books about Lisp programming style, including: 1. Molly M. Miller and Eric Benson "Lisp Style and Design" Digital Press, 1990. 214 pages. ISBN 1-55558-044-0. How to write large Lisp programs and improve Lisp programming style. Uses the development of Lucid CL as an example. 2. Robin Jones, Clive Maynard, and Ian Stewart. "The Art of Lisp Programming" Springer-Verlag, 1989. 169 pages. 3. W. Richard Stark. "LISP, Lore, and Logic: an algebraic view of LISP programming, foundations, and applications" Springer-Verlag, 1990. 278 pages. ISBN 0-387-97072-X Self-modifying code, self-reproducing programs, etc. 4. CMU CL User's Manual, Chapter 7, (talks about writing efficient code). It is available by anonymous ftp from any CMU CS machine (e.g., ftp.cs.cmu.edu [128.2.206.173]) as the file /afs/cs.cmu.edu/project/clisp/docs/cmu-user/cmu-user.ps [when getting this file by anonymous ftp, one must cd to the directory in one atomic operation, as some of the superior directories on the path are protected from access by anonymous ftp.] 5. See also Norvig's book, SICP (Abelson & Sussman), SAP (Springer and Friedman). 6. Hallvard Tretteberg's Lisp Style Guide is available by anonymous ftp in ftp.think.com:/public/think/lisp/style-guide.text. There is a fair bit of overlap between Hallvard's style guide and the notes below and in part 3 of this FAQ. Here are some general suggestions/notes about improving Lisp programming style, readability, correctness and efficiency: General Programming Style Rules: - Write short functions, where each function provides a single, well-defined operation. Small functions are easier to read, write, test, debug, and understand. - Use descriptive variable and function names. If it isn't clear from the name of a function or variable what its purpose is, document it with a documentation string and a comment. In fact, even if the purpose is evident from the name, it is still worth documenting your code. - Don't write Pascal (or C) code in Lisp. Use the appropriate predefined functions -- look in the index to CLtL2, or use the APROPOS and DESCRIBE functions. Don't put a close parenthesis on a line by itself -- this can really aggravate programmers who grew up on Lisp. Lisp-oriented text editors include tools for ensuring balanced parentheses and for moving across pairs of balanced parentheses. - Use proper indentation -- you should be able to understand the structure of your definitions without noticing the parentheses. The following functions often abused or misunderstood by novices. Think twice before using any of these functions. - EVAL. Novices almost always misuse EVAL. When experts use EVAL, they often would be better off using APPLY, FUNCALL, or SYMBOL-VALUE. Use of EVAL when defining a macro should set off a warning bell -- macro definitions are already evaluated during expansion. See also the answer to question 3-12. - PROGV. PROGV binds dynamic variables and is often misused in conjunction with EVAL, which uses the dynamic environment. In general, avoid unnecessary use of special variables. PROGV is mainly for writing interpreters for languages embedded in Lisp. If you want to bind a list of values to a list of lexical variables, use (MULTIPLE-VALUE-BIND (..) (VALUES-LIST ..) ..) or (MULTIPLE-VALUE-SETQ (..) (VALUES-LIST ..)) instead. Most decent compilers can optimize this expression. However, use of this idiom is not to be encouraged unless absolutely necessary. - CATCH and THROW. Often a named BLOCK and RETURN-FROM are more appropriate. Use UNWIND-PROTECT when necessary. - Destructive operations, such as NCONC, SORT, DELETE, RPLACA, and RPLACD, should be used carefully and sparingly. In general, trust the garbage collector: allocate new data structures when you need them. To improve the readability of your code, - Don't use any C{A,D}R functions with more than two letters between the C and the R. When nested, they become hard to read. If you have complex data structures, you are often better off describing them with a DEFSTRUCT, even if the type is LIST. If you must use C{A,D}R, try to use destructuring-bind instead, or at least SECOND, THIRD, NTH, NTHCDR, etc. - Use COND instead of IF and PROGN. In general, don't use PROGN if there is a way to write the code within an implicit PROGN. For example, (IF (FOO X) (PROGN (PRINT "hi there") 23) 34) should be written using COND instead. - Never use a 2-argument IF or a 3-argument IF with a second argument of NIL unless you want to emphasize the return value; use WHEN and UNLESS instead. You will want to emphasize the return value when the IF clause is embedded within a SETQ, such as (SETQ X (IF (EQ Y Z) 2 NIL)). If the second argument to IF is the same as the first, use OR instead: (OR P Q) rather than (IF P P Q). Use UNLESS instead of (WHEN (NOT ..) ..) but not instead of (WHEN (NULL ..) ..). - Use COND instead of nested IF statements. Be sure to check for unreachable cases, and eliminate those cond-clauses. - Use backquote, rather than explicit calls to LIST, CONS, and APPEND, whenever writing a form which produces a Lisp form, but not as a general substitute for LIST, CONS and APPEND. LIST, CONS and APPEND usually allocate new storage, but lists produced by backquote may involve destructive modification (e.g., ,.). - Make the names of special (global) variables begin and end with an asterisk (*): (DEFVAR *GLOBAL-VARIABLE*) Some programmers will mark the beginning and end of an internal global variable with a percent (%) or a period (.). Make the names of constants begin and end with a plus (+): (DEFCONSTANT +E+ 2.7182818) This helps distinguish them from lexical variables. Some people prefer to use macros to define constants, since this avoids the problem of accidentally trying to bind a symbol declared with defconstant. - If your program is built upon an underlying substrate which is implementation-dependent, consider naming those functions and macros in a way that visually identifies them, either by placing them in their own package, or prepending a character like a %, ., or ! to the function name. Note that many programmers use the $ as a macro character for slot access, so it should be avoided unless you're using it for that purpose. - Don't use property lists. Instead, use an explicit hash table. This helps avoid problems caused by the symbol being in the wrong package, accidental reuse of property keys from other programs, and allows you to customize the structure of the table. - Use the most specific construct that does the job. This lets readers of the code see what you intended when writing the code. For example, don't use SETF if SETQ will do (e.g., for lexical variables). Use the most specific predicate to test your conditions. If you intend for a function to be a predicate, have it return T for true, not just non-NIL. - When NIL is used as an empty list, use () in your code. When NIL is used as a boolean, use NIL. Similarly, use NULL to test for an empty list, NOT to test a logical value. Use ENDP to test for the end of a list, not NULL. - Don't use the &AUX lambda-list keyword. It is always clearer to define local variables using LET or LET*. - When using RETURN and RETURN-FROM to exit from a block, don't use (VALUES ..) when returning only one value, except if you are using it to suppress extra multiple values from the first argument. - If you want a function to return no values (i.e., equivalent to VOID in C), use (VALUES) to return zero values. This signals to the reader that the function is used mainly for side-effects. - (VALUES (VALUES 1 2 3)) returns only the first value, 1. You can use (VALUES (some-multiple-value-function ..)) to suppress the extra multiple values from the function. Use MULTIPLE-VALUE-PROG1 instead of PROG1 when the multiple values are significant. - When using MULTIPLE-VALUE-BIND and DESTRUCTURING-BIND, don't rely on the fact that NIL is used when values are missing. This is an error in some implementations of DESTRUCTURING-BIND. Instead, make sure that your function always returns the proper number of values. Documentation: - Comment your code. Use three semicolons in the left margin before the definition for major explanations. Use two semicolons that float with the code to explain the routine that follows. Two semicolons may also be used to explain the following line when the comment is too long for the single semicolon treatment. Use a single semicolon to the right of the code to explain a particular line with a short comment. The number of semicolons used roughly corresponds with the length of the comment. Put at least one blank line before and after top-level expressions. - Include documentation strings in your code. This lets users get help while running your program without having to resort to the source code or printed documentation. Issues related to macros: - Never use a macro instead of a function for efficiency reasons. Declaim the function as inline -- for example, (DECLAIM (INLINE ..)) This is *not* a magic bullet -- be forewarned that inline expansions can often increase the code size dramatically. INLINE should be used only for short functions where the tradeoff is likely to be worthwhile: inner loops, types that the compiler might do something smart with, and so on. - When defining a macro that provides an implicit PROGN, use the &BODY lambda-list keyword instead of &REST. - Use gensyms for bindings within a macro, unless the macro lets the user explicitly specify the variable. For example: (defmacro foo ((iter-var list) body-form &body body) (let ((result (gensym "RESULT"))) `(let ((,result nil)) (dolist (,iter-var ,list ,result) (setq ,result ,body-form) (when ,result ,@body))))) This avoids errors caused by collisions during macro expansion between variable names used in the macro definition and in the supplied body. - Use a DO- prefix in the name of a macro that does some kind of iteration, WITH- when the macro establishes bindings, and DEFINE- or DEF- when the macro creates some definitions. Don't use the prefix MAP- in macro names, only in function names. - Don't create a new iteration macro when an existing function or macro will do. - Don't define a macro where a function definition will work just as well -- remember, you can FUNCALL or MAPCAR a function but not a macro. - The LOOP and SERIES macros generate efficient code. If you're writing a new iteration macro, consider learning to use one of them instead. File Modularization: - If your program involves macros that are used in more than one file, it is generally a good idea to put such macros in a separate file that gets loaded before the other files. The same things applies to primitive functions. If a macro is complicated, the code that defines the macro should be put into a file by itself. In general, if a set of definitions form a cohesive and "independent" whole, they should be put in a file by themselves, and maybe even in their own package. It isn't unusual for a large Lisp program to have files named "site-dependent-code", "primitives.lisp", and "macros.lisp". If a file contains primarily macros, put "-macros" in the name of the file. Stylistic preferences: - Use (SETF (CAR ..) ..) and (SETF (CDR ..) ..) in preference to  RPLACA and RPLACD. Likewise (SETF (GET ..) ..) instead of PUT. - Use INCF, DECF, PUSH and POP instead instead of the corresponding SETF forms. - Many programmers religiously avoid using CATCH, THROW, BLOCK, PROG, GO and TAGBODY. Tags and go-forms should only be necessary to create extremely unusual and complicated iteration constructs. In almost every circumstance, a ready-made iteration construct or recursive implementation is more appropriate. - Don't use LET* where LET will do. Don't use LABELS where FLET will do. Don't use DO* where DO will do. - Don't use DO where DOTIMES or DOLIST will do. - If you like using MAPCAR instead of DO/DOLIST, use MAPC when no result is needed -- it's more efficient, since it doesn't cons up a list. If a single cumulative value is required, use REDUCE. If you are seeking a particular element, use FIND, POSITION, or MEMBER. - If using REMOVE and DELETE to filter a sequence, don't use the :test-not keyword or the REMOVE-IF-NOT or DELETE-IF-NOT functions. Use COMPLEMENT to complement the predicate and the REMOVE-IF or DELETE-IF functions instead. - Use complex numbers to represent points in a plane. - Don't use lists where vectors are more appropriate. Accessing the nth element of a vector is faster than finding the nth element of a list, since the latter requires pointer chasing while the former requires simple addition. Vectors also take up less space than lists. Use adjustable vectors with fill-pointers to implement a stack, instead of a list -- using a list continually conses and then throws away the conses. - When adding an entry to an association list, use ACONS, not two calls to CONS. This makes it clear that you're using an alist. - If your association list has more than about 10 entries in it, consider using a hash table. Hash tables are often more efficient. - When you don't need the full power of CLOS, consider using structures instead. They are often faster, take up less space, and easier to use. - Use PRINT-UNREADABLE-OBJECT when writing a print-function. - Use WITH-OPEN-FILE instead of OPEN and CLOSE. - When a HANDLER-CASE clause is executed, the stack has already unwound, so dynamic bindings that existed when the error occured may no longer exist when the handler is run. Use HANDLER-BIND if you need this. - When using CASE and TYPECASE forms, if you intend for the form to return NIL when all cases fail, include an explicit OTHERWISE clause. If it would be an error to return NIL when all cases fail, use ECASE, CCASE, ETYPECASE or CTYPECASE instead. - Use local variables in preference to global variables whenever possible. Do not use global variables in lieu of parameter passing. Global variables can be used in the following circumstances: * When one function needs to affect the operation of another, but the second function isn't called by the first. (For example, *load-pathname* and *break-on-warnings*.) * When a called function needs to affect the current or future operation of the caller, but it doesn't make sense to accomplish this by returning multiple values. * To provide hooks into the mechanisms of the program. (For example, *evalhook*, *, /, and +.) * Parameters which, when their value is changed, represent a major change to the program. (For example, *print-level* and *print-readably*.) * For state that persists between invocations of the program. Also, for state which is used by more than one major program. (For example, *package*, *readtable*, *gensym-counter*.) * To provide convenient information to the user. (For example, *version* and *features*.) * To provide customizable defaults. (For example, *default-pathname-defaults*.) * When a value affects major portions of a program, and passing this value around would be extremely awkward. (The example here is output and input streams for a program. Even when the program passes the stream around as an argument, if you want to redirect all output from the program to a different stream, it is much easier to just rebind the global variable.) Correctness and efficiency issues: - In CLtL2, IN-PACKAGE does not evaluate its argument. Use defpackage to define a package and declare the external (exported) symbols from the package. - The ARRAY-TOTAL-SIZE-LIMIT may be as small as 1024, and the CALL-ARGUMENTS-LIMIT may be as small as 50. - Novices often mistakenly quote the conditions of a CASE form. For example, (case x ('a 3) ..) is incorrect. It would return 3 if x were the symbol QUOTE. Use (case x (a 3) ..) instead. - Avoid using APPLY to flatten lists. (apply #'append list-of-lists) is compiled into a function call, and can run into problems with the CALL-ARGUMENTS-LIMIT. Use REDUCE or MAPCAR instead: (reduce #'append list-of-lists :from-end t) (mapcan #'copy-list list-of-lists) The second will often be more efficient (see note below about choosing the right algorithm). Beware of calls like (apply f (mapcar ..)). - NTH must cdr down the list to reach the elements you are interested in. If you don't need the structural flexibility of lists, try using vectors and the ELT function instead. - Don't use quoted constants where you might later destructively modify them. For example, instead of writing '(c d) in (defun foo () (let ((var '(c d))) ..)) write (list 'c 'd) instead. Using a quote here can lead to unexpected results later. If you later destructively modify the value of var, this is self-modifying code! Some Lisp compilers will complain about this, since they like to make constants read-only. Modifying constants has undefined results in ANSI CL. See also the answer to question [3-13]. Similarly, beware of shared list structure arising from the use of backquote. Any sublist in a backquoted expression that doesn't contain any commas can share with the original source structure. - Don't proclaim unsafe optimizations, such as (proclaim '(optimize (safety 0) (speed 3) (space 1))) since this yields a global effect. Instead, add the optimizations as local declarations to small pieces of well-tested, performance-critical code: (defun well-tested-function () (declare (optimize (safety 0) (speed 3) (space 1))) ..) Such optimizations can remove run-time type-checking; type-checking is necessary unless you've very carefully checked your code and added all the appropriate type declarations. - Some programmers feel that you shouldn't add declarations to code until it is fully debugged, because incorrect declarations can be an annoying source of errors. They recommend using CHECK-TYPE liberally instead while you are developing the code. On the other hand, if you add declarations to tell the compiler what you think your code is doing, the compiler can then tell you when your assumptions are incorrect. Declarations also make it easier for another programmer to read your code. - Don't change the compiler optimization with an OPTIMIZE proclamation or declaration until the code is fully debugged and profiled. When first writing code you should say (declare (optimize (safety 3))) regardless of the speed setting. - Depending on the optimization level of the compiler, type declarations are interpreted either as (1) a guarantee from you that the variable is always bound to values of that type, or (2) a desire that the compiler check that the variable is always bound to values of that type. Use CHECK-TYPE if (2) is your intention. - If you get warnings about unused variables, add IGNORE declarations if appropriate or fix the problem. Letting such warnings stand is a sloppy coding practice. To produce efficient code, - choose the right algorithm. For example, consider seven possible implementations of COPY-LIST: (defun copy-list (list) (let ((result nil)) (dolist (item list result) (setf result (append result (list item)))))) (defun copy-list (list) (let ((result nil)) (dolist (item list (nreverse result)) (push item result)))) (defun copy-list (list) (mapcar #'identity list)) (defun copy-list (list) (let ((result (make-list (length list)))) (do ((original list (cdr original)) (new result (cdr new))) ((null original) result) (setf (car new) (car original))))) (defun copy-list (list) (when list (let* ((result (list (car list))) (tail-ptr result)) (dolist (item (cdr list) result) (setf (cdr tail-ptr) (list item)) (setf tail-ptr (cdr tail-ptr)))))) (defun copy-list (list) (loop for item in list collect item)) (defun copy-list (list) (if (consp list) (cons (car list) (copy-list (cdr list))) list)) The first uses APPEND to tack the elements onto the end of the list. Since APPEND must traverse the entire partial list at each step, this yields a quadratic running time for the algorithm. The second implementation improves on this by iterating down the list twice; once to build up the list in reverse order, and the second time to reverse it. The efficiency of the third depends on the Lisp implementation, but it is usually similar to the second, as is the fourth. The fifth algorithm, however, iterates down the list only once. It avoids the extra work by keeping a pointer (reference) to the last cons of the list and RPLACDing onto the end of that. Use of the fifth algorithm may yield a speedup. Note that this contradicts the earlier dictum to avoid destructive functions. To make more efficient code one might selectively introduce destructive operations in critical sections of code. Nevertheless, the fifth implementation may be less efficient in Lisps with cdr-coding, since it is more expensive to RPLACD cdr-coded lists. Depending on the implementation of nreverse, however, the fifth and second implementations may be doing the same amount of work. The sixth example uses the Loop macro, which usually expands into code similar to the third. The seventh example copies dotted lists, and runs in linear time. It's equivalent to the other linear-time examples in a lisp that is properly tail-recursive. - use type declarations liberally in time-critical code, but only if you are a seasoned Lisp programmer. Appropriate type declarations help the compiler generate more specific and optimized code. It also lets the reader know what assumptions were made. For example, if you only use fixnum arithmetic, adding declarations can lead to a significant speedup. If you are a novice Lisp programmer, you should use type declarations sparingly, as there may be no checking to see if the declarations are correct. Wrong declarations can lead to errors in otherwise correct code, and can limit the reuse of code in other contexts. Depending on the Lisp compiler, it may also be necessary to declare the type of results using THE, since some compilers don't deduce the result type from the inputs. - check the code produced by the compiler by using the disassemble function ---------------------------------------------------------------- [1-3] Where can I learn about implementing Lisp interpreters and compilers? Books about Lisp implementation include: 1. John Allen "Anatomy of Lisp" McGraw-Hill, 1978. 446 pages. ISBN 0-07-001115-X 2. Samuel Kamin "Programming Languages, An Interpreter-Based Approach" Addison-Wesley. ISBN 0-201-06824-9 Includes sources to several interpreters for Lisp-like languages, and a pointer to sources via anonymous ftp. 3. Sharam Hekmatpour "Lisp: A Portable Implementation" Prentice Hall, 1985. ISBN 0-13-537490-X. Describes a portable implementation of a small dynamic Lisp interpreter (including C source code). 4. Peter Henderson "Functional Programming: Application and Implementation" Prentice-Hall (Englewood Cliffs, NJ), 1980. 355 pages. 5. Peter M. Kogge "The Architecture of Symbolic Computers" McGraw-Hill, 1991. ISBN 0-07-035596-7. Includes sections on memory management, the SECD and Warren Abstract Machines, and overviews of the various Lisp Machine architectures. 6. Daniel P. Friedman, Mitchell Wand, and Christopher T. Haynes "Essentials of Programming Languages" MIT Press, 1992, 536 pages. ISBN 0-262-06145-7. Teaches fundamental concepts of programming language design by using small interpreters as examples. Covers most of the features of Scheme. Includes a discussion of parameter passing techniques, object oriented languages, and techniques for transforming interpreters to allow their implementation in terms of any low-level language. Also discusses scanners, parsers, and the derivation of a compiler and virtual machine from an interpreter. Source files available by anonymous ftp from cs.indiana.edu in the directory /pub/eopl (129.79.254.191). 7. Also see the proceedings of the biannual ACM Lisp and Functional Programming conferences, and the implementation notes for CMU Common Lisp. ---------------------------------------------------------------- [1-4] What does CLOS, PCL, X3J13, CAR, CDR, ... mean? Glossary of acronyms: CAR Originally meant "Contents of Address portion of Register", which is what CAR actually did on the IBM 704. CDR Originally meant "Contents of Decrement portion of Register", which is what CDR actually did on the IBM 704. Pronounced "Cudder". LISP Originally from "LISt Processing" GUI Graphical User Interface CLOS Common Lisp Object System. The object oriented programming standard for Common Lisp. Based on Symbolics FLAVORS and Xerox LOOPS, among others. Pronounced either as "See-Loss" or "Closs". See also PCL. PCL Portable Common Loops. A portable CLOS implementation. Available by anonymous ftp from parcftp.xerox.com:pcl/. LOOPS Lisp Object Oriented Programming System. A predecessor to CLOS on Xerox Lisp machines. X3J13 Subcommittee of the ANSI committee X3 which is working on the ANSI Standardization of Common Lisp. ANSI American National Standards Institute CL Common Lisp SC22/WG16 The full name is ISO/IEC JTC 1/SC 22/WG 16. It stands for International Organization for Standardization/International Electronics(?) Congress(?) Joint Technical Committee 1, Subcommittee 22, Working Group 16. This long-winded name is the ISO working group working on an international Lisp standard, (i.e., the ISO analogue to X3J13). CLtL1 First edition of Guy Steele's book, "Common Lisp the Language". CLtL2 Second edition of Guy Steele's book, "Common Lisp the Language". SICP Abelson and Sussman's book "Structure and Interpretation of Computer Programs". SCOOPS An experimental object-oriented programming language for Scheme. R3RS Revised^3 Report on the Algorithmic Language Scheme. R4RS Revised^4 Report on the Algorithmic Language Scheme. ---------------------------------------------------------------- [1-5] Where can I get a copy of the draft ANSI standard for Common Lisp? The draft proposed American National Standard for Common Lisp is under public review until November 23, 1992. Hard copies of the draft may be purchased from Global Engineering Documents, Inc., 2805 McGaw Avenue, Irvine, CA 92714, 1-800-854-7179, 714-261-1455 for a single copy price of $80 ($104 international). Copies of the TeX sources and Unix-compressed DVI files may be obtained by anonymous FTP from parcftp.xerox.com in the directory /pub/cl/document/*. The file Reviewer-Notes.text should be read before ftp'ing the other files. There is no mechanism for submitting Public Review comments by e-mail. Comments on the draft must be submitted in hard copy format BOTH to X3 Secretariat, Attn: Lynn Barra, 1250 Eye Street NW, Suite 200, Washington, DC 20005-3922 AND to American National Standards Institute, Attn: BSR Center, 11 West 42nd St. 13th Floor, New York, NY 10036. ---------------------------------------------------------------- [1-6] Lisp Job Postings The LISP-JOBS mailing list exists to help programmers find Lisp programming positions, and to help companies with Lisp programming positions find capable Lisp programmers. (Lisp here means Lisp-like languages, including Scheme.) Material appropriate for the list includes Lisp job announcements and resumes from Lisp programmers (which should be sent only once) should be sent to lisp-jobs@amc.com. Administrative requests (e.g., to be added to the list) should be sent to lisp-jobs-request@amc.com. ---------------------------------------------------------------- ;;; ******************************** ;;; Change Log ********************* ;;; ******************************** ;;; Date Who Ver Reason ;;; ------------------------------------------------------------ ;;; 7-FEB-92 mk 1.0 Initial release. ;;; 10-FEB-92 mk 1.1 Pre-release corrections and additions. ;;; 10-FEB-92 mk 1.11 Minor changes from Arun Welch, Mitch Marks, ;;; Mike Meyer, Matthias Felleisen, and John Gateley. ;;; 11-FEB-92 mk 1.12 Corrections by John Carroll, Jason Trenouth, Joel ;;; Riedesel, David Neves, Lawrence Mayka and ;;; Bruce Miller. ;;; 13-FEB-92 mk 1.13 Renumbering. Split into 3 files. Some more FAQs. ;;; 23-MAR-92 mk 1.14 Updated various FTP entries, bug in EXPLODE. ;;; Updated harlequin entry. ;;; 25-MAR-92 mk 1.15 Added question [2-18]: saving data and CLOS ;;; instances to disk for later retrieval. ;;; 1-MAY-92 mk 1.17 Added entry for Feel to question [1-5]. Updated CMU ;;; ftp machines to point to ftp.cs.cmu.edu. Fixed CMU ;;; CL entry to be approximately version independent. ;;; Revised entry on Garnet. uunet.uu.net -> ftp.uu.net ;;; 12-MAY-92 mk 1.18 Split questions 1-5, 1-6, and 1-7 into part 4, ;;; which is now cross-posted to comp.lang.scheme, and ;;; questions 1-8, 2-3, 2-9 and 2-18 into part 5 which ;;; is now cross-posted to comp.lang.clos. ;;; Added detail to Norvig entry in 1-1. ;;; Updated entries for several Lisp implementations. ;;; 26-MAY-92 mk 1.19 Changed 5-2 on the basis of comments by Jeff Greif. ;;; 29-MAY-92 mk 1.20 Added question [2-17] about lisp sockets. ;;; 16-JUN-92 mk 1.21 Moved the question about object oriented ;;; programming references to part 5 of the FAQ. ;;; Entry on Dylan. Addition to MIT Scheme entry ;;; regarding Schematik. ;;; 22-JUN-92 mk Updated SOAR entry. ;;; 24-JUN-92 mk Fixed MCL entry to note that CLIM is available ;;; from ILA, not via Apple. ;;; 25-JUN-92 mk 1.22 Added question [2-18]. ;;; 17-JUL-92 mk Added entry on PSD (Portable Scheme Debugger). ;;; 20-JUL-92 mk Updated entry on T3.1 ;;; 30-JUL-92 mk Added entry on XIT to question 2-2. ;;; 3-AUG-92 mk Updated PC-Scheme entry (bought by Ibuki). ;;; 6-AUG-92 mk 1.23 Merged in Jeff Dalton's pitfalls list. ;;; 19-AUG-92 mk Added entry on FOCL. Move three questions from ;;; part 2 to part 3, to keep part 2 under 64k. ;;; 26-AUG-92 mk Added some items from Hallvard Tretteberg's ;;; Lisp style guide. ;;; 31-AUG-92 mk 1.24 Updated entries for CMU CL and SIOD. ;;; 8-SEP-92 mk Added entry on VSCM to part 4. Added entry on ;;; Pixie Scheme, Help, and Le-Lisp. ;;; 14-SEP-92 mk Fixed Symbolics entry. Added entry on CLIM-library. ;;; 15-SEP-92 mk Updated MIT C-Scheme entry. ;;; 17-SEP-92 mk Added entry on Lisp-Jobs. Fixed Le-Lisp entry. ;;; Added 3-15. ;;; 23-SEP-92 mk Added entry on COLAB to ftp resources. ;;; Added entry on WCL to Part 4. ;;; 30-SEP-92 mk Added entry on Dr. Dobb's lisp-style C extensions. ;;; Updated entry on Friedman/Wand/Haynes' book. ;;; 9-OCT-92 mk 1.25 Updated Chez Scheme entry. ;;; Added entry on extracting the function name from ;;; the function object, provided by Kerry Koitzsch. ;;; 14-OCT-92 mk 1.26 Split off the ftp resources question from Part 2 ;;; into its own file, now labels Part 6. ;;; Broke up the question into smaller pieces ;;; and reorganized it too. Reorganized Part 4. ;;; 20-OCT-92 mk Added description of Koschmann text, ;;; thanks to L. Mayka. ;;; 27-OCT-92 mk 1.27 Added question 6-6 about formatting code in LaTeX. ;;; 3-NOV-92 mk Added comment on file modularization to 1-2. ;;; Added note on the CLOS code repository to ;;; 6-1. ;;; 5-NOV-92 mk Added info on Lucid benchmark programs in the ;;; goodies/ directory. Also the Lucid ;;; wizards.doc file. ;;; 11-NOV-92 mk Added entry on Karlsruhe CLISP to 4-0. ;;; ------------------------------------------------------------ ;;; *EOF* From: mkant+@cs.cmu.edu (Mark Kantrowitz) Newsgroups: comp.lang.lisp,news.answers Subject: FAQ: Lisp Frequently Asked Questions 2/6 [Monthly posting] Message-ID: Date: 13 Nov 92 09:01:58 GMT Approved: news-answers-request@MIT.Edu Archive-name: lisp-faq/part2 Last-Modified: Thu Nov 5 19:30:40 1992 by Mark Kantrowitz Version: 1.27 ;;; **************************************************************** ;;; Answers to Frequently Asked Questions about Lisp *************** ;;; **************************************************************** ;;; Written by Mark Kantrowitz and Barry Margolin ;;; lisp-faq-2.text -- 28371 bytes This post contains Part 2 of the Lisp FAQ. If you think of questions that are appropriate for this FAQ, or would like to improve an answer, please send email to us at lisp-faq@think.com. Topics Covered (Part 2): [2-1] Is there a GNU-Emacs interface to Lisp? [2-3] What is the equivalent of EXPLODE and IMPLODE in Common Lisp? [2-4] Is Lisp inherently slower than more conventional languages such as C? [2-5] Why does Common Lisp have "#'"? [2-6] How do I call non-Lisp functions from Lisp? [2-7] Can I call Lisp functions from other languages? [2-8] I want to call a function in a package that might not exist at compile time. How do I do this? [2-9] What is CDR-coding? [2-10] What is garbage collection? [2-11] How do I save an executable image of my loaded Lisp system? How do I run a Unix command in my Lisp? How do I get the current directory name from within a Lisp program? [2-12] I'm porting some code from a Symbolics Lisp machine to some other platform, and there are strange characters in the code. What do they mean? [2-13] History: Where did Lisp come from? [2-14] How do I find the argument list of a function? How do I get the function name from a function object? [2-15] How can I have two Lisp processes communicate via unix sockets? Search for [#] to get to question number # quickly. ---------------------------------------------------------------- [2-1] Is there a GNU-Emacs interface to Lisp? ILISP is a powerful GNU-Emacs interface to many dialects of Lisp, including Lucid, Allegro, {A}KCL, IBCL, and CMU. Written by Chris McConnell . It is available by anonymous ftp from katmandu.mt.cs.cmu.edu [128.2.250.68] in the directory pub/ilisp as the file ilisp.tar.Z. If you start using it, send Chris mail, as he maintains a mailing list of users. Franz Inc.'s GNU-Emacs/Lisp interface includes an online Common Lisp manual. It is available by license from Franz Inc. Contact info@franz.com for more information. There is also a mailing list, lisp-emacs-forum-request@ucbarpa.berkeley.edu. The cl-shell package provides a major mode (cl-shell-mode) for running Common Lisp (CL) as an Emacs subprocess. It provides a general mechanism for communication between CL and Emacs which does not rely on extra processes, and should therefore be easily portable to any version of CL. Features include direct (i.e., not through a temp file) evaluation and in-package compilation of forms from lisp-mode buffers, type-ahead and a history mechanism for the cl-shell buffer, and pop-up help facilities for the CL functions documentation, macroexpand and describe. Extensions for Lucid Common Lisp provide pop-up arglists and source file editing. Other extensions are provided to allow editing source files of CLOS or Flavors methods. Cl-shell is available on the Lucid tape (in the goodies directory) or via anonymous ftp from whitechapel.media.mit.edu (18.85.0.125). Lucid includes some other Emacs-Lisp interfaces in its goodies directory. Harlequin's LispWorks includes an Emacs-Lisp interface. Venue's Medley has an optional EMACS Interface. GNU-Emacs itself is available by anonymous ftp from prep.ai.mit.edu. ---------------------------------------------------------------- [2-3] What is the equivalent of EXPLODE and IMPLODE in Common Lisp? Hopefully, the only reason you need to do this is as part of trying to port some old MacLisp code to Common Lisp. These functions predated the inclusion of strings as a first-class data type in Lisp; symbols were used as strings, and they ere EXPLODEd to allow the individual characters to be manipulated in a list. Probably the best approximations of these are: (defun explode (object) (loop for char across (prin1-to-string object) collect (intern (string char)))) (defun implode (list) (read-from-string (coerce (mapcar #'character list) 'string))) An alternate definition of EXPLODE which uses MAP instead of LOOP is: (defun explode (object) (map 'list #'(lambda (char) (intern (string char))) (prin1-to-string object))) The creation of N conses of garbage to process a string of N characters is a hideously inefficient way of doing the job. Rewrite EXPLODE code with PRIN1-TO-STRING, or better STRING if the arguments are symbols without funny characters. For IMPLODE, try to make its caller use strings and try to make the result usable as a string to avoid having to call INTERN or READ-FROM-STRING. ---------------------------------------------------------------- [2-4] Is Lisp inherently slower than more conventional languages such as C? This is a tough question to answer, as I'm sure you expected. In many cases, it appears to be. Lisp does not require the programmer to specify the data type of variables, so generic arithmetic operators may have to perform type checking at runtime in order to determine how to proceed. However, Lisp code can also be denser (i.e. there is more expressed in a single line) than many other languages: the Lisp expression (+ A B) is more powerful than the C expression A+B (the Lisp version supports bignums, rationals, and complex numbers, while the C version only supports limited-size integers and floating point); therefore, one may claim that it is reasonable that the Lisp version take longer than the C version (but don't expect everyone to accept this rationalization). Solutions to this include hardware support (e.g. processors that support type tags in data, such as SPARC and Symbolics Lisp Machines), declarations, and specialized variants of functions (e.g. in MacLisp, + accepts and returns only fixnums, +$ accepts and returns only flonums, and PLUS is generic). At one time, the MIT PDP-10 MacLisp compiler was compared to DEC's PDP-10 Fortran compiler. When appropriate declarations were supplied in the Lisp code, the performance of compiled Lisp arithmetic rivaled that of the Fortran code. It would hardly be fair to compare Lisp without declarations to Fortran, since the Fortran compiler would have more information upon which it could base its optimizations. Since Lisp is a good language for rapid prototyping, it is easy for a mediocre programmer (or even a good programmer, who isn't being careful) to generate a large amount of inefficient Lisp code. A good example is the use of APPEND to link successive lists together, instead of keeping a pointer to the tail of the list. Often a programmer can obtain significant speed increases by using a time/space profiler to identify the functions which waste time (often small functions which are called frequently) and rewriting those functions. ---------------------------------------------------------------- [2-5] Why does Common Lisp have "#'"? #' is a macro-character which expands #'FOO to (FUNCTION FOO). Symbols in Lisp have two bindings, one for values and one for functions, allowing them to represent both variables and functions, depending on context. #'FOO accesses FOO's lexical function binding in a context where the value interpretation would normally occur. #' is also used to create lexical closures for lambda expressions. A lexical closure is a function which when invoked executes the body of the lambda-expression in the lexical environment within which the closure was created. See pp. 115-117 of CLtL2 for more details. ---------------------------------------------------------------- [2-6] How do I call non-Lisp functions from Lisp? Most Lisp implementations for systems where Lisp is not the most common language provide a "foreign function" interface. As of now there has been no significant standardization effort in this area. They tend to be similar, but there are enough differences that it would be inappropriate to try to describe them all here. In general, one uses an implementation-dependent macro that defines a Lisp function, but instead of supplying a body for the function, one supplies the name of a function written in another language; the argument list portion of the definition is generally augmented with the data types the foreign function expects and the data type of the foreign function's return value, and the Lisp interface function arranges to do any necessary conversions. There is also generally a function to "load" an object file or library compiled in a foreign language, which dynamically links the functions in the file being loaded into the address space of the Lisp process, and connects the interface functions to the corresponding foreign functions. If you need to do this, see the manual for your language implementation for full details. In particular, be on the lookout for restrictions on the data types that may be passed. You may also need to know details about the linkage conventions that are used on your system; for instance, many C implementations prepend an underscore onto the names of C functions when generating the assembler output (this allows them to use names without initial underscores internally as labels without worrying about conflicts), and the foreign function interface may require you to specify this form explicitly. Franz Allegro Common Lisp's "Foreign Function Call Facility" is described in chapter 10 of the documentation. Calling Lisp Functions from C is treated in section 10.8.2. The foreign function interface in Macintosh Common Lisp is similar. The foreign function interface for KCL is described in chapter 10 of the KCL Report. The foreign function interfaces for Lucid on the Vax and Lucid on the Sun4 are incompatible. Lucid's interface is described in chapter 5 of the Advanced User's Guide. ---------------------------------------------------------------- [2-7] Can I call Lisp functions from other languages? In implementations that provide a foreign function interface as described above, there is also usually a "callback" mechanism. The programmer may associate a foreign language function name with a Lisp function. When a foreign object file or library is loaded into the Lisp address space, it is linked with these callback functions. As with foreign functions, the programmer must supply the argument and result data types so that Lisp may perform conversions at the interface. Note that in such foreign function interfaces Lisp is often left "in control" of things like memory allocation, I/O channels, and startup code (this is a major nuisance for lots of people). ---------------------------------------------------------------- [2-8] I want to call a function in a package that might not exist at compile time. How do I do this? Use (funcall (find-symbol "SYMBOL-NAME" :pkg-name) ...). ---------------------------------------------------------------- [2-9] What is CDR-coding? CDR-coding is a space-saving way to store lists in memory. It is normally only used in Lisp implementations that run on processors that are specialized for Lisp, as it is difficult to implement efficiently in software. In normal list structure, each element of the list is represented as a CONS cell, which is basically two pointers (the CAR and CDR); the CAR points to the element of the list, while the CDR points to the next CONS cell in the list or NIL. CDR-coding takes advantage of the fact that most CDR cells point to another CONS, and further that the entire list is often allocated at once (e.g. by a call to LIST). Instead of using two pointers to implement each CONS cell, the CAR cell contains a pointer and a two-bit "CDR code". The CDR code may contain one of three values: CDR-NORMAL, CDR-NEXT, and CDR-NIL. If the code is CDR-NORMAL, this cell is the first half of an ordinary CONS cell pair, and the next cell in memory contains the CDR pointer as described above. If the CDR code is CDR-NEXT, the next cell in memory contains the next CAR cell; in other words, the CDR pointer is implicitly thisaddress+1, where thisaddress is the memory address of the CAR cell. If the CDR code is CDR-NIL, then this cell is the last element of the list; the CDR pointer is implicitly a reference to the object NIL. When a list is constructed incrementally using CONS, a chain of ordinary pairs is created; however, when a list is constructed in one step using LIST or MAKE-LIST, a block of memory can be allocated for all the CAR cells, and their CDR codes all set to CDR-NEXT (except the last, which is CDR-NIL), and the list will only take half as much storage (because all the CDR pointers are implicit). If this were all there were to it, it would not be difficult to implement in software on ordinary processors; it would add a small amount of overhead to the CDR function, but the reduction in paging might make up for it. The problem arises when a program uses RPLACD on a CONS cell that has a CDR code of CDR-NEXT or CDR-NIL. Normally RPLACD simply stores into the CDR cell of a CONS, but in this case there is no CDR cell -- its contents are implicitly specified by the CDR code, and the word that would normally contain the CDR pointer contains the next CONS cell (in the CDR-NEXT case) to which other data structures may have pointers, or the first word of some other object (in the CDR-NIL case). When CDR-coding is used, the implementation must also provide automatic "forwarding pointers"; an ordinary CONS cell is allocated, the CAR of the original cell is copied into its CAR, the value being RPLACD'ed is stored into its CDR, and the old CAR cell is replaced with a forwarding pointer to the new CONS cell. Whenever CAR or CDR is performed on a CONS, it must check whether the location contains a forwarding pointer. This overhead on both CAR and CDR, coupled with the overhead on CDR to check for CDR codes, is generally enough that using CDR codes on conventional hardware is infeasible. There is some evidence that CDR-coding doesn't really save very much memory, because most lists aren't constructed at once, or RPLACD is done on them enough that they don't stay contiguous. At best this technique can save of the space occupied by CONS cells. However, the savings probably depends to some extent upon the amount of support the implementation provides for creating CDR-coded lists. For instance, many system functions on Symbolics Lisp Machines that operate on lists have a :LOCALIZE option; when :LOCALIZE T is specified, the list is first modified and then copied to a new, CDR-coded block, with all the old cells replaced with forwarding pointers. The next time the garbage collector runs, all the forwarding pointers will be spliced out. Thus, at a cost of a temporary increase in memory usage, overall memory usage is generally reduced because more lists may be CDR-coded. There may also be some benefit in improved paging performance due to increased locality as well (putting a list into CDR-coded form makes all the "cells" contiguous). Nevertheless, modern Lisps tend to use lists much less frequently, with a much heavier reliance upon code, strings, and vectors (structures). ---------------------------------------------------------------- [2-10] What is garbage collection? Garbage Collection (GC) refers to the automatic storage allocation mechanisms present in many Lisps. There are several kinds of storage allocation algorithms, but most fall within two main classes: 1. Stop and Copy. Systems which copy active objects from "old" storage to "new" storage and then recycle the old storage. 2. Mark and Sweep. Systems which link together storage used by discarded objects. Generational scavenging garbage collection (aka emphemeral GC) is a variation in which memory is allocated in layers, with tenured (long-lived) objects in the older layers. Rather than doing a full GC of all of memory every time more room is needed, only the last few layers are GCed during an ephemeral GC, taking much less time. Short-lived objects are quickly recycled, and full GCs are then much less frequent. It is most often used to improve the performance of stop and copy garbage collectors. It is possible to implement ephemeral GC in mark and sweep systems, just much more difficult. Stop and copy garbage collection provides simpler storage allocation, avoids fragmentation of memory (intermixing of free storage with used storage). Copying, however, consumes more of the address space, since up to half the space must be kept available for copying all the active objects. This makes stop and copy GC impractical for systems with a small address space or without virtual memory. Also, copying an object requires that you track down all the pointers to an object and update them to reflect the new address, while in a non-copying system you need only keep one pointer to an object, since its location will not change. It is also more difficult to explicitly return storage to free space in a copying system. Garbage collection is not part of the Common Lisp standard. Most Lisps provide a function ROOM which provides human-readable information about the state of storage usage. In many Lisps, (gc) invokes an ephemeral garbage collection, and (gc t) a full garbage collection. ---------------------------------------------------------------- [2-11] How do I save an executable image of my loaded Lisp system? How do I run a Unix command in my Lisp? How do I get the current directory name from within a Lisp program? There is no standard for dumping a Lisp image. Here are the commands from some lisp implementations: Lucid: DISKSAVE Symbolics: Save World [CP command] CMU CL: SAVE-LISP Franz Allegro: EXCL:DUMPLISP (documented) SAVE-IMAGE (undocumented) Medley: IL:SYSOUT or IL:MAKESYS MCL: SAVE-APPLICATION &key :toplevel-function :creator :excise-compiler :size :resources :init-file :clear-clos-caches KCL: (si:save-system "saved_kcl") There is no standard for running a Unix shell command from Lisp, especially since not all Lisps run on top of Unix. Here are the commands from some Lisp implementations: Allegro: EXCL:RUN-SHELL-COMMAND Lucid: RUN-PROGRAM (name &key input output error-output (wait t) arguments (if-input-does-not-exist :error) (if-output-exists :error) (if-error-output-exists :error)) KCL: SYSTEM For example, (system "ls -l"). You can also try RUN-PROCESS and EXCLP, but they don't work with all versions of KCL. There's no standard function for finding the current directory from within a Lisp program, since not all Lisp environments have the concept of a current directory. Here are the commands from some Lisp implementations: Lucid: working-directory (which is also SETFable) pwd and cd also work Allegro: current-directory (use excl:chdir to change it) CMU CL: default-directory Allegro also uses the variable *default-pathname-defaults* to resolve relative pathnames, maintaining it as the current working directory. So evaluating (truename "./") in Allegro (and on certain other systems) will return a pathname for the current directory. Likewise, in some VMS systems evaluating (truename "[]") will return a pathname for the current directory. ---------------------------------------------------------------- [2-12] I'm porting some code from a Symbolics Lisp machine to some other platform, and there are strange characters in the code. What do they mean? The Symbolics Zetalisp character set includes the following characters not present in other Lisps: ^] >= greater than or equal to ^\ <= less than or equal to ^Z != not equal to ^^ == equivalent to ^E not ^G pi ^L +/- plus/minus ^H lambda ^F epsilon ^W <--> left/right arrow ^X <-- left arrow ^Y --> right arrow Other special characters to look out for are the font-change characters, which are represented as a ^F followed by a digit or asterisk. A digit means to push font #N onto the stack; an asterisk means to pop the most recent font from the stack. You can clean up the code by replacing "\^F." with "". ---------------------------------------------------------------- [2-13] History: Where did Lisp come from? John McCarthy developed the basics behind Lisp during the 1956 Dartmouth Summer Research Project on Artificial Intelligence. He intended it as an algebraic LISt Processing (hence the name) language for artificial intelligence work. Early implementations included the IBM 704, the IBM 7090, the DEC PDP-1, the DEC PDP-6 and the DEC PDP-10. The PDP-6 and PDP-10 had 18-bit addresses and 36-bit words, allowing a CONS cell to be stored in one word, with single instructions to extract the CAR and CDR parts. The early PDP machines had a small address space, which limited the size of Lisp programs. Milestones in the development of Lisp: 1956 Dartmouth Summer Research Project on AI. 1960-65 Lisp1.5 is the primary dialect of Lisp. 1964- Development of BBNLisp at BBN. late 60s Lisp1.5 diverges into two main dialects: Interlisp (originally BBNLisp) and MacLisp. early 70s Development of special-purpose computers known as Lisp Machines, designed specificly to run Lisp programs. Xerox D-series Lisp Machines run Interlisp-D. Early MIT Lisp Machines run Lisp Machine Lisp (an extension of MacLisp). 1969 Anthony Hearn and Martin Griss define Standard Lisp to port REDUCE, a symbolic algebra system, to a variety of architectures. late 70s Macsyma group at MIT developed NIL (New Implementation of Lisp), a Lisp for the VAX. Stanford and Lawrence Livermore National Laboratory develop S-1 Lisp for the Mark IIA supercomputer. Franz Lisp (dialect of MacLisp) runs on stock-hardware Unix machines. Gerald J. Sussman and Guy L. Steele developed Scheme, a simple dialect of Lisp with lexical scoping and lexical closures, continuations as first-class objects, and a simplified syntax (i.e., only one binding per symbol). Advent of object-oriented programming concepts in Lisp. Flavors was developed at MIT for the Lisp machine, and LOOPS (Lisp Object Oriented Programming System) was developed at Xerox. early 80s Development of SPICE-Lisp at CMU, a dialect of MacLisp designed to run on the Scientific Personal Integrated Computing Environment (SPICE) workstation. 1980 First biannual ACM Lisp and Functional Programming Conf. 1981 PSL (Portable Standard Lisp) runs on a variety of platforms. 1981+ Lisp Machines from Xerox, LMI (Lisp Machines Inc) and Symbolics available commercially. April 1981 Grass roots definition of Common Lisp as a description of the common aspects of the family of languages (Lisp Machine Lisp, MacLisp, NIL, S-1 Lisp, Spice Lisp, Scheme). 1984 Publication of CLtL1. Common Lisp becomes a de facto standard. 1986 X3J13 forms to produce a draft for an ANSI Common Lisp standard. 1987 Lisp Pointers commences publication. 1990 Steele publishes CLtL2 which offers a snapshot of work in progress by X3J13. (Unlike CLtL1, CLtL2 was NOT an output of the standards process and was not intended to become a de facto standard. Read the Second Edition Preface for further explanation of this important issue.) Includes CLOS, conditions, pretty printing and iteration facilities. 1992 X3J13 creates a draft proposed American National Standard for Common Lisp. This document is the first official successor to CLtL1. [Note: This summary is based primarily upon the History section of the draft ANSI specification. More detail and references can be obtained from that document. See [1-5] for information on obtaining a copy.] ---------------------------------------------------------------- [2-14] How do I find the argument list of a function? How do I get the function name from a function object? There is no standard way to find the argument list of a function, since implementations are not required to save this information. However, many implementations do remember argument information, and usually have a function that returns the lambda list. Here are the commands from some Lisp implementations: Lucid: arglist Allegro: excl::arglist Symbolics: arglist CMU Common Lisp, new compiler: #+(and :CMU :new-compiler) (defun arglist (name) (let* ((function (symbol-function name)) (stype (system:%primitive get-vector-subtype function))) (when (eql stype system:%function-entry-subtype) (cadr (system:%primitive header-ref function system:%function-entry-type-slot))))) If you're interested in the number of required arguments you could use (defun required-arguments (name) (or (position-if #'(lambda (x) (member x lambda-list-keywords)) (arglist name)) (length (arglist name)))) To extract the function name from the function object, as in (function-name #'car) ==> 'car use the following vendor-dependent functions: Symbolics: (si::compiled-function-name ) Lucid: (sys::procedure-ref SYS:PROCEDURE-SYMBOL) Allegro: (Xref::object-to-function-name ) CMU CL: (kernel:%function-header-name ) AKCL: (system::compiled-function-name ) MCL: (ccl::function-name ) ---------------------------------------------------------------- [2-15] How can I have two Lisp processes communicate via unix sockets? CLX uses Unix sockets to communicate with the X window server. Look at the following files from the CLX distribution for a good example of using Unix sockets from Lisp: defsystem.lisp Lucid, AKCL, IBCL, CMU. socket.c, sockcl.lisp AKCL, IBCL excldep.lisp Franz Allegro CL You will need the "socket.o" files which come with Lucid and Allegro. To obtain CLX, see the entry for CLX in the answer to question [6-5]. See the file lisp-sockets.text in the Lisp Utilities repository described in the answer to question [6-1]. ---------------------------------------------------------------- ;;; *EOF* From: mkant+@cs.cmu.edu (Mark Kantrowitz) Newsgroups: comp.lang.lisp,news.answers Subject: FAQ: Lisp Frequently Asked Questions 3/6 [Monthly posting] Message-ID: Date: 13 Nov 92 09:02:17 GMT Approved: news-answers-request@MIT.Edu Archive-name: lisp-faq/part3 Last-Modified: Thu Nov 5 19:30:40 1992 by Mark Kantrowitz Version: 1.27 ;;; **************************************************************** ;;; Answers to Frequently Asked Questions about Lisp *************** ;;; **************************************************************** ;;; Written by Mark Kantrowitz and Barry Margolin ;;; lisp-faq-3.text -- 32488 bytes This post contains Part 3 of the Lisp FAQ. If you think of questions that are appropriate for this FAQ, or would like to improve an answer, please send email to us at lisp-faq@think.com. This section contains a list of common pitfalls. Pitfalls are aspects of Common Lisp which are non-obvious to new programmers and often seasoned programmers as well. Common Pitfalls (Part 3): [3-0] Why does (READ-FROM-STRING "foobar" :START 3) return FOOBAR instead of BAR? [3-1] Why can't it deduce from (READ-FROM-STRING "foobar" :START 3) that the intent is to specify the START keyword parameter rather than the EOF-ERROR-P and EOF-VALUE optional parameters? [3-2] Why can't I apply #'AND and #'OR? [3-3] I used a destructive function (e.g. DELETE, SORT), but it didn't seem to work. Why? [3-4] After I NREVERSE a list, it's only one element long. After I SORT a list, it's missing things. What happened? [3-5] Why does (READ-LINE) return "" immediately instead of waiting for me to type a line? [3-6] I typed a form to the read-eval-print loop, but nothing happened. Why? [3-7] DEFMACRO doesn't seem to work. When I compile my file, LISP warns me that my macros are undefined functions, or complains "Attempt to call which is defined as a macro. [3-8] Name conflict errors are driving me crazy! (EXPORT, packages) [3-9] Closures don't seem to work properly when referring to the iteration variable in DOLIST, DOTIMES and DO. [3-10] What is the difference between FUNCALL and APPLY? [3-11] Miscellaneous things to consider when debugging code. [3-12] When is it right to use EVAL? [3-13] Why does my program's behavior change each time I use it? [3-14] When producing formatted output in Lisp, where should you put the newlines (e.g., before or after the line, FRESH-LINE vs TERPRI, ~& vs ~% in FORMAT)? [3-15] I'm using DO to do some iteration, but it doesn't terminate. Search for [#] to get to question number # quickly. ---------------------------------------------------------------- [3-0] Why does (READ-FROM-STRING "foobar" :START 3) return FOOBAR instead of BAR? READ-FROM-STRING is one of the rare functions that takes both &OPTIONAL and &KEY arguments: READ-FROM-STRING string &OPTIONAL eof-error-p eof-value &KEY :start :end :preserve-whitespace When a function takes both types of arguments, all the optional arguments must be specified explicitly before any of the keyword arguments may be specified. In the example above, :START becomes the value of the optional EOF-ERROR-P parameter and 3 is the value of the optional EOF-VALUE parameter. ---------------------------------------------------------------- [3-1] Why can't it deduce from (READ-FROM-STRING "foobar" :START 3) that the intent is to specify the START keyword parameter rather than the EOF-ERROR-P and EOF-VALUE optional parameters? In Common Lisp, keyword symbols are first-class data objects. Therefore, they are perfectly valid values for optional parameters to functions. There are only four functions in Common Lisp that have both optional and keyword parameters (they are PARSE-NAMESTRING, READ-FROM-STRING, WRITE-LINE, and WRITE-STRING), so it's probably not worth adding a nonorthogonal kludge to the language just to make these functions slightly less confusing; unfortunately, it's also not worth an incompatible change to the language to redefine those functions to use only keyword arguments. ---------------------------------------------------------------- [3-2] Why can't I apply #'AND and #'OR? Here's the simple, but not necessarily satisfying, answer: AND and OR are macros, not functions; APPLY and FUNCALL can only be used to invoke functions, not macros and special operators. OK, so what's the *real* reason? The reason that AND and OR are macros rather than functions is because they implement control structure in addition to computing a boolean value. They evaluate their subforms sequentially from left/top to right/bottom, and stop evaluating subforms as soon as the result can be determined (in the case of AND, as soon as a subform returns NIL; in the case of OR, as soon as one returns non-NIL); this is referred to as "short circuiting" in computer language parlance. APPLY and FUNCALL, however, are ordinary functions; therefore, their arguments are evaluated automatically, before they are called. Thus, were APPLY able to be used with #'AND, the short-circuiting would be defeated. Perhaps you don't really care about the short-circuiting, and simply want the functional, boolean interpretation. While this may be a reasonable interpretation of trying to apply AND or OR, it doesn't generalize to other macros well, so there's no obvious way to have the Lisp system "do the right thing" when trying to apply macros. The only function associated with a macro is its expander function; this function accepts and returns and form, so it cannot be used to compute the value. The Common Lisp functions EVERY and SOME can be used to get the functionality you intend when trying to apply #'AND and #'OR. For instance, the erroneous form: (apply #'and *list*) can be translated to the correct form: (every #'identity *list*) ---------------------------------------------------------------- [3-3] I used a destructive function (e.g. DELETE, SORT), but it didn't seem to work. Why? I assume you mean that it didn't seem to modify the original list. There are several possible reasons for this. First, many destructive functions are not *required* to modify their input argument, merely *allowed* to; in some cases, the implementation may determine that it is more efficient to construct a new result than to modify the original (this may happen in Lisp systems that use "CDR coding", where RPLACD may have to turn a CDR-NEXT or CDR-NIL cell into a CDR-NORMAL cell), or the implementor may simply not have gotten around to implementing the destructive version in a truly destructive manner. Another possibility is that the nature of the change that was made involves removing elements from the front of a list; in this case, the function can simply return the appropriate tail of the list, without actually modifying the list. And example of this is: (setq *a* (list 3 2 1)) (delete 3 *a*) => (2 1) *a* => (3 2 1) Similarly, when one sorts a list, SORT may destructively rearrange the pointers (cons cells) that make up the list. SORT then returns the cons cell that now heads the list; the original cons cell could be anywhere in the list. The value of any variable that contained the original head of the list hasn't changed, but the contents of that cons cell have changed because SORT is a destructive function: (setq *a* (list 2 1 3)) (sort *a* #'<) => (1 2 3) *a* => (2 3) In both cases, the remedy is the same: store the result of the function back into the place whence the original value came, e.g. (setq *a* (delete 3 *a*)) *a* => (2 1) Why don't the destructive functions do this automatically? Recall that they are just ordinary functions, and all Lisp functions are called by value. Therefore, these functions do not know where the lists they are given came from; they are simply passed the cons cell that represents the head of the list. Their only obligation is to return the new cons cell that represents the head of the list. One thing to be careful about when doing this is that the original list might be referenced from multiple places, and all of these places may need to be updated. For instance: (setq *a* (list 3 2 1)) (setq *b* *a*) (setq *a* (delete 3 *a*)) *a* => (2 1) *b* => (3 2 1) ; *B* doesn't "see" the change (setq *a* (delete 1 *a*)) *a* => (2) *b* => (3 2) ; *B* sees the change this time, though One may argue that destructive functions could do what you expect by rearranging the CARs of the list, shifting things up if the first element is being deleted, as they are likely to do if the argument is a vector rather than a list. In many cases they could do this, although it would clearly be slower. However, there is one case where this is not possible: when the argument or value is NIL, and the value or argument, respectively, is not. It's not possible to transform the object referenced from the original cell from one data type to another, so the result must be stored back. Here are some examples: (setq *a* (list 3 2 1)) (delete-if #'numberp *a) => NIL *a* => (3 2 1) (setq *a* nil *b* '(1 2 3)) (nconc *a* *b*) => (1 2 3) *a* => NIL The names of most destructure functions (except for sort, delete, rplaca, rplacd, and setf of accessor functions) have the prefix N. In summary, the two common problems to watch out for when using destructive functions are: 1. Forgetting to store the result back. Even though the list is modified in place, it is still necessary to store the result of the function back into the original location, e.g., (setq foo (delete 'x foo)) If the original list was stored in multiple places, you may need to store it back in all of them, e.g. (setq bar foo) ... (setq foo (delete 'x foo)) (setq bar foo) 2. Sharing structure that gets modified. If it is important to preserve the shared structure, then you should either use a nondestructive operation or copy the structure first using COPY-LIST or COPY-TREE. (setq bar (cdr foo)) ... (setq foo (sort foo #'<)) ;;; now it's not safe to use BAR Note that even nondestructive functions, such as REMOVE, and UNION, can return a result which shares structure with an argument. Nondestructive functions don't necessarily copy their arguments; they just don't modify them. ---------------------------------------------------------------- [3-4] After I NREVERSE a list, it's only one element long. After I SORT a list, it's missing things. What happened? These are particular cases of the previous question. Many NREVERSE and SORT implementations operate by rechaining all the CDR links in the list's backbone, rather than by replacing the CARs. In the case of NREVERSE, this means that the cons cell that was originally first in the list becomes the last one. As in the last question, the solution is to store the result back into the original location. ---------------------------------------------------------------- [3-5] Why does (READ-LINE) return "" immediately instead of waiting for me to type a line? Many Lisp implementations on line-buffered systems do not discard the newline that the user must type after the last right parenthesis in order for the line to be transmitted from the OS to Lisp. Lisp's READ function returns immediately after seeing the matching ")" in the stream. When READLINE is called, it sees the next character in the stream, which is a newline, so it returns an empty line. If you were to type "(read-line)This is a test" the result would be "This is a test". The simplest solution is to use (PROGN (CLEAR-INPUT) (READ-LINE)). This discards the buffered newline before reading the input. However, it would also discard any other buffered input, as in the "This is a test" example above; some implementation also flush the OS's input buffers, so typeahead might be thrown away. ---------------------------------------------------------------- [3-6] I typed a form to the read-eval-print loop, but nothing happened. Why? There's not much to go on here, but a common reason is that you haven't actually typed a complete form. You may have typed a doublequote, vertical bar, "#|" comment beginning, or left parenthesis that you never matched with another doublequote, vertical bar, "|#", or right parenthesis, respectively. Try typing a few right parentheses followed by Return. ---------------------------------------------------------------- [3-7] DEFMACRO doesn't seem to work. When I compile my file, LISP warns me that my macros are undefined functions, or complains "Attempt to call which is defined as a macro. When you evaluate a DEFMACRO form or proclaim a function INLINE, it doesn't go back and update code that was compiled under the old definition. When redefining a macro, be sure to recompile any functions that use the macro. Also be sure that the macros used in a file are defined before any forms in the same file that use them. Certain forms, including LOAD, SET-MACRO-CHARACTER, and REQUIRE, are not normally evaluated at compile time. Common Lisp requires that macros defined in a file be used when compiling later forms in the file. If a Lisp doesn't follow the standard, it may be necessary to wrap an EVAL-WHEN form around the macro definition. Most often the "macro was previously called as a function" problem occurs when files were compiled/loaded in the wrong order. For example, developers may add the definition to one file, but use it in a file which is compiled/loaded before the definition. To work around this problem, one can either fix the modularization of the system, or manually recompile the files containing the forward references to macros. Also, if your macro calls functions at macroexpand time, those functions may need to be in an EVAL-WHEN. For example, (defun some-function (x) x) (defmacro some-macro (y) (let ((z (some-function y))) `(print ',z))) If the macros are defined in a file you require, make sure your require or load statement is in an appropriate EVAL-WHEN. Many people avoid all this nonsense by making sure to load all their files before compiling them, or use a system facility (or just a script file) that loads each file before compiling the next file in the system. ---------------------------------------------------------------- [3-8] Name conflict errors are driving me crazy! (EXPORT, packages) If a package tries to export a symbol that's already defined, it will report an error. You probably tried to use a function only to discover that you'd forgotten to load its file. The failed attempt at using the function caused its symbol to be interned. So now, when you try to load the file, you get a conflict. Unfortunately, understanding and correcting the code which caused the export problem doesn't make those nasty error messages go away. That symbol is still interned where it shouldn't be. Use unintern to remove the symbol from a package before reloading the file. Also, when giving arguments to REQUIRE or package functions, use strings or keywords, not symbols: (find-package "FOO"), (find-package :foo). A sometimes useful technique is to rename (or delete) a package that is "too messed up". Then you can reload the relevant files into a "clean" package. ---------------------------------------------------------------- [3-9] Closures don't seem to work properly when referring to the iteration variable in DOLIST, DOTIMES and DO. DOTIMES, DOLIST, and DO all use assignment instead of binding to update the value of the iteration variables. So something like (let ((l nil)) (dotimes (n 10) (push #'(lambda () n) l))) will produce 10 closures over the same value of the variable N. ---------------------------------------------------------------- [3-10] What is the difference between FUNCALL and APPLY? FUNCALL is useful when the programmer knows the length of the argument list, but the function to call is either computed or provided as a parameter. For instance, a simple implementation of MEMBER-IF (with none of the fancy options) could be written as: (defun member-if (predicate list) (do ((tail list (cdr tail))) ((null tail)) (when (funcall predicate (car tail)) (return-from member-if tail)))) The programmer is invoking a caller-supplied function with a known argument list. APPLY is needed when the argument list itself is supplied or computed. Its last argument must be a list, and the elements of this list become individual arguments to the function. This frequently occurs when a function takes keyword options that will be passed on to some other function, perhaps with application-specific defaults inserted. For instance: (defun open-for-output (pathname &rest open-options) (apply #'open pathname :direction :output open-options)) FUNCALL could actually have been defined using APPLY: (defun funcall (function &rest arguments) (apply function arguments)) ---------------------------------------------------------------- [3-11] Miscellaneous things to consider when debugging code. This question lists a variety of problems to watch out for when debugging code. This is sort of a catch-all question for problems too small to merit a question of their own. See also question [1-2] for some other common problems. Functions: * (flet ((f ...)) (eq #'f #'f)) can return false. * The function LIST-LENGTH is not a faster, list-specific version of the sequence function LENGTH. It is list-specific, but it's slower than LENGTH because it can handle circular lists. * Don't confuse the use of LISTP and CONSP. CONSP tests for the presence of a cons cell, but will return NIL when called on NIL. LISTP could be defined as (defun listp (x) (or (null x) (consp x))). * Use the right test for equality: EQ tests if the objects are identical -- numbers with the same value need not be EQ, nor are two similar lists necessarily EQ. Similarly for characters and strings. For instance, (let ((x 1)) (eq x x)) is not guaranteed to return T. EQL Like EQ, but is also true if the arguments are numbers of the same type with the same value or character objects representing the same character. (eql -0.0 0.0) is not guaranteed to return T. EQUAL Tests if the arguments are structurally isomorphic, using EQUAL to compare components that conses, arrays, strings or pathnames, and EQ for all other data objects (except for numbers and characters, which are compared using EQL). EQUALP Like EQUAL, but ignores type differences when comparing numbers and case differences when comparing characters. = Compares the values of two numbers even if they are of different types. CHAR= Case-sensitive comparison of characters. CHAR-EQUAL Case-insensitive comparison of characters. STRING= Compares two strings, checking if they are identical. It is case sensitive. STRING-EQUAL Like STRING=, but case-insensitive. * Some destructive functions that you think would modify CDRs might modify CARs instead. (E.g., NREVERSE.) * READ-FROM-STRING has some optional arguments before the keyword parameters. If you want to supply some keyword arguments, you have to give all of the optional ones too. * If you use the function READ-FROM-STRING, you should probably bind *READ-EVAL* to NIL. Otherwise an unscrupulous user could cause a lot of damage by entering #.(shell "cd; rm -R *") at a prompt. * Only functional objects can be funcalled in CLtL2, so a lambda expression '(lambda (..) ..) is no longer suitable. Use #'(lambda (..) ..) instead. If you must use '(lambda (..) ..), coerce it to type FUNCTION first using COERCE. Methods: * PRINT-OBJECT methods can make good code look buggy. If there is a problem with the PRINT-OBJECT methods for one of your classes, it could make it seem as though there were a problem with the object. It can be very annoying to go chasing through your code looking for the cause of the wrong value, when the culprit is just a bad PRINT-OBJECT method. Initialization: * Don't count on array elements being initialized to NIL, if you don't specify an :initial-element argument to MAKE-ARRAY. For example, (make-array 10) => #(0 0 0 0 0 0 0 0 0 0) Iteration vs closures: * DO and DO* update the iteration variables by assignment; DOLIST and DOTIMES are allowed to use assignment (rather than a new binding). (All CLtL1 says of DOLIST and DOTIMES is that the variable "is bound" which has been taken as _not_ implying that there will be separate bindings for each iteration.) Consequently, if you make closures over an iteration variable in separate iterations they may nonetheless be closures over the same variable and hence will all refer to the same value -- whatever value the variable was given last. For example, (let ((fns '())) (do ((x '(1 2) (cdr x))) ((null x)) (push #'(lambda () x) fns)) (mapcar #'funcall (reverse fns))) returns (nil nil), not (1 2), not even (2 2). Thus (let ((l nil)) (dolist (a '(1 2 3) l) (push #'(lambda () a) l))) returns a list of three closures closed over the same bindings, whereas (mapcar #'(lambda (a) #'(lambda () a)) '(1 2 3)) returns a list of closures over distinct bindings. Defining Variables and Constants: * (defvar var init) assigns to the variable only if it does not already have a value. So if you edit a DEFVAR in a file and reload the file only to find that the value has not changed, this is the reason. (Use DEFPARAMETER if you want the value to change upon reloading.) DEFVAR is used to declare a variable that is changed by the program; DEFPARAMETER is used to declare a variable that is normally constant, but which can be changed to change the functioning of a program. * DEFCONSTANT has several potentially unexpected properties: - Once a name has been declared constant, it cannot be used a the name of a local variable (lexical or special) or function parameter. Really. See page 87 of CLtL2. - A DEFCONSTANT cannot be re-evaluated (eg, by reloading the file in which it appears) unless the new value is EQL to the old one. Strictly speaking, even that may not be allowed. (DEFCONSTANT is "like DEFPARAMETER" and hence does an assignment, which is not allowed if the name has already been declared constant by DEFCONSTANT.) Note that this makes it difficult to use anything other than numbers, symbols, and characters as constants. - When compiling (DEFCONSTANT name form) in a file, the form may be evaluated at compile-time, load-time, or both. (You might think it would be evaluated at compile-time and the _value_ used to obtain the object at load-time, but it doesn't have to work that way.) Declarations: * You often have to declare the result type to get the most efficient arithmetic. Eg, (the fixnum (+ (the fixnum e1) (the fixnum e2))) rather than (+ (the fixnum e1) (the fixnum e2)) * Declaring the iteration variable of a DOTIMES to have type FIXNUM does not guarantee that fixnum arithmetic will be used. That is, implementations that use fixnum-specific arithmetic in the presence of appropriate declaration may not think _this_ declaration is sufficient. It may help to declare that the limit is also a fixnum, or you may have to write out the loop as a DO and add appropriate declarations for each operation involved. FORMAT related errors: * When printing messages about files, filenames like foo~ (a GNU-Emacs backup file) may cause problems with poorly coded FORMAT control strings. * Beware of using an ordinary string as the format string, i.e., (format t string), rather than (format t "~A" string). Miscellaneous: * Be careful of circular lists and shared list structure. * Watch out for macro redefinitions. * If you use (SETF (SYMBOL-FUNCTION 'foo) ...) to change the definition of a built-in Lisp function named FOO, be aware that this may not work correctly (i.e., as desired) in compiled code in all Lisps. In some Lisps, the compiler treats certain symbols in the LISP package specially, ignoring the function definition. * A NOTINLINE may be needed if you want SETF of SYMBOL-FUNCTION to affect calls within a file. (See CLtL2, page 686.) * When dividing two numbers, beware of creating a rational number where you intended to get an integer or floating point number. Use TRUNCATE or ROUND to get an integer and FLOAT to ensure a floating point number. This is a major source of errors when porting ZetaLisp or C code to Common Lisp. * If your code doesn't work because all the symbols are mysteriously in the keyword package, one of your comments has a colon (:) in it instead of a semicolon (;). ---------------------------------------------------------------- [3-12] When is it right to use EVAL? Hardly ever. Any time you think you need to use EVAL, think hard about it. EVAL is useful when implementing a facility that provides an external interface to the Lisp interpreter. For instance, many Lisp-based editors provide a command that prompts for a form and displays its value. Inexperienced macro writers often assume that they must explicitly EVAL the subforms that are supposed to be evaluated, but this is not so; the correct way to write such a macro is to have it expand into another form that has these subforms in places that will be evaluated by the normal evaluation rules. Explicit use of EVAL in a macro is likely to result in one of two problems: the dreaded "double evaluation" problem, which may not show up during testing if the values of the expressions are self-evaluating constants (such as numbers); or evaluation at compile time rather than runtime. For instance, if Lisp didn't have IF and one desired to write it, the following would be wrong: (defmacro if (test then-form &optional else-form) ;; this evaluates all the subforms at compile time, and at runtime ;; evaluates the results again. `(cond (,(eval test) ,(eval then-form)) (t ,(eval else-form)))) (defmacro if (test then-form &optional else-form) ;; this double-evaluates at run time `(cond ((eval ,test) (eval ,then-form)) (t (eval ,else-form))) This is correct: (defmacro if (test then-form &optional else-form) `(cond (,test ,then-form) (t ,else-form))) On the other hand, EVAL can sometimes be necessary when the only portable interface to an operation is a macro. ---------------------------------------------------------------- [3-13] Why does my program's behavior change each time I use it? Most likely your program is altering itself, and the most common way this may happen is by performing destructive operations on embedded constant data structures. For instance, consider the following: (defun one-to-ten-except (n) (delete n '(1 2 3 4 5 6 7 8 9 10))) (one-to-ten-except 3) => (1 2 4 5 6 7 8 9 10) (one-to-ten-except 5) => (1 2 4 6 7 8 9 10) ; 3 is missing The basic problem is that QUOTE returns its argument, *not* a copy of it. The list is actually a part of the lambda expression that is in ONE-TO-TEN-EXCEPT's function cell, and any modifications to it (e.g., by DELETE) are modifications to the actual object in the function definition. The next time that the function is called, this modified list is used. In some implementations calling ONE-TO-TEN-EXCEPT may even result in the signalling of an error or the complete aborting of the Lisp process. Some Lisp implementations put self-evaluating and quoted constants onto memory pages that are marked read-only, in order to catch bugs such as this. Details of this behavior may vary even within an implementation, depending on whether the code is interpreted or compiled (perhaps due to inlined DEFCONSTANT objects). All of these behaviors are allowed by the draft ANSI Common Lisp specification, which specifically states that the consequences of modifying a constant are undefined (X3J13 vote CONSTANT-MODIFICATION:DISALLOW). To avoid these problems, use LIST to introduce a list, not QUOTE. QUOTE should be used only when the list is intended to be a constant which will not be modified. If QUOTE is used to introduce a list which will later be modified, use COPY-LIST to provide a fresh copy. For example, the following should all work correctly: o (remove 4 (list 1 2 3 4 1 3 4 5)) o (remove 4 '(1 2 3 4 1 3 4 5)) ;; Remove is non-destructive. o (delete 4 (list 1 2 3 4 1 3 4 5)) o (let ((x (list 1 2 4 1 3 4 5))) (delete 4 x)) o (defvar *foo* '(1 2 3 4 1 3 4 5)) (delete 4 (copy-list *foo*)) (remove 4 *foo*) (let ((x (copy-list *foo*))) (delete 4 x)) The following, however, may not work as expected: o (delete 4 '(1 2 3 4 1 3 4 5)) ---------------------------------------------------------------- [3-14] When producing formatted output in Lisp, where should you put the newlines (e.g., before or after the line, FRESH-LINE vs TERPRI, ~& vs ~% in FORMAT)? Where possible, it is desirable to write functions that produce output as building blocks. In contrast with other languages, which either conservatively force a newline at various times or require the program to keep track of whether it needs to force a newline, the Lisp I/O system keeps track of whether the most recently printed character was a newline or not. The function FRESH-LINE outputs a newline only if the stream is not already at the beginning of a line. TERPRI forces a newline irrespective of the current state of the stream. These correspond to the ~& and ~% FORMAT directives, respectively. (If the Lisp I/O system can't determine whether it's physically at the beginning of a line, it assumes that a newline is needed, just in case.) Thus, if you want formatted output to be on a line of its own, start it with ~& and end it with ~%. (Some people will use a ~& also at the end, but this isn't necessary, since we know a priori that we're not at the beginning of a line. The only exception is when ~& follows a ~A, to prevent a double newline when the argument to the ~A is a formatted string with a newline at the end.) For example, the following routine prints the elements of a list, N elements per line, and then prints the total number of elements on a new line: (defun print-list (list &optional (elements-per-line 10)) (fresh-line) (loop for i upfrom 1 for element in list do (format t "~A ~:[~;~%~]" element (zerop (mod i elements-per-line)))) (format t "~&~D~%" (length list))) ---------------------------------------------------------------- [3-15] I'm using DO to do some iteration, but it doesn't terminate. Your code probably looks something like (do ((sublist list (cdr list)) ..) ((endp sublist) ..) ..) or maybe (do ((index start (+ start 2)) ..) ((= index end) ..) ..) The problem is caused by the (cdr list) and the (+ start 2) in the first line. You're using the original list and start index instead of the working sublist or index. Change them to (cdr sublist) and (+ index 2) and your code should start working. ---------------------------------------------------------------- ;;; *EOF* From: mkant+@cs.cmu.edu (Mark Kantrowitz) Newsgroups: comp.lang.lisp,comp.lang.scheme,news.answers Subject: FAQ: Lisp Implementations and Mailing Lists 4/6 [Monthly posting] Message-ID: Date: 13 Nov 92 09:02:41 GMT Approved: news-answers-request@MIT.Edu Archive-name: lisp-faq/part4 Last-Modified: Thu Nov 5 19:30:40 1992 by Mark Kantrowitz Version: 1.27 ;;; **************************************************************** ;;; Answers to Frequently Asked Questions about Lisp *************** ;;; **************************************************************** ;;; Written by Mark Kantrowitz and Barry Margolin ;;; lisp-faq-4.text -- 55661 bytes This post contains Part 4 of the Lisp FAQ. It is cross-posted to the newsgroup comp.lang.scheme because it contains material of interest to Scheme people. The other parts of the Lisp FAQ are posted only to the newsgroups comp.lang.lisp and news.answers. If you think of questions that are appropriate for this FAQ, or would like to improve an answer, please send email to us at lisp-faq@think.com. Lisp/Scheme Implementations and Mailing Lists (Part 4): [4-0] Free Lisp implementations. [4-1] Commercial Lisp implementations. [4-2] Free Scheme implementations. [4-3] Commercial Scheme implementations. [4-4] Other Commercial Lisp-like Language implementations. [4-5] Where can I get an implementation of Prolog in Lisp? [4-6] What is Dylan? [4-7] What Lisp-related discussion groups and mailing lists exist? [4-8] What are R4RS and IEEE P1178? [4-9] How do I do object-oriented programming in Scheme? Search for [#] to get to question number # quickly. ---------------------------------------------------------------- [4-0] Free Lisp implementations. Repositories of Lisp source code are described in the answer to question [6-1]. Remember, when ftping compressed or compacted files (.Z, .arc, .fit, etc.) to use binary mode for retrieving the files. Kyoto Common Lisp (KCL) is free, but requires a license. Conforms to CLtL1. KCL was written by T. Yuasa and M. Hagiya at Kyoto University. Austin Kyoto Common Lisp (AKCL) is a collection of ports, bug fixes and improvements to KCL by Bill Schelter ( or ). {A}KCL generates C code which it compiles with the local C compiler. Both are available by anonymous ftp from rascal.ics.utexas.edu [128.83.138.20], cli.com [192.31.85.1], or [133.11.11.11] (a machine in Japan) in the directory /pub. KCL is in the file kcl.tar, and AKCL is in the file akcl-xxx.tar.Z (take the highest value of xxx). To obtain KCL, one must first sign and mail a copy of the license agreement to: Special Interest Group in LISP, c/o Taiichi Yuasa, Department of Computer Science, Toyohashi University of Technology, Toyohashi 441, JAPAN. Runs on Sparc, IBM RT, RS/6000, DecStation 3100, hp300, hp800, Macintosh II (under AUX), mp386, IBM PS2, Silicon Graphics 4d, Sun3, Sun4, Sequent Symmetry, IBM 370, NeXT and Vax. A port to DOS is in beta test as math.utexas.edu:pub/beta2.zip. Commercial versions of {A}KCL are available from Austin Code Works, 1110 Leafwood Lane, Austin, TX 78750-3409, Tel. 512-258-0785, Fax 512-258-1342, including a CLOS for AKCL. See also Ibuki, below. XLISP is free, and runs on the IBM PC (MSDOS), Amiga (AmigaDOS), Atari ST (TOS), Apple Macintosh, and Unix. It should run on anything with a C compiler. It was written by David Michael Betz, 167 Villa Avenue #11, Los Gatos, CA 95032, 408-354-9303 (H), 408-862-6325 (W), dbetz@apple.com. The reference manual was written by Tim Mikkelsen. Version 2.0 is available by anonymous ftp from cs.orst.edu:/pub/xlisp/ [128.193.32.1] or sumex-aim.stanford.edu:info-mac/lang/ Version 2.1 is the same as XLISP 2.0, but modified to bring it closer to Common Lisp and with several bugs fixed. It can be obtained by anonymous ftp from glia.biostr.washington.edu 128.95.10.115 bikini.cis.ufl.edu 128.227.224.1 in the file xlisp21d.zip and comes with IBM/PC executables. For obtaining a copy through US mail, send email to Tom Almy, toma@sail.labs.tek.com. CMU Common Lisp is free, and runs on Sparcs (Mach and SunOs), DecStation 3100 (Mach), IBM RT (Mach) and requires 16mb RAM, 25mb disk. It includes an incremental compiler, Hemlock emacs-style editor, source-code level debugger, code profiler and is mostly X3J13 compatible, including the new loop macro. It is available by anonymous ftp from any CMU CS machine, such as ftp.cs.cmu.edu [128.2.206.173], in the directory /afs/cs.cmu.edu/project/clisp/release. Login with username "anonymous" and "userid@host" (your email address) as password. Due to security restrictions on anonymous ftps (some of the superior directories on the path are protected against outside access), it is important to "cd" to the source directory with a single command. Don't forget to put the ftp into binary mode before using "get" to obtain the compressed/tarred files. The binary releases are contained in files of the form -_.tar.Z Other files in this directory of possible interest are 16e-source.tar.Z, which contains all the ".lisp" source files used to build version 16e. A listing of the current contents of the release area is in the file FILES. You may also use "dir" or "ls" to see what is available. Bug reports should be sent to cmucl-bugs@cs.cmu.edu. PC LISP is a Lisp interpreter for IBM PCs (MSDOS) available from any site that archives the group comp.binaries.ibm.pc, such as ix1.cc.utexas.edu:/microlib/pc/languages/pc-lisp/ps-lisp.arc wuarchive.wustl.edu:/mirrors/msdos/lisp/pclisp30.zip ucdavis.ucdavis.edu:/pub/pclisp30.zip PC-LISP is a Franz LISP dialect and is by no means Common LISP compatible. It is also available directly from the author by sending 2 blank UNFORMATTED 360K 48TPI IBM PC diskettes, a mailer and postage to: Peter Ashwood-Smith, 8 Du Muguet, Hull, Quebec, CANADA, J9A-2L8; phone 819-595-9032 (home). Source code is available from the author for $15. WCL is an implementation of Common Lisp for Sparc based workstations. It is available free by anonymous ftp from sunrise.stanford.edu in the pub/wcl directory. The file wcl-2.14.tar.Z contains the WCL distribution, including CLX and PCL; wgdb-4.2.tar.Z contains a version of the GDB debugger which has been modified to grok WCL's Lisp; and gcc-2.2.2.tar.Z contains the GNU C compiler. WCL provides a large subset of Common Lisp as a Unix shared library that can be linked with Lisp and C code to produce efficient and small applications. WCL provides CLX R5 as a shared library, and comes with PCL and a few other utilities. For further information on WCL, see the paper published in the proceedings of the 1992 Lisp and Functional Programming Conference, a copy of which appears in the wcl directory as lfp-paper.ps, or look in the documentation directory of the WCL distribution. Please direct any questions to Wade Hennessey, wade@sunrise.stanford.edu. If you would like to be added to a mailing list for information about new releases, send email to wcl-request@sunrise.stanford.edu. CLISP is a Common Lisp (CLtL1) implementation by Bruno haible and Michael Stoll of Karlsruhe University in Germany. German and English versions are available. It runs on Atari-ST, DOS, Linux, and Sun4 (SunOS 4.1.1), An OS/2 port is in progress. CLISP is for non-profit use at universities and at home, not at companies. It includes an interpreter and a compiler. Some of the implementations may be slightly buggy. Some include PCL; others include only Closette. Available by anonymous ftp from ma2s2.mathematik.uni-karlsruhe.de in the directory /pub/lisp/clisp. For more information, contact haible@ma2s2.mathematik.uni-karlsruhe.de. ---------------------------------------------------------------- [4-1] Commercial Lisp implementations. Macintosh Common Lisp (MCL 2.0) runs on the Apple Macintosh (Mac+ or higher with 4mb RAM and system software 6.0.4 or later or AUX 3.0) and is available from APDA for $495. It includes a native CLOS Macintosh Toolbox/interface toolkit, ephemeral garbage collection, incremental compiler, window-based debugger, source-code stepper, object inspector, emacs-style editor, and a foreign function interface. With MCL version 2.0, Apple has started distributing a CD-ROM which contains, among other things, a large collection of Lisp code, complete MCL manuals in an online-browser format, the CLIM 1.0 manual in TeX and postscript, and copies of Gambit 1.8 Scheme, SIOD 2.8 Scheme, Pixie Scheme, and a demo version of MacScheme. For more information, write to: APDA, Apple Computer Inc., 20525 Mariani Avenue, MS 33-G, Cupertino, CA 95014-6299 or call toll free 1-800-282-2732 (US), 1-800-637-0029 (Canada), 1-408-562-3910. Their fax number is 1-408-562-3971 and their telex is 171-576. Email may also be sent to APDA@applelink.apple.com. CLIM for MCL is available as a separate product from Lucid, Inc., 707 Laurel Street, Menlo Park, CA 94025 U.S.A., 415-329-8400, fax: 415-329-8480, . Procyon Common Lisp runs on either the Apple Macintosh or IBM PC (386/486 or OS/2 native mode), costing 450 pounds sterling (educational), 1500 pounds ($795) commercial. It requires 2.5mb RAM on the Macintosh and 4mb RAM on PCs (4mb and more than 4mb recommended respectively). It is a full graphical environment, and includes a native CLOS with meta-object protocol, incremental compilation, foreign function interface, object inspector, text and structure editors, and debugger. Write to: Scientia Ltd., St. John's Innovation Centre, Cowley Road, Cambridge, CB4 4WS, UK, with phone +44-223-421221, fax +44-223-421218, and email UK0061@applelink.apple.com. An alternate address for US customers is: ExperTelligence, Inc., 5638 Hollister Ave, Suite 302, Goleta, CA 93117, or call 1-800-828-0113, (805) 967-1797. Their fax is (805) 964-8448 and email is D2042@applelink.apple.com. [The rights to the MS Windows version of Procyon were sold to Franz who are marketing and developing it as Allegro CL\PC. See Allegro's entry for more information.] Franz Lisp 2.0 runs on the Apple Macintosh, requiring 1mb RAM for the interpreter ($99) and 2.5mb RAM for the compiler ($199). Student prices are $60 for the interpreter and $110 for the interpreter and compiler. Includes editor and language reference manual. Complete sources are available for $649. The ALJABR symbolic mathematics system costs $249. Write to: Fort Pond Research, 15 Fort Pond Road, Acton, MA 01720, call 1-508-263-9692, or send mail to order@fpr.com. Allegro Common Lisp 4.1 runs on a variety of platforms, including Sparcs and DecStations ($3750), as well as the NeXT ($1875). It requires 12mb RAM for the 680x0 and 16mb for RISC. It includes native CLOS, X-windows support, Unix interface, incremental compilation, generational garbage collection, and a foreign function interface. Options include Allegro Composer (development environment, including debugger, inspector, object browser, time/space code profiler, and a graphical user interface), Common LISP Interface Manager (CLIM is a Symbolic's Dynamic Windows clone) and Allegro CLIP (a parallel version of Lisp for the Sequent). Franz has bought the rights to the Windows version of Procyon CL, and are now marketing it as Allegro CL\PC for Windows 3.1. Write to: Franz Inc., 1995 University Avenue, Berkeley, CA 94704 or call (510) 548-3600 (area code was 415), fax (510) 548-8253, telex 340179 WUPUBTLXSFO. Bug reports can be mailed to bugs@franz.com. Questions about Franz Inc. products (e.g., current and special pricing) can be sent to info@franz.com. Ibuki Common Lisp is a commercialized and improved version of Kyoto Common Lisp. It runs on over 30 platforms, including Sun3, Sparc, Dec (Ultrix), Apollo, HP 9000, IBM RS/6000, Silicon Graphics and IBM PCs. It includes an incremental compiler, interpreter, foreign function interface. It generates C code from the Lisp and compiles it using the local C compiler. Image size is about 3mb. Cost is $2800 (workstations), $3500 (servers), $700 (IBM PCs). Supports CLOS and CLX ($200 extra). Source code is available at twice the cost. Ibuki now also has a product called CONS which compiles Lisp functions into linkable Unix libraries. Write to: Ibuki Inc., PO Box 1627, Los Altos, CA 94022, or call 415-961-4996, fax 415-961-8016, or send email to Richard Weyhrauch, rww@ibuki.com. Lucid Common Lisp runs on a variety of platforms, including PCs (AIX), Apollo, HP, Sun-3, Sparc, IBM RT, IBM RS/6000, Decstation 3100, Silicon Graphics, and Vax, and costs $2500 (IBM PCs), $4400 (other platforms). Lucid includes native CLOS, a foreign function interface, and generational garbage collection. CLIM is available for Lucid as a separate product. Write to Lucid Inc., 707 Laurel Street, Menlo Park, CA 94025, call toll free 800-225-1386 (or 800-843-4204), 415-329-8400, fax 415-329-8480, or email to sales@lucid.com for information on pricing, product availability, etc. Technical questions may be addressed to customer-support@lucid.com. See also the comments in question [1-1] on the wizards.doc file that comes with the release. Medley is a Common Lisp development environment that includes a native CLOS w/MOP, window toolkit, window-based debugger, incremental compiler, structure editor, inspectors, stepper, cross-referencer, code analysis tools, and browsers. It is the successor to InterLisp-D. It runs on a variety of platforms, including Suns, DecStations, 386/486s, IBM RS/6000, MIPS, HP, and Xerox 1186. Requires Unix and 8mb RAM. Developer version costs $995 and run-time version $300. Instructional costs $250/copy or $1250 site license. Write to: Venue, 1549 Industrial Rd, San Carlos, CA 94070, call 1-800-228-5325, 1-415-508-9672, fax 415-508-9770, or email aisupport.mv@envos.xerox.com. Golden Common Lisp (GCLisp) runs on IBM PCs under DOS and Windows, costing $2,000 ($250 extra for Gold Hill Windows), and includes an incremental compiler, foreign function interface, interactive debugger, and emacs-like editor. It supports DDE and other Windows stuff, and is CLtL1 compatible. Supports PCL. It requires 4mb RAM, and 12mb disk. See a review in PC-WEEK 4/1/91 comparing GCLisp with an older version of MCL. Write to: Gold Hill Computers, 26 Landsdowne Street, Cambridge, MA 02139, call (617) 621-3300, or fax (617) 621-0656. Star Sapphire Common LISP provides a subset of Common Lisp and includes an emacs-like editor, compiler, debugger, DOS graphics and CLOS. It runs on IBM PCs (MSDOS), requires 640k RAM, a hard disk, and costs $100. Write to: Sapiens Software Corporation, PO Box 3365, Santa Cruz, CA 95063-3365, call (408) 458-1990, or fax (408) 425-0905. Sapiens Software also has a Lisp-to-C translator in beta-test. NanoLISP is a Lisp interpreter for DOS systems that supports a large subset of the Common Lisp standard, including lexical and dynamic scoping, four lambda-list keywords, closures, local functions, macros, output formatting, generic sequence functions, transcendental functions, 2-d arrays, bit-arrays, sequences, streams, characters double-floats, hash-tables and structures. Runs in DOS 2.1 or higher, requiring only 384k of RAM. Cost is $100. Write to: Microcomputer Systems Consultants, PO Box 6646, Santa Barbara, CA 93160 or call (805) 967-2270. Software Engineer is a Lisp for Windows that creates small stand-alone executables. It is a subset of Common Lisp, but includes CLOS. It requires 2mb RAM, but can use up to 16mb of memory, generating 286 specific code. It costs $250. Write to: Raindrop Software, 833 Arapaho Road, Suite 104, Richardson, TX 75081, call (214) 234-2611, or fax (214) 234-2674. muLISP-90 is a small Lisp which runs on IBM PCs (or the HP 95LX palmtop), MS-DOS version 2.1 or later. It isn't Common Lisp, although there is a Common Lisp compatibility package which augments muLISP-90 with over 450 Common Lisp special forms, macros, functions and control variables. Includes a screen-oriented editor and debugger, a window manager, an interpreter and a compiler. Among the example programs is DOCTOR, an Eliza-like program. The runtime system allows one to create small EXE or COM executables. Uses a compact internal representation of code to minimize space requirements and speed up execution. The kernel takes up only 50k of space. Costs $400. Write to Soft Warehouse, Inc., 3660 Waialae Avenue, Suite 304, Honolulu, HI 96816-3236, call 1-808-734-5801, or fax 1-808-735-1105. CLOE (Common Lisp Operating Environment) is a cross-development environment for IBM PCs (MSDOS) and Symbolics Genera. It includes CLOS, condition error system, generational garbage collection, incremental compilation, code time/space profiling, and a stack-frame debugger. It costs from $625 to $4000 and requires 4-8mn RAM and a 386 processor. Write to: Symbolics, 6 New England Tech Center, 521 Virginia Road, Concord, MA 01742, call 1-800-394-5522 or 508-287-1000 or fax 508-287-1099. Top Level Common Lisp includes futures, a debugger, tracer, stepper, foreign function interface and object inspector. It runs on Unix platforms, requiring 8mb RAM, and costs $687. Write to: Top Level, 100 University Drive, Amherst, MA 01002, call (413) 549-4455, or fax (413) 549-4910. Harlequin Lispworks runs on a variety of Unix platforms, including Sun3, Sparc, RS/6000, DEC (MIPS), MIPS, Intergraph, HP 400, HP 700, and IBM PCs. It is a full graphical Common Lisp environment and costs $2500. Harlequin is coming out with a delivery 386 Lisp in June 1992. Common Lisp: CLtL2 compatible, native CLOS/MOP, generational GC, Fortran/C/C++/SQL interface. Environment : Prolog, Emacs-like editor/listener/shell, defadvice, defsystem, cross-referencing, lightweight processes, debugger, mail reader, extensible hypertext online doc. Browsers/graphers: files, objects, classes, generic functions, source code systems, specials, compilation warnings. Graphics: CLX, CLUE, toolkit, CLIM, Open Look, Motif, interface builder, program visualization. Integrated Products: KnowledgeWorks (RETE engine) Write to: Harlequin Limited, Barrington Hall, Barrington, Cambridge, CB2 5RG, call 0223 872522 (or 44223 872522 outside UK), telex 818440 harlqn g, fax 0223 872519, or send email to ai@uk.co.harlqn (or ai@harlqn.co.uk for US people) or info@harlqn.co.uk. Lisp-to-C Translator translates Common Lisp into C, but requires that you specify when and where you'd like your garbage to be collected. It costs $12,000. Write to: Chestnut Software, Inc., 636 Beacon Street, Boston, MA 02215, call (617) 262-0914, or fax (617) 536-6469. Poplog Common Lisp is an integrated Lisp/Prolog environment with an incremental compiler. It runs on a variety of platforms, including Unix ($749), Sparc ($4500), Macintosh AUX ($749), and VAX/VMS ($4500). Write to: Computable Functions, Inc., 35 South Orchard Drive, Amherst, MA 01002, call (413) 253-7637, or fax (413) 545-1249. Clisp is a library of functions which extends the C programming language to include some of the functionality of Lisp. Costs $349. Write to Drasch Computer Software, 187 Slade Road, Ashford, CT 06278, or call 1-203-429-3817. Two references in Dr. Dobb's journal on Lisp-style libraries for C are: Douglas Chubb, "An Improved Lisp-Style Library for C", Dr. Dobb's Jounral #192, September 1992, and Daniel Ozick, "A Lisp-Style Library for C", Dr. Dobb's Journal #179:36-48, August 1991. Source is available by ftp from various archives, including wuarchive.wustl.edu (MSDOSDDJMAG), or ftp.mv.com:/pub/ddj, or the DDJ Forum on Compuserve. Other Lisps for PCs include: o UO-LISP from Calcode Systems, e-mail:calcode!marti@rand.org It comes complete with compiler and interpreter, and is optimised for large programs. It is Standard LISP, not Common LISP. They are based in Amoroso Place in Venice, CA. o LISP/88 v1.0. Gotten from Norell Data Systems, 3400 Wilshire Blvd, Los Angeles, CA 90010, in 1983. They may or may not still exist. o IQLisp. Not a Common Lisp but still very good for PCs - you can actually get a lot done in 640K. The lisp itself runs in less than 128K and every cons cell takes only 6 bytes. Unfortunately that makes the 640K (maybe a little more, but certainly no more than 1M) limit really hard. It has a byte code compiler which costs extra. This has support for all sorts of PC specific things. It costs $175 w/o compiler, $275 with. Write to: Integral Quality, Box 31970, Seattle, WA 98103, call Bob Rorschach, (206) 527-2918 or email rfr@franz.com. Lisps which run on special-purpose hardware (Lisp Machines) include o Symbolics 1-800-394-5522 (508-287-1000) fax 508-287-1099 6 New England Tech Center, 521 Virginia Road, Concord MA 01742 o TI Explorers o Xerox Interlisp. See Medley above. ---------------------------------------------------------------- [4-2] Free Scheme implementations. Repositories of Scheme source code are described in the answer to question [6-2]. Remember, when ftping compressed or compacted files (.Z, .arc, .fit, etc.) to use binary mode for retrieving the files. Many free Scheme implementations are available from altdorf.ai.mit.edu [18.43.0.246]. See also the Scheme Repository described below. The Scheme Repository contains a Scheme bibliography, copies of the R4RS report, sample Scheme code for a variety of purposes, several utilities, and some implementations. The repository is maintained by Ozan S. Yigit, scheme@nexus.yorku.ca. The repository is accessible by anonymous ftp at nexus.yorku.ca [130.63.9.66] in the directory pub/scheme/. PC-Scheme, free by anonymous ftp from altdorf.ai.mit.edu in the directory /archive/pc-scheme/. Written by Texas Instruments. Runs on MS-DOS 286/386 IBM PCs and compatibles. Includes an optimizing compiler, an emacs-like editor, inspector, debugger, performance testing, foreign function interface, window system and an object-oriented subsystem. Conforms to the Revised^3 Report on Scheme. Also supports the dialect used in Abelson and Sussman's SICP. The official commercialized implementation costs $95 and includes a reference manual and user's guide. Write to: Texas Instruments, 12501 Research Boulevard, MS 2151, Austin, TX 78759 and order TI Part number #2537900-0001, or call 1-800-TI-PARTS and order it using your Visa or Mastercard. [NOTE: Ibuki announced on July 13, 1992, that it has purchased the rights to PC Scheme from TI and intends to make it also available on 486 PCs and under Windows 3.1. For more information, contact IBUKI, PO Box 1627, Los Altos, CA 94022, phone (415) 961-4996, fax (415) 961-8016, email rww@ibuki.com.] PCS/Geneva is a cleaned-up version of Texas Instrument's PC Scheme developed at the University of Geneva. The main extensions to PC Scheme are 486 support, BGI graphics, LIM-EMS pagination support, line editing, and assmebly-level interfacing. (TI's PC Scheme gives users full Revised^3 support along with many primitives for DOS, Graphics and Text Windows. A powerful built-in optimizing compiler produces fast code.) The beta version of PCS/Geneva has been tested on XTs, ATs, AT386s and AT486s under various DOS and OS/2 versions. It even runs on Hewlett-Packard's HP95LX. To receive a copy of PCS/Geneva, please send email to schemege@uni2a.unige.ch. You will be given instructions on obtaining PCS/Geneva by FTP. The purpose of the mailing detour is to keep track of the users and diffuse bug reports along with corrections. MIT Scheme (aka C-Scheme), free by anonymous FTP from altdorf.ai.mit.edu in the directory pub/scheme-7.1 (for the architectures MC68020/30/40, HP Prevision Architecture, MIPS, VAX, Intel 386/486, and DEC Alpha). Directory scheme-7.2 contains preliminary *alpha* versions of the next release of MIT C-Scheme for the MIPS and Intel 386/486 (MS-DOS, Windows 3.x and Unix) architectures. (The port includes Edwin, Scheme's Emacs-like editor and Liar, the Scheme compiler. If you acquire the alpha release through ftp, please send mail to info-cscheme-dos-request@zurich.ai.mit.edu so they know to send you updates and bug reports. Bugs in the DOS version should be send to bug-cscheme-dos@zurich.ai.mit.edu.) Does not have a convenient foreign function interface yet. FTP distribution includes MIT C-Scheme Reference and User manuals, as well as the Revised^4 Report on Scheme. Send bug reports to bug-cscheme@zurich.ai.mit.edu. For DOS floppy distribution requests (includes printed copies of manuals), send $95.00 (payable in U.S. funds to "Scheme Distribution") to cover costs of distribution to Scheme Distribution, c/o Prof. Hal Abelson, 545 Technology Sq. rm 410, Cambridge MA 02139, USA. | On the NeXT, MIT Scheme is available as part of the Schematik package, which provides an editor/front-end user interface, graphics, and "robotics" support for Lego and the like. Schematik is free and is available for anonymous ftp from ftp.gac.edu in the pub/next/scheme directory. Europeans can get it more locally from ftp.informatik.uni-muenchen.de, in the directory /pub/next/ProgLang; start with Schematik-1.1.5.1.README . Schematik is also apparently included on NeXT's "Educational Software Sampler" CD-ROM. SCM, free by anonymous ftp from altdorf.ai.mit.edu:archive/scm or nexus.yorku.ca:pub/oz/scheme/new. Current version 4a12. Runs on Amiga, IBM PC, VMS, Macintosh, Unix, and similar systems. Scm conforms to the Revised^4 Report on the Algorithmic Language Scheme and the IEEE P1178 specification. Scm is written in C. ASCII and EBCDIC are supported. To receive an IBM PC floppy disk with the source files and MSDOS executable send $60 ($65 for i386 version) to Aubrey Jaffer, 84 Pleasant St. Wakefield MA 01880, USA. Turtlscm is SCM with turtle graphics for MSDOS systems. Written by Mkinen Sami , it is available from altdorf.ai.mit.edu:archive/scm/turtlscm4a10.lzh or nexus.yorku.ca:pub/scheme/new/turtlscm4a10.lzh. X-SCM is an interface to Xlib and the Motif and OpenLook toolkits for the SCM interpreter. It requires scm4a10 or later. It should be available at any archive of alt.sources. Contact campbell@redsox.bsw.com for more information. SMG-SCM is a package that adds VMS SMG screen management routines to SCM. It is available from both altdorf and nexus as the file sgm-scm.com. SMG-SCM.COM is a DCL command procedure; execute it to extract the source code, documentation, and example code. Send comments and bugs to T. Kurt Bond, . Gambit is an optimizing Scheme compiler/system. It supports the IEEE Scheme standard and `future' construct. It runs on M680x0 based unix machines, such as Sun3, HP300, BBN GP1000, NeXT, and the Apple Macintosh. For the Macintosh, only the interpreter is available by FTP; the author, Marc Feeley, requests $40 for the complete Gambit Scheme System (compiler, linker, source code) for the Macintosh. It is available by anonymous ftp from trex.iro.umontreal.ca [132.204.36.34] in the directory pub/gambit/. Versions 1.7, 1.7.1, 1.8.2 and 1.9 may be found in this directory. Contact Marc Feeley at feeley@iro.umontreal.ca for more information. A Macintosh version may be obtained from /afs/umich.edu/group/itd/archive/mac/development/languages as the file gambitscheme1.8.cpt.hqx if your site runs the Andrew File System, or by anonymous ftp from mac.archive.umich.edu. T3.1 is a Scheme-like language developed at Yale. Available by anonymous ftp from ftp.ai.mit.edu in the directory pub/systems/t3.1. (T may be obtained in Europe from nic.funet.fi in the directory pub/unix/languages/scheme/t3.1 or from ftp.diku.dk in the directory pub/t3.1) Runs on DecStations (MIPS processor) and SGI Iris, Sun4 (SPARC), Sun3, Vax/Unix. Includes a copy of the online version of the T manual and release notes for T3.0 and T3.1. All implementations include a foreign function (C) interface. To be informed of fixes, new releases, etc., send your email address to t-project@cs.yale.edu. Bug reports should go to t3-bugs@cs.yale.edu. A multiprocessing version of T (for Encore Multimax) is available from masala.lcs.mit.edu:/pub/mult. Oaklisp is an seamless integration of Scheme with an object-oriented substrate. Available by anonymous ftp from f.gp.cs.cmu.edu [128.2.250.164] in the directory /usr/bap/oak/ftpable, and includes reference and implementation manuals. Elk (Extension Language Kit) is a Scheme interpreter designed to be used as a general extension language. Available by anonymous ftp from the Scheme Repository in nexus.yorku.ca:/pub/scheme/imp/. Also available in the X contrib directory on export.lcs.mit.edu. Runs on Unix, SunOs, and Ultrix based platforms, including VAX, Sun3, Sun4 (Sparc), 680x0, 80386, MIPS, and IBM RT. The Elk interpreter is mostly R3RS compatible. Elk has interfaces to Xlib, Xt and the various widget sets. Implemented by Oliver Laumann. EuLisp is available from gmdzi.gmd.de [129.26.8.90] in the /lang/lisp/eulisp directory. EuLisp has an object system, and is sort of like an extended Scheme. Feel (Free and Eventually Eulisp) is an initial implementation of the eulisp language. It can be retrieved by anonymous FTP from ftp.bath.ac.uk in the directory /pub/eulisp/ as the file feel-0.75.tar.Z. feel-0.75.sun4.Z is the Sparc executable. The language definition is in the same directory. It includes an integrated object system, a module system, and support for parallelism. The program is a C-based interpreter, and a bytecode interpreter/compiler will be available sometime soon. The distribution includes an interface to the PVM library, support for TCP/IP sockets, and libraries for futures, Linda, and CSP. Feel is known to run on Sun3, Sun4, Stardent Titan, Alliant Concentrix 2800, Orion clippers, DEC VAX, DECstation 3000, Gould UTX/32, and Inmos T800 transputer (using CS-Tools). (All bar the last four have a threads mechanism.) It can run in multi-process mode on the first three machines, and hopefully any other SysV-like machine with shared memory primitives. Porting Feel to new machines is reasonably straightforward. It now also runs on MS-DOS machines. Written by Pete Broadbery, pab@maths.bath.ac.uk. Scheme->C compiles R3RS Scheme to C that is then compiled by the native C compiler for the target machine. Runs on Vaxen and DecStation 3100s running Ultrix, as well as Sun3, Sun4, Amiga (SAS/C 5.10b), HP 9000/700 and Apollo. It is available for anonymous ftp from gatekeeper.dec.com [16.1.0.2] in /pub/DEC/Scheme-to-C. There are two interfaces to X-windows available, Ezd (a drawing system) and SCIX (Scheme Interface to X), implemented using Scheme-to-C. Both should be available by ftp from gatekeeper. Information on obtaining documentation for Scheme->C may be obtained by sending mail to WRL-Techreports@decwrl.dec.com with subject line "help". SIOD (Scheme in One Defun), free by anonymous ftp from nexus.yorku.ca:pub/scheme/imp/siod-v2.9-shar world.std.com:src/lisp/siod-v2.9-shar or in any comp.sources.unix archive. Runs on VAX/VMS, VAX UNIX, Sun3, Sun4, Amiga, Macintosh, MIPS, Cray. Small scheme implementation in C arranged as a set of subroutines that can be called from any main program for the purpose of introducing an interpreted extension language. Compiles to ~20K bytes of executable. Lisp calls C and C calls Lisp transparently. XScheme is available free by anonymous ftp from ftp.uu.net in the directories MSDOS/languages/X-scheme and amiga-sources/xscheme.20.zoo. It was written by David Michael Betz, 167 Villa Avenue #11, Los Gatos, CA 95032, 408-354-9303 (H), 408-862-6325 (W), dbetz@apple.com. XScheme is discussed in the newsgroup comp.lang.lisp.x. It may also be found in the Scheme Repository. Fools' Lisp is a small Scheme interpreter that is R4RS conformant, and is available by anonymous ftp from scam.berkeley.edu [128.32.138.1] in the directory src/local/fools.tar.Z. Runs on Sun3 and Sun4 (SunOs), DecStation 3100s, Vax (Ultrix), Sequent, and Apollo. Implemented by Jonathan Lee . Scheme84 is in the public domain, and available by mail from Indiana University. It runs on the VAX under either VMS or BSD Unix. To receive a copy, send a tape and return postage to: Scheme84 Distribution, Nancy Garrett, c/o Dan Friedman, Department of Computer Science, Indiana University, Bloomington, Indiana. Call 1-812-335-9770 or send mail to nlg@indiana.edu for more information. Scheme48 is an implementation of the Scheme programming language as described in the Revised^4 Report on the Algorithmic Language Scheme. It is based on a compiler and interpreter for a virtual Scheme machine. The name derives from the author's desire to have an implementation that is simple and lucid enough that it looks as if it were written in just 48 hours. This is an alpha release, but the goal is to produce a bullet-proof system. Send bug reports to scheme48-bugs@altdorf.ai.mit.edu. It is available by anonymous ftp from nexus.yorku.ca in /pub/scheme/imp/s48.tar.Z. Written by Richard Kelsey and Jonathan Rees. UMB Scheme is a R4RS Scheme available by anonymous ftp from ucbarpa.berkeley.edu in pub/UMB_scheme.tar.Z and also in the Scheme Repository. It includes a simple editor, debugger, Written by William Campbell, University of Massachusetts at Boston, bill@cs.umb.edu. VSCM is a R4RS Scheme available by anonymous ftp from the Scheme Repository, nexus.yorku.ca:pub/scheme/imp/vscm92Nov2.tar.Z (130.63.9.66) Written by Matthias Blume, . The implementation is based on a virtual machine design with heavy support for most of the sophisticated features of Scheme. The virtual machine is written in ANSI-C to aid in its portability. Pixie Scheme for the Macintosh is a nearly complete implementation of R3RS available by anonymous ftp from rascal.ics.utexas.edu:/misc/mac/programming/ Pixie.Goodies.SIT.bin Pixie.NoFPP.world.SIT.bin Pixie.world.SIT.bin PixieScheme.NoFPP.SIT.bin ; for macs without floating-point coprocessor PixieScheme.SIT.bin ; for macs with FPP Pixie_Scheme_Help.SIT.bin Pixie_intro Written by Jay Reynolds Freeman , P. O. Box 60628, Palo Alto, CA, 94306-0628. A copy may also be obtained from /afs/umich.edu/group/itd/archive/mac/development/languages as the file pixiescheme.cpt.hqx if your site runs the Andrew File System, or by anonymous ftp from mac.archive.umich.edu. HELP (a lazy Scheme) is available by anonymous ftp from sumex-aim.stanford.edu:/info-mac/lang/lazy-scheme.hqx. Written by Thomas Schiex (schiex@cert.fr, schiex@irit.fr). Help is a complete and efficient Scheme-like functional lazy Lisp interpreter. It works only on 68020 (or more) based Macintoshes. It has a 'friendly' interface (parenthesis matcher, auto-indent), uses a full call-by-need semantics and includes many examples, including a symbolic compiler for the 680x0. Efficiency is good and lazyness is fully parametrizable (you may turn Help into a strict Scheme-like language if you like). French AND English updated docs are included in Word4 and plain text formats. Similix is a a Self-Applicable Partial Evaluator for a Subset of Scheme. Written by Anders Bondorf and Olivier Danvy. It is available by anonymous ftp from nexus.yorku.ca in the directory /pub/scheme/imp as similix.tar.Z or from ftp.diku.dk:misc/Similix.tar.Z. For more information, contact Anders Bondorf, DIKU, Department of Computer Science, University of Copenhagen, Universitetsparken 1, DK-2100 Copenhagen, Denmark, or send email to anders@diku.dk. Similix may be run in Chez Scheme and T3.1. Free Scheme Implementations implemented in Lisp: Peter Norvig's book "Paradigms of AI Programming" has a chapters about Scheme interpreters and compilers, both written in Common Lisp. The software from the book is available by anonymous ftp from unix.sri.com:pub/norvig and on disk in Macintosh or DOS format from the publisher, Morgan Kaufmann. For more information, contact: Morgan Kaufmann, Dept. P1, 2929 Campus Drive, Suite 260, San Mateo CA 94403, or call Toll free tel: (800) 745-7323; FAX: (415) 578-0672 PseudoScheme is available free by anonymous ftp from altdorf.ai.mit.edu:/archive/pseudo/pseudo-2-8.tar.Z. It is Scheme implemented on top of Common Lisp, and runs in Lucid, Symbolics CL, VAX Lisp under VMS, and Explorer CL. It should be easy to port to other Lisps. It was written by Jonathan Rees (jar@altdorf.ai.mit.edu, jar@cs.cornell.edu). Send mail to info-clscheme-request@mc.lcs.mit.edu to be put on a mailing list for announcements. Conforms to R3RS except for lacking a correct implementation of call/cc. It works by running the Scheme code through a preprocessor, which generates Common Lisp code. Scheme88 is available by anonymous ftp from rice.edu:public/scheme88.sh and also from the Scheme Repository. ---------------------------------------------------------------- [4-3] Commercial Scheme implementations. Chez Scheme is fully compatible with the IEEE and R4RS standards for the Scheme programming language and includes an incremental compiler, object inspector, multitasking with engines, and a foreign function interface. It runs on Sparc and Sun3 (SunOs), Vax and DecStation (Ultrix), NeXT, Silicon Graphics, and Motorola Delta 88000, costs approximately $2000 and requires 4-8mb RAM. Implemented by Kent Dybvig, Robert Hieb, and Carl Bruggeman. Write to: Cadence Research Systems, 620 Park Ridge Road, Bloomington, IN 47408, call (812) 333-9269, or fax (812) 332-4688. email: dyb@cs.indiana.edu or dyb@cadence.bloomington.in.us MacScheme is a Scheme interpreter and compiler for the Apple Macintosh, and includes an editor, debugger and object system. MacScheme costs $125 (includes compiler) and Scheme Express costs $70 (interpreter only). It requires 1mb RAM. A development environment (MacScheme+Toolsmith) costs $495. Conforms to the Revised^4 Report on the Algorithmic Language Scheme. MacScheme+Toolsmith includes support for menus, windows, and interfaces to the Macintosh Toolbox, and can create small standalone Macintosh executables. Implemented by Will Clinger, John Ulrich, Liz Heller and Eric Ost. Write to: Lightship Software, PO Box 1636, Beaverton, OR 97075, or call (503) 292-8765. They're moving to California. The temporary phone number is 415-940-4008 (Liz Heller). The new phone number will be 415-694-7799. MacScheme is distributed by ACS, 2015 East 3300 South, Salt Lake City, UT 84109-2630, 1-800-531-3227 (801-484-3923). EdScheme runs on Macintosh, DOS and Atari ST and costs $50. It includes an incremental compiler, and editor, and is a close match to the IEEE standard. Implemented by Iain Ferguson, Edward Martin, and Burt Kaufman. The book (The Schemer's Guide) is 328 pages long costs $30. Write to: Schemers Inc., 4250 Galt Ocean Mile, Suite 7U, Fort Lauderdale, FL 33308, call (305) 776-7376, or fax (305) 776-6174. You can also send email to 71020.1774@compuserve.com. They also offer an Archimedes (Acorn) platform which is only available through their European distributor, Lambda Publications, who is reachable by phone at 44-793-695296 or by EMail on 100015.1465@compuserve.com. ---------------------------------------------------------------- [4-4] Other Commercial Lisp-like Language implementations. Le-Lisp includes a compiler, color and graphic output, a debugger, a pretty printer, performance analysis tools, tracing, and incremental execution. Le-Lisp is Macintosh AUX 2.0 Compatible and also runs on Unix platforms. Note that Le-Lisp is neither Common Lisp nor Scheme. Le-Lisp was originally developed in 1980 at Inria, the French national computer science laboratory, by a team led by Jerome Chailloux for work on VLSI design. It was based on several earlier Lisps in the MacLisp family, but was not directly derived from MacLisp. Le-Lisp enjoyed a large success in the French academic world because it was small, fast, and portable, being based on a abstract machine language called LLM3. In 1983, for example, Le-Lisp ran on Z-80 machines running CP/M. In 1987, Ilog was formed as an offshoot of Inria to commercialize and improve Le-Lisp and several products which had been developed with it, including a portable graphic interface system and an expert system shell. Since then, Ilog has continued to grow and expand the use of Le-Lisp into industrial markets around the world. Ilog is the largest European Lisp vendor, and continues to develop new products and markets for Lisp. In 1992, Ilog released the next major version of Le-Lisp, Le-Lisp version 16. This version modernizes Le-Lisp for use in the industrial world, adding lexical closures and special-form-based semantics for static analysis, a new object system based on the EuLisp object system (TELOS), an enhanced module system for application production, a conservative GC for integration with C and C++, and compilation to C for portability and efficiency on a wide range of processors. For pricing and other information, write to ILOG, 2 Avenue Gallieni, BP 85, 94253 Gentilly Cedex, France, call 33-1-46-63-66-66 or fax 33-1-46-63-15-82. Jerome Chailloux (chaillou@ilog.ilog.fr). ---------------------------------------------------------------- [4-5] Where can I get an implementation of Prolog in Lisp? Implementations of Prolog in Lisp: The Frolic package from the University of Utah is written in Common Lisp and available by anonymous ftp from cs.utah.edu:pub/frolic.tar.Z Prolog in Scheme is a collection of macros that expand syntax for clauses, elations, and so on. It is written in Scheme and has support for delayed goals and interval arithmetic. It is known to run in Chez Scheme and in Elk, and is intended to be portable to other Scheme implementations. It relies on continuations, and so is not easily ported to Common Lisp. Available from the University of Calgary by anonymous ftp from fsa.cpsc.ucalgary.ca:pub/prolog1.2/prolog12.tar.Z Questions and comments may be addressed to Alan Dewar or John Cleary . An implementation of prolog for Chez Scheme is available by anonymous ftp from titan.rice.edu:public/slog.sh. It is a collection of macros that expand syntax for clauses, elations, and so on into pure Scheme. It should be easily portable to other Schemes. Its use of higher-order continuations is probably a major obstacle to porting it to Common Lisp. For more information, please contact the author: dorai@cs.rice.edu. LM-PROLOG by Ken Kahn and Mats Carlsson is written in ZetaLisp and not easily portable to Common Lisp. It is available by anonymous ftp from sics.se:archives/lm-prolog.tar.Z. Peter Norvig's book "Paradigms of AI Programming" includes Common Lisp implementations of a prolog interpreter and compiler. The software is available by anonymous ftp from unix.sri.com:pub/norvig and on disk in Macintosh or DOS format from the publisher, Morgan Kaufmann. For more information, contact: Morgan Kaufmann, Dept. P1, 2929 Campus Drive, Suite 260, San Mateo CA 94403, (800) 745-7323; FAX: (415) 578-0672 Harlequin's LispWorks comes with Common Prolog -- a fast Edinburgh-compatible Prolog integrated with Common Lisp. Write to: Harlequin Limited, Barrington Hall, Barrington, Cambridge, CB2 5RG, call 0223 872522 (or 44223 872522 outside UK), telex 818440 harlqn g, fax 0223 872519, or send email to ai@uk.co.harlqn (or ai@harlqn.co.uk for US people). ---------------------------------------------------------------- [4-6] What is Dylan? Dylan is a new object-oriented dynamic language (oodl), based on Scheme, CLOS, and Smalltalk. The purpose of the language is to retain the benefits of oodls and also allow efficient application delivery. The design stressed keeping Dylan small and consistent, while allowing a high degree of expressiveness. A manual/specification for the language is available from Apple Computer. Send email to dylan-manual-request@cambridge.apple.com or write to Apple Computer, 1 Main Street, Cambridge, MA 02142. Include your complete address and also a phone number (the phone number is especially important for anyone outside the US). Comments on Dylan can be sent to the internet mail address dylan-comments@cambridge.apple.com. The mailing list info-dylan@cambridge.apple.com is for any and all discussions of Dylan, including language design issues, implementation issues, marketing issues, syntax issues, etc. The mailing list announce-dylan@cambridge.apple.com is for major announcements about Dylan, such as the availability of new implementations, new versions of the manual, etc. This mailing list should be *much* lower volume than info-dylan. Everything sent to this list is also sent to info-dylan. The mailing list dylan-builders@cambridge.apple.com is for people who are working on Dylan implementations. (To be added to dylan-builders, send a note describing your implementation plans to dylan-builders-request.) Apple hopes to set up a comp.lang.dylan newsgroup to be gatewayed to the info-dylan mailing list. Send mail to the -request version of the list to be added to it. Apple hasn't announced plans to release Dylan as a product. The directory cambridge.apple.com:pub/dylan contains some documents pertaining to Dylan, including a FAQ list. ======== Thomas is a compiler for a language that is compatible with the language described in the book "Dylan(TM) an object-oriented dynamic language" by Apple Computer Eastern Research and Technology, April 1992. Thomas was written at Digital Equipment Corporation's Cambridge Research Laboratory. Thomas is NOT Dylan(TM) and was built with no direct input, aid, assistance or discussion with Apple. Thomas is available to the public by anonymous ftp at crl.dec.com:pub/DEC/Thomas gatekeeper.pa.dec.com:pub/DEC/Thomas altdorf.ai.mit.edu:archive/Thomas The Thomas system is written in Scheme and runs under MIT's CScheme, DEC's Scheme->C, and Marc Feeley's Gambit. It can run on a wide range of machines including the Macintosh, PC compatibles, Vax, MIPS, Alpha, and 680x0. Thomas generates IEEE compatible Scheme code. DEC CRL's goals in building Thomas were to learn about Dylan by building an implementation, and to build a system they could use to write small Dylan programs. As such, Thomas has no optimizations of any kind and does not perform well. The original development team consisted of: Matt Birkholz (Birkholz@crl.dec.com) Jim Miller (JMiller@crl.dec.com) Ron Weiss (RWeiss@crl.dec.com) In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley (Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial release. ---------------------------------------------------------------- [4-7] What Lisp-related discussion groups and mailing lists exist? Before posting to any discussion group, please read the rest of this FAQ, to make sure your question isn't already answered. First of all, there are several lisp-related newsgroups: comp.lang.lisp General Lisp-related discussions. See below for archive information. comp.lang.clos Discussion related to CLOS, PCL, and object-oriented programming in Lisp. Gatewayed to commonloops@cis.ohio-state.edu. (or equivalently, comp.lang.clos@cis.ohio-state.edu) See below for info on the newsgroup's archives. comp.lang.lisp.mcl Discussions related to Macintosh Common Lisp. This newsgroup is gatewayed to the info-mcl@cambridge.apple.com mailing list and archived on cambridge.apple.com. comp.lang.lisp.franz Discussion of Franz Lisp, a dialect of Lisp. (Note: *not* Franz Inc's Allegro.) comp.lang.lisp.x Discussion of XLISP, a dialect of Lisp. comp.sys.xerox Discussions related to using Medley (name exists for historical reasons, and is likely to change soon). Gatewayed to the info-1100 mailing list. comp.windows.garnet Garnet, a Lisp-based GUI. comp.lang.scheme General Scheme-related discussion. This newsgroup is gatewayed to the scheme@mc.lcs.mit.edu mailing list. comp.lang.scheme.c Discussion of C-Scheme, a scheme dialect. This newsgroup is gatewayed to the info-cscheme@zurich.ai.mit.edu mailing list. comp.ai and subgroups General AI-related dicusssion. The newsgroup comp.lang.lisp is archived on ftp.gmd.de by month, from 1989 onward. Individual files are in rnews format. (They contain articles prefixed by a header line "#! rnews archive" where is the number of characters in the article following the header. That format is convenient for various news processing programs (e.g. relaynews) and is rather easy to process from a lisp program too.) A copy of the GMD archives for comp.lang.lisp is available on cambridge.apple.com:pub/comp.lang.lisp. We list several mailing lists below. In general, to be added to a mailing list, send mail to the "-request" version of the address. This avoids flooding the mailing list with annoying and trivial administrative requests. General Lisp Mailing Lists: common-lisp@ai.sri.com Technical discussion of Common Lisp. cl-utilities@cs.cmu.edu Low volume mailing list associated with the Lisp Utilities repository at CMU. Do *NOT* post directly to this list. Send mail to CL-Utilities-Request@cs.cmu.edu instead and the moderator will either answer your question or post the message for you. lisp-faq@think.com A mailing list concerning the contents of this FAQ posting. scheme@mc.lcs.mit.edu Discussion of Scheme. Gatewayed to the comp.lang.scheme newsgroup. scheme@ai.mit.edu General discussion about Scheme. Particular Flavors of Lisp: info-mcl@cambridge.apple.com Macintosh Common Lisp. Gatewayed to the comp.lang.lisp.mcl newsgroup. cmucl-bugs@cs.cmu.edu CMU Common Lisp bug reports slug@ai.sri.com Symbolics Lisp Users Group allegro-cl@ucbvax.berkeley.edu Franz Allegro Common Lisp kcl@cli.com Kyoto Common Lisp Archived in cli.com:pub/kcl/kcl-mail-archive kcl@rascal.ics.utexas.edu Forwards to kcl@cli.com. lispworks@harlqn.co.uk LispWorks info-ti-explorer@sumex-aim.stanford.edu TI Explorer Lisp Machine bug-ti-explorer@sumex-aim.stanford.edu TI Explorer Lisp Machine info-1100@tut.cis.ohio-state.edu Xerox/Envos Lisp machine environment, InterLisp-D, and Medley. Gatewayed to the newsgroup comp.sys.xerox. info-cscheme@altdorf.ai.mit.edu, info-cscheme@zurich.ai.mit.edu C-Scheme. Gatewayed to the comp.lang.scheme.c newsgroup. t-project@cs.yale.edu T, a dialect of Scheme. info-clscheme@mc.lcs.mit.edu PseudoScheme franz-friends@berkeley.edu The Franz Lisp Language. Lisp Windowing Systems: cl-windows@ai.sri.com Common Lisp Window System Discussions. bug-clx@expo.lcs.mit.edu CLX (Common Lisp X Windows) clim@bbn.com Common Lisp Interface Manager clue-review@dsg.csc.ti.com Common Lisp User-Interface Environment express-windows@cs.cmu.edu Express Windows garnet-users@cs.cmu.edu Garnet (send mail to garnet@cs.cmu.edu or garnet-request@cs.cmu.edu to be added) gina-users@gmdzi.gmd.de GINA and CLM lispworks@harlequin.co.uk LispWorks winterp@hplnpm.hpl.hp.com WINTERP (OSF/Motif Widget INTERPreter) yyonx@csrl.aoyama.ac.jp YYonX Lisp Object-Oriented Programming: CommonLoops@cis.ohio-state.edu (same as comp.lang.clos@cis.ohio-state.edu) PCL (Xerox PARC's portable implementation of CLOS). Gatewayed to the comp.lang.clos newsgroup. The mailing list is archived on nervous.cis.ohio-state.edu in the directory pub/lispusers/commonloops. The CLOS code repository is in pub/lispusers/clos. Miscellaneous: stat-lisp-news-request@umnstat.stat.umn.edu Use of Lisp and Lisp-based systems in statistics. lisp-emacs-forum-request@ucbarpa.berkeley.edu Franz Inc's GNU-Emacs/Lisp interface. ---------------------------------------------------------------- [4-8] What are R4RS and IEEE P1178? R4RS is the Revised^4 Report on the Algorithmic Language Scheme, edited by W. Clinger and J. Rees. It appeared in ACM Lisp Pointers IV, July-September 1991, and also as MIT AI Memo 848b. It serves as a kind of standard for the language. It can be obtained by anonymous ftp at the two Scheme Repositories, altdorf.ai.mit.edu and nexus.yorku.ca. IEEE P1178 is IEEE Standard 1178-1990, "IEEE Standard for the Scheme Programming Language", published by IEEE in 1991. ISBN 1-55937-125-0. It is now also an ANSI standard. It may be ordered from IEEE by calling 1-800-678-IEEE and using order number SH14209. ---------------------------------------------------------------- [4-9] How do I do object-oriented programming in Scheme? Some Scheme implementations (for example, MacScheme, Feel, Oaklisp, and PC-Scheme) include built-in object-oriented extensions. The MEROON package is a mini-CLOS-like object package for generic R4RS Scheme (but with non-standard macros). It runs with PC-Scheme, Scheme->C and Chez Scheme. It is available in the Scheme Repository as nexus.yorku.ca:pub/scheme/new/meroon.*.tar.Z. A paper on it appears in nexus.yorku.ca:pub/txt/meroon.ps.Z. For information on YASOS (Yet Another Scheme Object System), see "Scheming with Objects" in the October 1992 issue of AI Expert magazine. ---------------------------------------------------------------- ;;; *EOF* From: mkant+@cs.cmu.edu (Mark Kantrowitz) Newsgroups: comp.lang.lisp,comp.lang.clos,news.answers Subject: FAQ: CLOS and PCL Questions 5/6 [Monthly posting] Message-ID: Date: 13 Nov 92 09:02:51 GMT Approved: news-answers-request@MIT.Edu Archive-name: lisp-faq/part5 Last-Modified: Thu Nov 5 19:30:40 1992 by Mark Kantrowitz Version: 1.27 ;;; **************************************************************** ;;; Answers to Frequently Asked Questions about Lisp *************** ;;; **************************************************************** ;;; Written by Mark Kantrowitz and Barry Margolin ;;; lisp-faq-5.text -- 11959 bytes This post contains Part 5 of the Lisp FAQ. It is cross-posted to the newsgroup comp.lang.clos because it contains material of interest to people concerned with CLOS, PCL and object-oriented programming in Lisp. The other parts of the Lisp FAQ are posted only to the newsgroups comp.lang.lisp and news.answers. If you think of questions that are appropriate for this FAQ, or would like to improve an answer, please send email to us at lisp-faq@think.com. CLOS/PCL Questions (Part 5): [5-0] What is CLOS (PCL) and where can I get it? How do you pronounce CLOS? [5-1] What documentation is available about object-oriented programming in Lisp? [5-2] How I write a function that can access defstruct slots by name? I would like to write something like (STRUCTURE-SLOT '). [5-3] How can I list all the CLOS instances in a class? [5-4] How can I store data and CLOS instances (with possibly circular references) on disk so that they may be retrieved at some later time? [5-5] Given the name of a class, how can I get the names of its slots? Search for [#] to get to question number # quickly. ---------------------------------------------------------------- [5-0] What is CLOS (PCL) and where can I get it? How do you pronounce CLOS? CLOS (Common Lisp Object System) is the object-oriented programming standard for Common Lisp. It is the successor to Symbolics FLAVORS and Xerox LOOPS (Lisp Object Oriented Programming System). The acronym CLOS is pronouned either as "See-Loss" or "Closs", depending on taste. PCL (Portable Common Loops) is a portable CLOS implementation, and is available by anonymous ftp from parcftp.xerox.com (13.1.64.94) in the /pub/pcl/ directory. Also in the same directory are sources for CLX R5 and an inspecter. The sources for the CLOS Metaobject Protocol specification are also available from parcftp as /pub/pcl/mop/spec.tar.Z. See also the book ``The Art of the Metaobject Protocol'' below. The Closette files related to this book are available from parcftp as /pub/pcl/mop/closette.lisp. ---------------------------------------------------------------- [5-1] What documentation is available about object-oriented programming in Lisp? Books about object-oriented programming in Lisp include: 1. dpANS CL describes the entire Common Lisp language, which includes the CLOS standard. Informally, CLtL2 can also be used to learn about CLOS, but please remember that CLtL2 is not an official X3J13 committee document. (The presentation of CLtL2 differs from that of the draft proposed standard, and some matters of fact have changed in the proposed standard since the publication of CLtL2.) 2. Sonya E. Keene "Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS" Addison-Wesley (Reading, MA), 1989. 266 pages. ISBN 0-201-17589-4. Tutorial introduction to CLOS with many examples and a lot of good advice for designing large programs using CLOS. 3. Jo A. Lawless and Molly M. Miller. "Understanding CLOS: the Common Lisp Object System" Digital Press, 1991. 192 pages. 4. Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow. "The Art of the Metaobject Protocol" MIT Press, 1991. 335 pages. ISBN 0-262-61074-4 The first part of the book presents a model CLOS implementation, introduces the basic principles of metaobject protocols, and works through the key elements of the CLOS Metaobject Protocol. The second half is the detailed specification of the CLOS Metaobject Protocol. A simple working interpreter suitable for experimentation is contained in an appendix. 5. Robert R. Kessler and Amy R. Petajan. "LISP, Objects, and Symbolic Programming" Scott, Foresman and Company (Glenview, IL), 1988. 644 pages. Includes a small Lisp compiler. ---------------------------------------------------------------- [5-2] How can I write a function that can access defstruct slots by name? I would like to write something like (STRUCTURE-SLOT '). There is currently no portable, built-in way to access structure slots given only the name. If your Common Lisp includes an implementation of CLOS that supports the meta-object protocol specified in the original X3J13 draft spec (document X3J13/88-003), then it probably will allow (SLOT-VALUE '); however, not all implementations of CLOS currently provide this. Lacking this, some implementations may provide implementation-dependent functions that allow access to structure slots by name; note that this may cause saved images to be larger, as some implementations normally open-code structure accessors and discard slot name information. While it is not possible to write a fully general STRUCTURE-SLOT function, it is not very difficult to write version that handles specific structure types. For instance, after defining: (defstruct spaceship name captain position velocity) one may then define: (defun spaceship-slot (spaceship slot-name) (ecase slot-name (name (spaceship-name spaceship)) (captain (spaceship-captain spaceship)) (position (spaceship-position spaceship)) (velocity (spaceship-velocity spaceship)))) or using CLOS (generic functions): (defgeneric spaceship-slot (spaceship slot-name) (:method ((x spaceship) (slot (eql :name))) (spaceship-name x)) (:method ((x spaceship) (slot (eql :captain))) (spaceship-captain x)) (:method ((x spaceship) (slot (eql :position))) (spaceship-position x)) (:method ((x spaceship) (slot (eql :velocity))) (spaceship-velocity x))) Another popular way to define this is: (defun spaceship-slot (spaceship slot-name) (funcall (symbol-function (find-symbol (format nil "SPACESHIP-~A" slot-name) #.(package-name *package*))) spaceship)) I personally recommend the first version. It is likely to be much faster and more memory efficient than the second version. It's also easy to get the second one wrong; many people forget to specify the package argument to FIND-SYMBOL, which can cause incorrect results when the package at run time is different from the one at compile time. Even my version assumes that SPACESHIP-SLOT is being defined in a file that is in the same package as the one containing the structure definition; if this isn't the case, #.(PACKAGE-NAME *PACKAGE*) should be replaced by a string naming the correct package. Another workaround is to define a MY-DEFSTRUCT macro that parses the defstruct arguments and expands into a call to DEFSTRUCT along with a definition of the runtime slot-accessor function. Some non-portable techniques include the use of LCL:STRUCTURE-REF in Lucid and EXCL:STRUCTURE-REF in Allegro. ---------------------------------------------------------------- [5-3] How can I list all the CLOS instances in a class? There is no built-in way to enumerate the instances of a class. If you are only interested in listing the instances of classes that you have defined, it is not very difficult to implement it as part of your class definition. Add a shared slot, e.g. ALL-INSTANCES, with an initial value of NIL, to the class definition. Then write an after-method on INITIALIZE-INSTANCE for this class, which pushes the instance being initialized onto ALL-INSTANCES. Note that this must be done separately for each class that wants to maintain such a list; it can't be encapsulated in a mixin class, because all its dependent classes would share the same ALL-INSTANCES slot. A compromise would be to use a mixin to define the INITIALIZE-INSTANCE after-method (and any other general-purpose methods that use the slot), but not the shared slot; it would be up to the descendant classes to define the slot at the level of the class hierarchy that is appropriate. You could also try defining the classes that need instance-recording as instances of a metaclass that holds the instance registry on the class object. The recording behavior could then be built-in to an after method on initialize-instance for the root class of the metaclass, or even allocate-instance. To allow for garbage collection of old instances, you will also need to define a generic function to remove the recorded instances from the list of instances. ---------------------------------------------------------------- [5-4] How can I store data and CLOS instances (with possibly circular references) on disk so that they may be retrieved at some later time? There are two main techniques of doing this kind of persistent object storage. The first involves using #. to compile the data into a file. The second produces an ASCII representation which, when evaluated, will reproduce an equivalent set of data. If the data you wish to save is stored in the variable *hash-table*, create a file containing just the lines (in-package "YOUR-PACKAGE") (setq *hash-table* '#.*hash-table*) and compile it. The #. macro performs read-time evaluation of the expression following the dot, and so this compiles the data into the file. You may then load the file to restore the data. However, the resulting binary file is not portable between Lisp implementations, and sometimes not even for the same Lisp on different platforms. Also, some Lisps will treat the data as constant, and place it on pages in memory that are marked read-only (after it is loaded). If one tries to later modify the data, these Lisps will signal an error. Lucid CL only puts such constants in a read-only area when they appear inside functions, so this should be safe. Allegro CL doesn't seem to complain about modification if the data is a cons. DEC's VAXLisp, however, has problems with #. circular structures in .fas files. The other technique is to produce an ASCII representation of the Lisp objects which may then be saved to a file. To reproduce the data, one can load (or compile and load) the file. This technique is portable between different Lisps and platforms. Unfortunately, the resulting data is not necessarily EQ to the original. Kerry Koitzsch's save-object.lisp package is included in the Lisp Utilities Repository, ftp.cs.cmu.edu:/afs/cs.cmu.edu/user/mkant/Public/Lisp-Utilities/. (Note: You must cd to this directory in one atomic operation, as some of the superior directories on the path are protected from access by an anonymous ftp.) The Lisp Utilities Repository is described in detail in the answer to question [6-1]. See also the discussion of MAKE-LOAD-FORM and MAKE-LOAD-FORM-SAVING-SLOTS in CLtL2. ---------------------------------------------------------------- [5-5] Given the name of a class, how can I get the names of its slots? (defun class-slot-names (class-name) (mapcar #'clos:slot-definition-name (clos:class-slots (find-class class-name)))) ---------------------------------------------------------------- ;;; *EOF* From: mkant+@cs.cmu.edu (Mark Kantrowitz) Newsgroups: comp.lang.lisp,comp.lang.scheme,news.answers Subject: FAQ: Lisp FTP Resources 6/6 [Monthly posting] Message-ID: Date: 13 Nov 92 09:03:05 GMT Approved: news-answers-request@MIT.Edu Archive-name: lisp-faq/part6 Last-Modified: Thu Nov 5 19:30:40 1992 by Mark Kantrowitz Version: 1.27 ;;; **************************************************************** ;;; FTP Archives and Other Resources ******************************* ;;; **************************************************************** ;;; Written by Mark Kantrowitz and Barry Margolin ;;; lisp-faq-6.text -- 43732 bytes This post contains Part 6 of the Lisp FAQ. If you think of questions that are appropriate for this FAQ, or would like to improve an answer, please send email to us at lisp-faq@think.com. Topics Covered (Part 6): [6-0] General information about FTP Resources for Lisp and Scheme [6-1] Repositories of Lisp Software [6-2] Repositories of Scheme Software [6-3] Publicly Redistributable Lisp Software [6-4] Publicly Redistributable Scheme Software [6-5] How can I use the X Window System or other GUIs from Lisp? [6-6] Formatting code in LaTeX Search for [#] to get to question number # quickly. ---------------------------------------------------------------- [6-0] General information about FTP Resources for Lisp and Scheme Remember, when ftping compressed or compacted files (.Z, .arc, .fit, etc.) to use binary mode for retrieving the files. FTP sites for Lisp/Scheme interpreters and compilers are discussed in the answer to questions [4-0] and [4-2]. See the entry on Macintosh Common Lisp in question [4-1] for information on the CD-ROM of Lisp code that Apple distributes with MCL 2.0. ---------------------------------------------------------------- [6-1] Repositories of Lisp Software There are several repositories of publicly redistributable and public domain Lisp code. The Lisp Utilities collection is accessible by anonymous ftp to any CMU CS machine (e.g., ftp.cs.cmu.edu [128.2.206.173]) or through AFS in the directory /afs/cs.cmu.edu/user/mkant/Public/Lisp-Utilities/ If accessing this directory through anonymous ftp, it is important to "cd" to the directory using one atomic operation, as some of the superior directories on the path are protected from access by an anonymous ftp. Files included in the repository include: extensions.lisp A collection of extensions to Common Lisp. initializations.lisp Brad Miller's initializations packaged for Allegro CL 4.0. xref.lisp Portable cross referencing tool for Lisp. Similar to the Symbolics Who-Calls and the Xerox MasterScope programs. defsystem.lisp Portable system definition facility (a "Make" for lisp). More featureful than other defsystem implementations. logical-pathnames.lisp Portable implementation of the X3J13 June 1989 specification for logical pathnames. metering.lisp Portable code time/space profiling tool. source-compare.lisp A portable "diff" utility for Lisp. user-manual.lisp Program which helps with documenting Lisp code. psgraph.lisp Joe Bates' PostScript DAG grapher. matcher.lisp A regexp-like matcher for Lisp. framework.lisp A portable generic frame system. date-formatter.lisp Simple code for formatting a date. save-object.lisp Kerry Koitzsch's package to save ASCII representations of Lisp objects to a file. defpackage.lisp Stephen Nicoud's semi-portable CLtL2 version of defpackage. johnson-yacc.lisp Mark Johnson's lisp YACC. ops5.tar.Z Public domain Common Lisp implementation of the OPS5 production system interpreter. "Expert System Shell". Written by Charles Forgy and ported by George Wood and Jim Kowalski. cmu-loop.lisp Implements the CLtL2 Loop Macro. mit-loop.lisp Implements the CLtL1 Loop Macro. sloop.lisp William Schelter's loop macro, not CLtL1/2. yloop.lisp Frank Ritter and Jim Panagos' implementation of the Yale loop macro described in McDermont, Charniak and Riesbeck's AI programming book. Not CLtL1/2. ew/ Express Windows distribution. iterate/ The Iterate Macro. series/ Waters' Series Macro package. simplex.lisp Bruno Haible's implementation of the Simplex algorithm. mapforms.tar.Z Moon's code walker. resources.lisp Brad Miller's resources package. nregex.lisp Lawrence Freil's regular expression matching code The Lisp Utilities repository is maintained by Mark Kantrowitz, cl-utilities-request@cs.cmu.edu. The CLOS code repository is available by anonymous ftp to nervous.cis.ohio-state.edu [128.146.61.200] in the directory pub/lispusers/clos/. If you've got code you'd like to add to the repository, send mail to Arun Welch, commonloops-request@cis.ohio-state.edu. The Macintosh Common Lisp repository contains Lisp code for MCL contributed by MCL users. It is available by anonymous ftp from cambridge.apple.com:pub/MACL/CONTRIB [134.149.2.3] and also contains the Info-MCL mailing list archives. The CLIM Library (a library of CLIM code) is available on cambridge.apple.com:/public/clim. For more information, contact Vincent Keunen, keunen@nrb.be. MIT AI Lab -- ftp.ai.mit.edu:pub/ loop-macro.tar [LOOP from CLtL1] series/ [SERIES from CLtL2] Iterate/ [Alternative to series and loop.] clmath.tar [Numeric math 1984] ontic/ [ONTIC Knowledge Rep. for Mathematics] xp/ [Waters' XP Lisp Pretty Printer] The LispUsers Archives, a collection of programs for Medley, can be found on nervous.cis.ohio-state.edu:pub/lispusers/medley. Also on nervous.cis.ohio-state.edu is GTT, an implementation of Chandrasekaran's Generic Tasks Toolset, in directory pub/lispusers/toolset. There's a repository of Amiga LISP implementations (and other Lisp-like language implementations) on gatekeeper.pa.dec.com:pub/micro/amiga/lisp/. Common Lisp versions of the mini programs from "Inside Computer Understanding" by Schank and Riesbeck, 1981, are available by anonymous ftp from cs.umd.edu in the directory pub/schank. Contact Bill Andersen (waander@cs.umd.edu) for more information. The directory pub/schank/icbr contains the complete code for "Inside Case-Based Reasoning" by Riesbeck and Schank, 1989. This includes code for an instructional version of CHEF by Kristian Hammond. Norvig: The software from Peter Norvig's book "Paradigms of AI Programming" is available by anonymous ftp from unix.sri.com:pub/norvig and on disk in Macintosh or DOS format from the publisher, Morgan Kaufmann. | Software includes Common Lisp implementations of: Eliza and pattern matchers, Emycin, Othello, Parsers, Scheme interpreters and compilers, Unification and a prolog interpreter and compiler, Waltz line-labelling, implementation of GPS, macsyma, and random number generators. | For more information, contact: Morgan Kaufmann, Dept. P1, 2929 Campus Drive, Suite 260 San Mateo CA 94403, (800) 745-7323; FAX: (415) 578-0672 A catalog of free and commercial natural language software is available from the Natural Language Software Registry, by anonymous ftp from tira.uchicago.edu [128.135.96.31] in the directory /registry, or by email to registry@tira.uchicago.edu. TI Explorer Lisp Code -- sumex-aim.stanford.edu:pub/exp/ The Knowledge Systems Lab's set of Explorer patches and tools. It includes in the jwz subdirectory a set of tools written and collected by Jamie Zawinski. Send questions to acuff@sumex-aim.stanford.edu. ---------------------------------------------------------------- [6-2] Repositories of Scheme Software There are several repositories of publicly redistributable and public domain Scheme code. The Scheme Repository contains a Scheme bibliography, copies of the R4RS report and other papers, sample Scheme code for a variety of purposes, several utilities, and some implementations. The Scheme code includes code for calendar calculations, Earley parser, FORMAT for Scheme, a scheme version of the Gabriel benchmarks, Marc Feeley's minimal object support for Scheme, a Scheme pretty-printer, a Prolog interpreter written in Scheme, a random number generator in Scheme, an implementation of SCOOPS, code from Abelson and Sussman's SICP book, Aubrey Jaffer's IEEE/R^3.99RS compliance test, and a LALR(1) parser. The repository is maintained by Ozan S. Yigit, scheme@nexus.yorku.ca. The repository is accessible by anonymous ftp at nexus.yorku.ca [130.63.9.66] in the directory pub/scheme/. Scheme Implementations may also be found at altdorf.ai.mit.edu:/archive/ The R4RS report is available in altdorf.ai.mit.edu:/archive/scheme-reports/ or as MIT AI Memo 848b (email publications@ai.mit.edu for more information). The altdorf archive includes SCOOPS, CL2Scheme, extend-syntax, btree, Gabriel benchmarks, FORMAT for Scheme, etc. ---------------------------------------------------------------- [6-3] Publicly Redistributable Lisp Software AI Algorithms and Tools: PAIL (Portable AI Lab) is a computing environment containing a collection of state-of-the-art AI tools, examples, and documentation. It is aimed at those involved in teaching AI courses at university level or equivalent. The system has enough built-in functionality to enable its users to get practical experience with a broad range of AI problems without having to build all the supporting tools from scratch. It is implemented in Common Lisp and uses CLOS and Allegro Common Windows (i.e., in Allegro CL 4.1). It is available by anonymous ftp from pobox.cscs.ch (148.187.10.13) in the directory /pub/ai/pail-2.1/. Written by Mike Rosner and Dean Allemang {dean,mike}@idsia.ch. AI_ATTIC is an anonymous ftp collection of classic AI programs and other information maintained by the University of Texas at Austin. It includes Parry, Adventure, Shrdlu, Doctor, Eliza, Animals, Trek, Zork, Babbler, Jive, and some AI-related programming languages. This archive currently resides on the host ftp.cc.utexas.edu (bongo.cc.utexas.edu, 128.83.186.13) in the directory /pub/AI_ATTIC. For more information, contact atticmaster@bongo.cc.utexas.edu. Benchmarks: Gabriel Lisp Benchmarks are available by anonymous ftp as ai.toronto.edu:/pub/gabriel-lisp-benchmarks.tar.Z. Lucid CL contains a set of benchmarks in its goodies/ directory, including Bob Boyer's logic programming benchmark, a benchmark to create and browse through an AI-like database of units, a CLOS speed test, a compilation speed test, TAKR (the 100 function version of TAK that tries to defeat cache memory effects), CTAK (A version of the TAKeuchi function that uses the CATCH/THROW facility), STAK (A version of the TAKeuchi function with special variables instead of parameter passing), DERIV and DDERIV (Symbolic derivative benchmarks written by Vaughn Pratt), DESTRU (a destructive operation benchmark), DIV2 (a benchmark which divides by 2 using lists of n ()'s), the FFT benchmark written by Harry Barrow, FPRINT (a benchmark to print to a file), FRPOLY (a Franz Lisp benchmark by Fateman based on polynomial arithmentic), Forest Baskett's PUZZLE benchmark (originally written in Pascal), the TPRINT benchmark to read and print to the terminal, a benchmark that creates and traverses a tree structure, and TRIANG (board game benchmark). Some of the benchmarks may work only in Lucid. Blackboard Architectures: The UMass GBB system (V1.2) is available by anonymous ftp from dime.cs.umass.edu:/gbb. The commercial GBB product is not. Work on the UMass GBB project (and funding) ended over 2 years ago. Many researchers using it have opted for the commercial release. The UMass research system remains available, but the two should not be confused as the commercial system is substantially improved and extended. The commercial system is available from Blackboard Technology Group, PO Box 44, 401 Main Street, Amherst, Massachusetts 01002, 413-256-4240. Case-based Reasoning: CL-Protos is a Common Lisp implementation of the case-based reasoning system developed by E. Ray Bareiss and Bruce W. Porter of the University of Texas/Austin AI Lab. It runs on Sun3, TI Explorer, HP 9000, and Symbolics, and gobbles a huge amount of memory. Common Lisp implementation by Rita Duran, Dan Dvorak, Jim Kroger, Hilel Swerdlin, and Ben Tso. For more information, bug reports, or comments, contact either Dan Dvorak or Ray Bareiss or Erik Eilerts Available by anonymous ftp from cs.utexas.edu:/pub/porter Databases: Postgres is an object-oriented database, and is available from postgres.berkeley.edu:/pub/postgres* It runs on DecStation 3100s, Sun3 (SunOs), Sun4 (Sparc), and Sequent Symmetry. Eliza and Similar Programs: See Peter Norvig's book (question [6-1] above). The doctor.el is an implementation of Eliza for GNU-Emacs emacs-lisp. Invoke it with "Meta-X doctor" Source code for ELIZA in Prolog (implemented by Viren Patel) is available by ftp from aisun1.ai.uga.edu. muLISP-87 (a MSDOS Lisp sold by Soft Warehouse) includes a Lisp implementation of Eliza. Compute!'s Gazette, June 1984, includes source for a BASIC implementation of Eliza. You can also find it in 101 more computer games, edited by David Ahl, published by Creative Computing (alas, they're defunct, and the book is out of print). Herbert Schildt "Artificial Intelligence using C", McGraw-Hill, 1987, ISBN 0-07-881255-0, pp315-338, includes a simple version of DOCTOR. ucsd.edu:pub/pc-ai contains implementations of Eliza for the IBM PC. The original Parry (in MLISP for a PDP-10) is available in labrea.stanford.edu:/pub/parry.tar.Z. Expert Systems: FOCL is an expert system shell and machine learning program written in Common Lisp. The machine learning program extends Quinlan's FOIL program by containing a compatible explanation-based learning component. FOCL learns Horn Clause programs from examples and (optionally) background knowledge. The expert system includes a backward-chaining rule interpreter and a graphical interface to the rule and fact base. For details on FOCL, see: Pazzani, M. and Kibler, D., "The role of prior knowledge in inductive learning", Machine Learning 9:54-97, 1992. It is available by anonymous ftp from ics.uci.edu as a (binhexed, compacted) Macintosh application, pub/SaranWrap/KR-FOCL-ES.cpt.hqx, or as Common Lisp source code (see pub/SaranWrap/README for details). If you use a copy of FOCL, or have any comments or questions, send mail to pazzani@ics.uci.edu. BABYLON is a development environment for expert systems. It includes frames, constraints, a prolog-like logic formalism, and a description language for diagnostic applications. It is implemented in Common Lisp and has been ported to a wide range of hardware platforms. Available by anonymous ftp from gmdzi.gmd.de:gmd/ai-research/Software/ (129.26.8.90) as a BinHexed stuffit archive, on the Apple CD-ROM, or with the book "The AI Workbench BABYLON", which contains *full source code* of BABYLON and the stand-alone version for the Mac. The book describes the use of BABYLON in detail. OPS5 -- See Lisp Utilities Repository in question [6-1]. Frame Languages: FrameWork is available in the Lisp Utilities Repository described above. THEO (learning frame system) is available free from CMU, after signing a license agreement. Send mail to Tom.Mitchell@cs.cmu.edu. FrameKit is available free from CMU, after signing a license agreement. Send mail to Eric.Nyberg@cs.cmu.edu KR. Send mail to Brad.Myers@cs.cmu.edu for more info. PARKA. Frames for the CM. Contact spector@cs.umd.edu. PARMENIDES (Frulekit) is available free, after signing a license agreement. Send mail to peter.shell@cs.cmu.edu FROBS is available free by anonymous ftp from cs.utah.edu:/pub/frobs.tar.Z Contact Robert Kessler for more info. PFC is a simple frame system written by Tim Finin available free by anonymous ftp from linc.cis.upenn.edu. YAK is a hybrid knowledge-representation system of the KL-ONE family. Includes an optional graphical interface depending on the Lisp. Available free after signing a license agreement. Contact Enrico Franconi . Knowledge Representation: KNOWBEL is an implementation of Telos (a sorted/temporal logic system) by Bryan M. Kramer, . It is available by anonymous ftp from ai.toronto.edu:/pub/kr/ as the files knowbel.tar.Z and manual.txt.tar.Z Runs in Allegro CL on Sparcstations and Silicon Graphics 4d and in MCL on Apple Macintoshes. SNePS is a semantic net implementation, available free after signing a license agreement. Contact shapiro@cs.buffalo.edu for more information. COLAB (COmpilation LABoratory) is a hybrid knowledge representation system emphasizing the horizontal and vertical compilation of knowledge bases. It is comprised of cooperating subsystems -- CONTAX, FORWARD, RELFUN and TAXON -- which deal with different knowledge representation and reasoning formalisms. Each subsystem can also be used as stand-alone system. CONTAX deals with constraint nets and constraint-propagation techniques. Relational knowledge in the form of Horn rules is processed by forward (FORWARD) and backward (RELFUN) chaining. Taxonomic knowledge is represented by intensional concept definitions which are automatically arranged in a subsumption hierarchy (TAXON). The COLAB software was developed at DFKI and the University of Kaiserslautern and runs in Common Lisp. (The subsystems have been tested in AKCL and Lucid CL, and possibly also Allegro CL and Symbolics CL.) All the subsystems are available free of charge for research purposes. o RELFUN is a logic-programming language with call-by-value (eager), non-deterministic, non-ground functions, and higher-order operations. It accepts freely interchangeable LISP-style and PROLOG-style syntaxes. For sources to RELFUN and copies of relevant papers, contact Dr. Harold Boley, DFKI, Postfach 2080, W-6750 Kaiserslautern, Germany, call +49-631-205-3459, fax +49-631-205-3210, or send email to boley@informatik.uni-kl.de. o TAXON is a terminological knowledge representation system extended by concrete domains. For sources to TAXON and copies of relevant papers, contact Philipp Hanschke, DFKI, Postfach 2080, W-6750 Kaiserslautern, Germany, call +49-631-205-3460, fax +49-631-205-3210, or send email to hanschke@dfki.uni-kl.de. o CONTAX is a constraint system for weighted constraints over hierarchically structured finite domains. CONTAX uses CLOS in addition to Common Lisp. For sources to CONTAX and copies of relevant papers, contact Manfred Meyer, DFKI, Postfach 2080, W-6750 Kaiserslautern, Germany, call +49-631-205-3468, fax +49-631-205-3210, or send email to meyer@dfki.uni-kl.de. o FORWARD is a logic programming language with bottom-up and top-down evaluation of Horn clauses. For sources to FORWARD and copies of relevant papers, contact Knut Hinkelmann, DFKI, Postfach 2080, W-6750 Kaiserslautern, Germany, call +49-631-205-3467, fax +49-631-205-3210, or send email to hinkelma@dfki.uni-kl.de. Languages: GLisp -- apple.com:/pub/dts/mac/lisp/glisp.tar.Z See also ftp.apple.com StarLisp Simulator -- think.com:/cm/starlisp/starsim-f19-sharfile Simulates *Lisp, one of the programming langauges used to program the Connection Machine. Runs under Symbolics, Lucid, Allegro, and Franz. InterLisp->Common-Lisp Translator -- ai.sri.com:pub/pkarp/lisp/ilisp/ Other InterLisp to Common Lisp translators may be found in the LispUsers archive listed above. The Yale Haskell system runs in CMU Common Lisp, Lucid CL, and AKCL. It is available by anonymous ftp from Chalmers animal.cs.chalmers.se 129.16.225.66 Glasgow ftp.dcs.glasgow.ac.uk 130.209.240.50 Yale nebula.cs.yale.edu 128.36.13.1 in the directory pub/haskell/yale as the files haskell-beta-2-source.tar.Z -- full sources haskell-beta-2-sparc.tar.Z -- sparc executable Machine Learning: ID3. A Lisp implementation of ID3 and other machine learning algorithms are available by anonymous ftp from the machine learning group at the University of Texas as cs.utexas.edu:pub/mooney COBWEB/3 is a concept formation system available free after signing a license agreement. Contact cobweb@ptolemy.arc.nasa.gov for more information. Mathematics: LMath -- peoplesparc.berkeley.edu:pub/mma.tar.Z [128.32.131.14] A Mathematica-style parser written in Common Lisp. Written by Richard Fateman; fateman@renoir.Berkeley.EDU. Runs in any valid Common Lisp. rascal.ics.utexas.edu:/pub/ 128.83.138.20 Maxima for Common Lisp (License required from National Energy Software Center at Argonne.) Ported by Bill Schelter. JACAL: Implicit representation and mathematics. Contact jaffer@altdorf.ai.mit.edu for more information. Medical Reasoning: TMYCIN -- sumex-aix.stanford.edu:/tmycin The TMYCIN rule based system. Object-Oriented Programming: PCL -- parcftp.xerox.com:pcl/ [13.1.64.94] Portable Common Loops (PCL) is a portable implementation of the Common Lisp Object System (CLOS). CLOS-on-KEE -- zaphod.lanl.gov:/pub/ A subset of CLOS that is implemented on top of KEE. Contact egdorf%zaphod@LANL.GOV (Skip Egdorf) for more info. MCS (Meta Class System) -- ftp.gmd.de:/pub/lisp/mcs/ [129.26.8.90] Portable object-oriented extension to Common Lisp. Integrates the functionality of CLOS (the Common Lisp Object System), and TELOS, (the object system of LeLisp Version 16 and EULISP). MCS provides a metaobject protocol which the user can specialize. MCS is claimed to be more efficient in time and space than comparable systems we know, including commercial CLOS implementations. Runs in any valid Common Lisp. Contact: Harry Bretthauer and Juergen Kopp, German National Research Center for Computer Science (GMD), Expert System Research Group, P.O. Box 1316, D-5205 Sankt Augustin 1, FRG, email: kopp@gmdzi.gmd.de Probabilistic Reasoning and Statistics: BELIEF is a Common Lisp implementation of the Dempster and Kong fusion and propagation algorithm for Graphical Belief Function Models and the Lauritzen and Spiegelhalter algorithm for Graphical Probabilistic Models. It includes code for manipulating graphical belief models such as Bayes Nets and Relevance Diagrams (a subset of Influence Diagrams) using both belief functions and probabilities as basic representations of uncertainty. It is available by anonymous ftp from ftp.stat.washington.edu (128.95.17.34), and by email from the author, Russell Almond . Contact the author at almond@statsci.com for information about a commercial version GRAPHICAL-BELIEF currently in the prototype stages. XSTAT is a statistics package which runs in XLISP. It has recently been ported to Common Lisp, and is available as umnstat.stat.umn.edu:/pub/xlispstat/CL/CLS1.0A1.tar.Z The CL port does not yet include the lisp-stat dynamic graphics package, only the numerics. The XLisp version is available from the above site and several mirror sites, such as mac.archive.umich.edu. Planning: NONLIN -- cs.umd.edu:/pub/nonlin (128.8.128.8) Common Lisp implementation of the NONLIN planning system originally designed and implemented by Austin Tate. Bugs can be reported to nonlin-bugs@cs.umd.edu. User's group is nonlin-users@cs.umd.edu. The authors request that anybody ftping the code send a message to nonlin-users-request@cs.umd.edu, letting them know you have a copy and also letting them know if you wish to subscribe to the users group. More information can also be obtained from Jim Hendler, hendler@cs.umd.edu. A Common Lisp implementation of ABTWEAK, a hierarchical nonlinear planner extending David Chapman's (MIT) TWEAK, may be obtained by anonymous ftp from csis.dit.csiro.au in the directory pub/steve. A user's manual, a copy of the associated masters thesis by Steve Woods, and an extended Journal paper are also contained in that directory. Send mail to Steven.Woods@csis.dit.csiro.au for more information. RHETORICAL is a planning and knowledge tool available by anonymous ftp from cs.rochester.edu:/pub/knowledge-tools in the files rhet-19-40.tar.Z and cl-lib-3-11.tar.Z. The files tempos-3-6.tar.Z and timelogic-5-0.tar.Z add James Allen's interval logic to Rhet. It runs on Symbolics Genera and Allegro Common Lisp. Written by Brad Miller . PRODIGY is an integrated planning and learning system, available free after signing a license agreement. Contact prodigy@cs.cmu.edu for more information. SOAR is an integrated intelligent agent architecture currently being developed at Carnegie Mellon University, the University of Michigan, and the Information Sciences Institute of the University of Southern California. SOAR, and its companion systems, CParaOPS5 and TAQL, have been placed in the public domain. The system may be retrieved by anonymous ftp to ftp.cs.cmu.edu (or any other CMU CS machine) in the directory /afs/cs.cmu.edu/project/soar/5.2/2/public/. [Note: You must cd to this directory in one atomic operation, as superior directories may be protected during an anonymous ftp.] For more information, send email to soar-request@cs.cmu.edu or write to The Soar Group, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213. Finally, though the software is in the public domain, the manual remains under copyright. To obtain one (at no charge) send a request (including your physical mail address) to soar-doc@cs.cmu.edu or to the physical address above. SNLP is a domain independent systematic nonlinear planner, available by anonymous ftp from cs.washington.edu:/pub/snlp.tar.Z Contact weld@cs.washington.edu for more information. TILEWORLD is a planning testbed/simulator developed at SRI International by Martha Pollack, Michael Frank and Marc Ringuette. TILEWORLD originally ran under Lucid CL, but was later extended and ported to Allegro CL by Badr H. Al-Badr and Steve Hanks. The new tileworld is available by anonymous ftp from cs.washington.edu as the file new-tileworld.tar.Z It includes an X interface. Contact pollack@cs.pitt.edu for more information. TRUCKWORLD is a simulated world intended to provide a testbed for AI planning programs, where the planning agent is a truck that roams around the simulated world. It is available by anonymous ftp from cs.washington.edu in the file simulator.tar.Z. It includes an X interface. Contact Steve Hanks for more information. IDM is a Common Lisp implementation of both a classical and extended version of the STRIPS planner. It is available by anonymous ftp from sauquoit.gsfc.nasa.gov (128.183.101.29). Questions, comments and bug reports may be sent to idm-users@chelmsford.gsfc.nasa.gov. Qualitative Reasoning: QSIM is a qualitative reasoning system implemented in Common Lisp. It is available by anonymous ftp from cs.utexas.edu:/pub/qsim Contact Ben Kuipers for more information. Theorem Proving: MVL (Multi-Valued Logic) is a theorem proving system written in Common Lisp, and is available from t.stanford.edu:/mvl/mvl.tar.Z A user's manual may be found in /mvl/manual.tex. Send mail to ginsberg@t.stanford.edu. Boyer-Moore cli.com:pub/nqthm/nqthm.tar.Z Contact: kaufman@cli.com rascal.ics.utexas.edu:/pub/ 128.83.138.20 nqthm/ Boyer and Moore's theorem prover. Also available from cli.com:/pub/nqthm. proof-checker/ Matt Kaufmann's proof checking enhancements to nqthm. The mailing list nqthm-users-request@cli.com is for users of the Boyer-Moore theorem-prover, NQTHM. Virtual Reality: VEOS (Virtual Environment Operating Shell) is an extendible environment for prototyping distributed applications for Unix. The programmer's interface uses XLISP 2.1. Although intended for distributed Virtual Reality applications at The Human Interface Technology Lab in Seattle, it should be appropriate for other applications. VEOS uses heavyweight sequential processes, corresponding roughly to unix processes. VEOS runs on DEC/5000, Sun4, and Silicon Graphics VGX and Indigo. VEOS is available by anonymous ftp from milton.u.washington.edu (128.95.136.1) in the directory ~ftp/public/veos as veos.tar.Z. If you use the software, the authors ask that you send them mail to veos-support@hitl.washington.edu. Vision: OBVIUS -- whitechapel.media.mit.edu:/obvius/ [18.85.0.125] Object-Based Vision and Image Understanding System (OBVIUS), is a Common Lisp image processing package. Provides a library of image processing routines (e.g., convolutions, fourier transforms, statistical computations, etc.) on gray or binary images and image-sequences (no color support yet), an X windows display interface, postscript printer output, etc. It uses a homebrew interface to X11 (i.e., it does not use clx or clue). However, they eventually hope to port Obvius to a clx/clue platform. Written by David Heeger and Eero Simoncelli . Runs in Lucid-4.0. Includes LaTeX documentation and User's Guide. Miscellaneous: ftp.csrl.aoyama.ac.jp: YY/ YY window toolkit sources Lisp/ several common lisp sources, including MIT's FRL. RRL (Rewrite Rule Laboratory) -- herky.cs.uiowa.edu:public/rrl [128.255.28.100] PLisp - A Common Lisp front end to Postscript. This translates many Common Lisp functions to postscript as well as manage the environment and many lispisms (&optional and &rest arguments, multiple values, macros, ...). Available via anonymous ftp in pub/plisp/plisp.tar.Z on nebula.cs.yale.edu (128.36.13.1). Written by John Peterson, peterson-john@cs.yale.edu. RegExp is an extension to Allegro Common Lisp which adds regular expression string matching, using the foreign function interface. Available by anonymous ftp from ai.sri.com:/pub/pkarp/regexp/. Contact pkarp@ai.sri.com for more information. ---------------------------------------------------------------- [6-4] Publicly Redistributable Scheme Software SLIB is a portable scheme library that provides compatibility and utility functions for many of the standard scheme implementations, including ELK 1.5, GAMBIT, MITScheme, scheme->C, Scheme48, T3.1 and Scm4a. It is available by anonymous ftp from altdorf.ai.mit.edu:archive/scm/slib1b10.tar.Z nexus.yorku.ca:pub/scheme/new/slib1b10.tar.Z TEST.SCM is an IEEE and R4RS conformance test suite. It is available from altdorf.ai.mit.edu:archive/scm/test.scm and nexus.yorku.ca:pub/scheme/new/test.scm PSD (Portable Scheme Debugger) is available by anonymous ftp from Tampere University of Technology, Finland, cs.tut.fi:/pub/src/languages/schemes/psd.tar.Z With PSD, you can run a Scheme program in an Emacs buffer, set breakpoints, single step evaluation and access and modify the program's variables. It works by instrumenting the original source code, so it should run with any R4RS compliant Scheme. It has been tested with SCM and Elk 1.5, but should work with other Schemes with a minimal amount of porting, if at all. Includes documentation and user's manual. Written by Pertti Kellom\"aki, pk@cs.tut.fi A bibliography of work in functional programming can be obtained by anonymous ftp from tamdhu.dcs.st-andrews.ac.uk:/pub/staple/pubs.txt (138.251.192.40). It uses a refer-like format with %T for title, %A for authors %I for a unique index entry %S for source (possibly a reference to another index) %K for keywords and %C for comments. Compiled by Tony Davie, . Scheme Utilities -- brokaw.lcs.mit.edu:/pub/scmutils.tar 18.30.0.33 [This collection seems to no longer be located on brokaw -- does anybody know the current location?] A collection of Scheme implementations of data structures and algorithms is available by anonymous ftp from cs.tut.fi in the directory /pub/src/languages/schemes/as the file scheme-algorithms.tar. For more information, contact Pertti Kellom\"aki . ---------------------------------------------------------------- [6-5] How can I use the X Window System or other GUIs from Lisp? There are several GUI's and Lisp interfaces to the X Window System. Mailing lists for these systems are listed in the answer to question [4-7]. Various vendors also offer their own interface-building packages. CLX provides basic Common Lisp/X functionality. It is a de facto standard low-level interface to X, providing equivalent functionality to XLib, but in Lisp. It is also a good source for comparing the foreign function calls in various Lisps. Does *not* depend on CLOS. Available free as part of the X release in the contrib directory. Also available form export.lcs.mit.edu:/contrib as the files CLX.Manual.tar.Z, CLX.R4.5.tar.Z and CLX.R5.tar.Z Primary Interface Author: Robert W. Scheifler Send bug reports to bug-clx@expo.lcs.mit.edu. CLIM (Common Lisp Interface Manager) is a GUI originally developed by Symbolics and International Lisp Associates, and now under joint development by several Lisp vendors, including Symbolics, Apple, Franz, Harlequin and Lucid. It is intended to be a portable analogue of Symbolics UIMS (Dynamic Windows, Presentations Types). It runs on Symbolics Lisp Machines; Allegro and Lucid on several Unix platforms; Symbolics CLOE on 386/486 IBM PCs running Windows; and MCL on Apple Macintoshes. It is *not* free, and with the exception of Macintoshes, if it is available it can be purchased from the vendor of the Lisp system you are using. For the Macintosh version write to the ILA: International Lisp Associates, 114 Mt. Auburn St., Cambridge, MA 02138, 617-576-1151 Contact: Dennis Doughty - Doughty@ILA.com International Lisp Associates, 898 Windmill Park Road, Mountain View, CA 94043, 1-800-477-CLIM Contact: Bill York - York@ILA.com The CLIM 2.0 SPECIFICATION is available by anonymous ftp from ftp.uunet.net:vendor/franz/clim.ps.Z. CLUE (Common Lisp User-Interface Environment) is from TI, and extends CLX to provide a simple, object-oriented toolkit (like Xt) library that uses CLOS. Provides basic window classes, some stream I/O facilities, and a few other utilities. Still pretty low level (it's a toolkit, not widget library). Available free by anonymous ftp from csc.ti.com:pub/clue.tar.Z Written by Kerry Kimbrough. Send bug reports to clue-bugs@dsg.csc.ti.com. CLIO (Common Lisp Interactive Objects) is a GUI from the people who created CLUE. It provides a set of CLOS classes that represent the standard components of an object-oriented user interface -- such as text, menus, buttons, scroller, and dialogs. It is included as part of the CLUE distribution, along with some packages that use it, both sample and real. Allegro Common Windows provides a front end to CLX. Uses CLOS. It is *not* free. Contact info@franz.com for more information. The LispWorks Toolkit is an extensible CLOS-based widget set that uses CLX and CLUE. The LispWorks programming environment has been written using the toolkit and includes: an Emacs-like editor, listener, debugger, profiler, and operating system shell; browsers/graphers for classes, generic functions, processes, windows, files, compilation errors, source code systems, and setting LispWorks parameters; and an interactive interface builder and complete online hypertext documentation. Contact: lispworks-request@harlqn.co.uk CLM (Common Lisp Motif) and GINA (Generic Interactive Application) and IB (Interface Builder). CLM runs Motif widgets in a separate C process, with minimal work on the Lisp side and communicates between C and Lisp using TCP sockets. Runs in Allegro CL, Sun CL, and Symbolics Genera. GINA uses CLOS. Available free in the X contrib directory or by anonymous ftp from either export.lcs.mit.edu:/contrib or ftp.gmd.de:/gmd/gina [129.26.8.90] as the files CLM+GINA.README, CLM2.2.tar.Z and GINA2.2.tar.Z. CLM was written by Andreas Baecker , GINA by Mike Spenke , and IB by Thomas Berlage . Contact Mike Spenke for more info. To be added to the mailing list, send a message to gina-users-request@gmdzi.gmd.de. EW (Express Windows) is intended to mimic Symbolics' Dynamic Windows user and programmer interfaces. It is available free in the ew/ subdirectory of the Lisp Utilities repository. It is no longer under active development. Runs on Sun/Lucid, Franz Allegro, and Symbolics. Should port easily to other Lisps with CLX. Written by Andrew L. Ressler . Garnet is a large and flexible GUI. Lots of high-level features. Does *not* depend on CLOS, but does depend on CLX. Garnet (version 2.0 and after) is now in the public domain, and has no licensing restrictions, so it is available to all foreign sites and for commercial uses. Detailed instructions for obtaining it by anonymous ftp are available by anonymous ftp from a.gp.cs.cmu.edu [128.2.242.7] as the file /usr/garnet/garnet/README. Garnet includes the Lapidiary interactive design tool, C32 constraint editor, spreadsheet object, Gilt Interface Builder, automatic display management, two widget sets (Motif look-and-feel and Garnet look-and-feel), support for gesture recognition, and automatic constraint maintenance, application data layout and PostScript generation. Runs in virtually any Common Lisp environment, including Allegro, Lucid, CMU, and Harlequin Common Lisps on Sun, DEC, HP, Apollo, IBM 6000, and many other machines. Garnet helps implement highly-interactive, graphical, direct manipulation programs for X/11 in Common Lisp. Typical applications include: drawing programs similar to Macintosh MacDraw, user interfaces for expert systems and other AI applications, box and arrow diagram editors, graphical programming languages, game user interfaces, simulation and process monitoring programs, user interface construction tools, CAD/CAM programs, etc. Contact Brad Myers (bam@a.gp.cs.cmu.edu) for more information. Bug reports and administrative questions: garnet@cs.cmu.edu. Garnet is discussed on the newsgroup comp.windows.garnet. LispView is a GUI written at Sun that does not use CLX. Instead it converts Xlib.h directly into Lucid foreign function calls. It is intended to be fast and tight. Uses CLOS. Available for anonymous ftp from export.lcs.mit.edu:contrib/lispview1.1 and xview.ucdavis.edu:pub/XView/LispView1.1 Includes a general-purpose 2D grapher library. Written by Hans Muller (hmuller@sun.com). Runs in Sun CL and Lucid CL. Direct questions about the source provision to lispview@Eng.Sun.Com. WINTERP (Widget INTERPreter) was developed at HP and uses the Xtoolkit and Motif widget set. It is based on David Betz's XLISP interpreter, which is a small subset of Common Lisp that runs on IBM PCs. Runs on DecStation 3100, HP9000s, Sun3, Sparcs. It is a free-standing Lisp-based tool for setting up window applications. Available free in X contrib directory, or by anonymous ftp from export.lcs.mit.edu:contrib/winterp-???.tar.Z where ??? is the version number. If you do not have Internet access you may request the source code to be mailed to you by sending a message to winterp-source%hplnpm@hplabs.hp.com or hplabs!hplnpm!winterp-source. Contact Niels Mayer mayer@hplabs.hp.com for more information. ftp.csrl.aoyama.ac.jp:YY/ YY window toolkit sources YYonX is a port of the YY system to X windows. Runs in Lucid CL, Allegro CL, and Symbolics Genera. Supports kanjii. Developed at Aoyama Gakuin University. Available free by anonymous ftp from ftp.csrl.aoyama.ac.jp:YY/ Written by Masayuki Ida Picasso is a CLOS based GUI, and is available from postgres.berkeley.edu:/pub/Picasso-2.0 It runs on DecStation 3100s, Sun3 (SunOs), Sun4 (Sparc), and Sequent Symmetry in Allegro CL. The file pub/xcl.tar.Z contains X-Common Lisp interface routines. Send mail to picasso@postgres.berkeley.edu for more information. XIT (X User Interface Toolkit) is an object-oriented user interface toolkit for the X Window System based on Common Lisp, CLOS, CLX, and CLUE. It has been developed by the Research Group DRUID at the Department of Computer Science of the University of Stuttgart as a framework for Common Lisp/CLOS applications with graphical user interfaces for the X Window System. The work is based on the USIT system developed by the Research Group INFORM at the University of Stuttgart. Although the system kernel is quite stable, XIT is still under active development. XIT can be obtained free by anonymous ftp from ifi.informatik.uni-stuttgart.de (129.69.211.1) in the directory /pub/xit/. ---------------------------------------------------------------- [6-6] Formatting code in LaTeX SLaTeX is a R4RS-compliant Scheme program that allows you to write program code "as is" in your LaTeX or TeX source. It is particularly geared to the programming languages Scheme and Common Lisp, and has been tested in Chez Scheme, Common Lisp, MIT C Scheme, Elk, Scheme->C, SCM and UMB Scheme on Unix; and MIT C Scheme and SCM on MSDOS. The formatting of the code includes assigning appropriate fonts to the various tokens in the code (keywords, variables, constants, data), at the same time retaining the proper indentation when going to the non-monospace (non-typewriter) provided by TeX. SLaTeX comes with two databases that recognize the standard keywords/variables/constants of Scheme and Common Lisp respectively. These can be modified by the user using easy TeX commands. In addition, the user can inform SLaTeX to typeset arbitrary identifiers as specially suited TeX expressions (i.e., beyond just fonting them). The code-typesetting program SLaTeX is available by anonymous ftp from cs.rice.edu as the file public/slatex.tar.Z. Send bug reports to dorai@cs.rice.edu. ----------------------------------------------------------------