This is quick-n-dirty conversion of the old comp.lang.lisp FAQ into Markup syntax. (Last updated: 2006-01-30T16:59:33+8:00)
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):
Postings should be of general interest to the Lisp community. See also question [4-9]. Postings asking for solutions to homework problems are inappropriate.
The comp.lang.lisp newsgroup is archived in ftp.cs.cmu.edu:/user/ai/pubs/news/comp.lang.lisp/ on a weekly basis.
Every so often, somebody posts an inflammatory message, such as
These "religious" issues serve no real purpose other than to waste bandwidth. If you feel the urge to respond to such a post, please do so through a private e-mail message.
Questions about object oriented programming in Lisp should be directed to the newsgroup comp.lang.clos. Similarly, questions about the programming language Scheme should be directed to the newsgroup comp.lang.scheme. Discussion of functional programming language issues should be directed to the newsgroup comp.lang.functional. Discussion of AI programs implemented in Lisp should sometimes be cross-posted to the newsgroup comp.ai.
Scheme is a dialect of Lisp that stresses conceptual elegance and simplicity. It is specified in R4RS and IEEE standard P1178. (See the Scheme FAQ for details on standards for Scheme.) Scheme is much smaller than Common Lisp; the specification is about 50 pages, compared to Common Lisp's 1300 page draft standard. (See question [4-10] for details on standards for Common Lisp.) Advocates of Scheme often find it amusing that the Scheme standard is shorter than the index to CLtL2.
Scheme is often used in computer science curricula and programming language research, due to its ability to represent many programming abstractions with its simple primitives. Common Lisp is often used for real world programming because of its large library of utility functions, a standard object-oriented programming facility (CLOS), and a sophisticated condition handling system.
See the Scheme FAQ for information about object-oriented programming in Scheme.
In Common Lisp, a simple program would look something like the following:
(defun fact (n)
(if (< n 2)
1
(* n (fact (1- n)))))
In Scheme, the equivalent program would like like this:
(define fact
(lambda (n)
(if (< n 2)
1
(* n (fact (- n 1))))))
Experienced Lisp programmers might write this program as follows in order to allow it to run in constant space:
(defun fact (n)
(labels ((tail-recursive-fact (counter accumulator)
(if (> counter n)
accumulator
(tail-recursive-fact (1+ counter)
(* counter accumulator)))))
(tail-recursive-fact 1 1)))
Whereas in Scheme the same computation could be written as follows:
(define fact
(lambda (n)
(letrec ((tail-recursive-fact
(lambda (counter accumulator)
(if (> counter n)
accumulator
(tail-recursive-fact (+ counter 1)
(* counter accumulator))))))
(tail-recursive-fact 1 1))))
or perhaps (using IEEE named LETs):
(define fact
(lambda (n)
(let loop ((counter n)
(accumulator 1))
(if (< counter 2)
accumulator
(loop (- counter 1)
(* accumulator counter))))))
Some Schemes allow one to use the syntax (define (fact n) ...)
instead of (define fact (lambda (n) ...)).
There are several good Lisp introductions and tutorials:
Perhaps the best tutorial introduction to the language. It has clear and correct explanations, and covers some fairly advanced topics. The book is an updated Common Lisp version of the 1984 edition published by Harper and Row Publishers.
Three free Lisp educational tools which were used in the book — Evaltrace, DTRACE and SDRAW — are available by anonymous ftp from
b.gp.cs.cmu.edu:/usr/dst/public/lisp/
b.gp.cs.cmu.edu:/usr/dst/public/evaltrace/
Evaltrace is a graphical notation for explaining how evaluation works and is described in "Visualizing Evaluation in Applicative Languages" by David S. Touretzky and Peter Lee, CACM 45-59, October 1992. DTRACE is a "detailed trace" which provides more information than the tracing tools provided with most Common Lisp implementations. SDRAW is a read-eval-draw loop that evaluates Lisp expressions and draws the result as a cons cell diagram (for both X11 and ascii terminals). Also available is PPMX, a tool for pretty printing macro expansions.
3. Wade L. Hennessey. "Common Lisp" McGraw-Hill, New York, 1989. 395 pages. ISBN 0-07-028177-7, $26.95. Fairly good, but jumps back and forth from the simple to the complex rather quickly, with no clear progression in difficulty.
4. Laurent Siklossy. "Let's Talk LISP" Prentice-Hall, NJ, 1976. 237 pages, ISBN 0-13-53276-2-8. Good introduction, but quite out of date.
5. Stuart C. Shapiro. "Common Lisp: An Interactive Approach" Computer Science Press/W.H. Freeman, New York, 1992. 358 pages, ISBN 0-7167-8218-9. The errata for the book may be obtained by anonymous ftp from ftp.cs.buffalo.edu:/users/shapiro/clerrata.ps
Other introductions to Lisp include:
More advanced introductions to Lisp and its use in Artificial Intelligence include:
1. Peter Norvig. "Paradigms of AI Programming: Case Studies in Common Lisp" Morgan Kaufmann, 1992. 946 pages. ISBN 1-55860-191-0 ($49.95).
Provides an in-depth exposition of advanced AI programming techniques
and includes large-scale detailed examples. The book is the most
advanced AI/Common-Lisp programming text and reference currently
available, and hence is not for the complete novice. It focuses on the
programming techniques necessary for building large AI systems,
including object-oriented programming, and has a strong performance
orientation.
The text is marked by its use of "non-toy" examples to illustrate the
techniques. All of the examples are written in Common Lisp, and copies
of the source code are available by anonymous ftp from
unix.sri.com:/pub/norvig and on disk in Macintosh or DOS format from
the publisher. Some of the techniques described include rule-based
pattern matching (GPS, Eliza, a subset of Macsyma, the Emycin expert
system shell), constraint propagation and backtracking (Waltz
line-labelling), alpha-beta search (Othello), natural language
processing (top-down, bottom-up and chart parsing), logic-programming
(unification and Prolog), interpreters and compilers for Scheme, and
object-oriented programming (CLOS).
The examples are also used to illustrate good programming style and
efficiency. There is a guide to trouble-shooting and debugging Lisp
programs, a style guide, and a discussion of portability problems.
Some of the efficiency techniques described include memoization,
data indexing, compilation, delaying computation, proper use of
declarations, avoiding garbage collection, and choosing and using the
correct data structure.
The book also serves as an advanced introduction to Common Lisp, with
sections on the Loop macro, CLOS and sequences, and some coverage of
error handling, series, and the package facility.
2. Eugene Charniak, Christopher K. Riesbeck, Drew V. McDermott and James R. Meehan. "Artificial Intelligence Programming", 2nd edition. Lawrence Erlbaum Associates (Hillsdale, NJ), 1987. 533 pages, ISBN 0-89-85960-9-2, $29.95.
Provides many nice code fragments, all of which are written
in Common Lisp. The first half of the book covers topics
like macros, the reader, data structures, control structures,
and defstructs. The second half of the book describes
programming techniques specific to AI, such as
discrimination nets, production systems, deductive database
retrieval, logic programming, and truth maintenance.
3. Patrick H. Winston and Berthold K. P. Horn. "LISP", 3rd edition. Addison-Wesley (Reading, MA), 1989. 611 pages. ISBN 0-201-08319-1 Covers the basic concepts of the language, but also gives a lot of detail about programming AI topics such as rule-based expert systems, forward chaining, interpreting transition trees, compiling transition trees, object oriented programming, and finding patterns in images. Not a tutorial. Has many good examples. Source code for the examples is available by anonymous ftp from ftp.ai.mit.edu:/pub/lisp3/. (The code runs in Lucid, Allegro, KCL, GCLisp, MCL, Symbolics Genera. Send mail with subject line "help" to ai3@ai.mit.edu for more information.)
4. John R. Anderson, Albert T. Corbett, and Brian J. Reiser. "Essential LISP" Addison-Wesley (Reading, MA), 1987. 352 pages, ISBN 0-20-11114-8-9, $23.95. Concentrates on how to use Lisp with iteration and recursion.
5. Robert D. Cameron and Anthony H. Dixon "Symbolic Computing with Lisp" Prentice-Hall, 1992, 326 pages. ISBN 0-13-877846-9. The book is intended primarily as a third-year computer science text. In terms of programming techniques, it emphasizes recursion and induction, data abstraction, grammar-based definition of Lisp data structures and functional programming style. It uses two Lisp languages: (1) a purely functional subset of Lisp called Small Lisp and (2) Common Lisp. An MS-DOS interpreter for Small Lisp (including source) is provided with the book. It considers applications of Lisp to formal symbolic data domains: algebraic expressions, logical formulas, grammars and programming languages.
6. Tony Hasemer and John Domingue. "Common Lisp Programming for Artificial Intelligence" Addison-Wesley, Reading, MA, 1989. 444 pages, ISBN 0-20-11757-9-7.
This book presents an introduction to Artificial Intelligence
with an emphasis on the role of knowledge representation. Three
chapters focus on object-oriented programming, including the
construction and use of a subset of CLOS.
The authors' research into the problems faced by novice Lisp
users influenced the content and style of the book. (The authors
are members of the Human Cognition Research Laboratory at the
Open University in the United Kingdom.) The book employs a
tutorial approach, especially in areas that students often find
difficult, such as recursion. Early and progressive treatment of
the evaluator promotes understanding of program execution.
Hands-on exercises are used to reinforce basic concepts.
The book assumes no prior knowledge of Lisp or AI and is a
suitable textbook for students in Cognitive Science, Computer
Science and other disciplines taking courses in Lisp or AI
programming as well as being invaluable for professional
programmers who are learning Lisp for developing AI applications.
7. Steven Tanimoto "The Elements of Artificial Intelligence Using Common Lisp", 2nd edition Computer Science Press, New York, 1995. 562 pages, ISBN 0-71-67826-9-3, (ISBN 0-71-67823-0-8, 1990, $48).
8. Patrick R. Harrison "Common Lisp and Artificial Intelligence" Prentice Hall, Englewood Clifs, NJ, 1990. 244 pages, ISBN 0-13-1552430, $22.50.
9. Paul Graham "On Lisp: Advanced Techniques for Common Lisp" Prentice Hall, Englewood Clifs, NJ, 1994. 413 pages, ISBN 0-13-030552-9. Emphasizes a bottom-up style of writing programs, which he claims is natural in Lisp and has advantages over the traditional way of writing programs in C and Pascal. Also has in-depth sections on writing macros with several nice examples. Source code is available by anonymous ftp from ftp.das.harvard.edu:/pub/onlisp/ as a single 56kb file.
10. John A. Moyne "Lisp: A first language for computing" Van Nostrand Reinhold, New York, 1991. 278 pages, ISBN 0442004265.
General Lisp reference books include:
1. ANSI/X3J13 Programming Language Common Lisp (ANSI/X3.226-1994) American National Standards Institute 11 West 42nd Street, New York, NY 10036. http://www.ansi.org/
2. Kent M. Pitman Common Lisp HyperSpec (TM) Harlequin, Inc., 1996. This is an HTML-only document available via the web. Available for browsing from http://www.harlequin.com/books/HyperSpec/FrontMatter/ Available free for download (subject to some legal restrictions) from http://www.harlequin.com/books/HyperSpec/ Includes text from ANSI/X3.226-1994 and other design rationales.
3. Guy L. Steele "Common Lisp: The Language" [CLtL1] Digital Press, 1984. 465 pages. ISBN 0-932376-41-X.
4. Guy L. Steele "Common Lisp: The Language, 2nd Edition" [CLtL2] Digital Press, 1990. 1029 pages, ISBN 1-55558-041-6 paperbound ($39.95).
[Butterworth-Heinemann, the owners of Digital Press, have made
the LaTeX sources to this book available by anonymous FTP from
cambridge.apple.com:/pub/CLTL/
A copy of the distribution is also available from
ftp.cs.cmu.edu:/user/ai/lang/lisp/doc/cltl/
The paperbound version of the book is, of course, available at
fine bookstores, or contact them directly at Digital Press,
225 Wildwood Street, Woburn, MA 01801, call 800-366-2665
(617-928-2527), or fax 800-446-6520 (617-933-6333). A copy of
the Digital Press book catalog is available from the same FTP location.]
A html version, produced using latex2html on the latex sources,
is accessible via the URL:
http://www.cs.cmu.edu/Web/Groups/AI/html/cltl/cltl2.html
5. Franz Inc. "Common Lisp: The Reference" Addison-Wesley, Reading, MA 1988. ISBN 0-201-11458-5 Entries on Lisp (CLtL1) functions in alphabetical order.
6. Rosemary Simpson "Common Lisp, the Index" Franz Inc., Berkeley, CA, 1987. 71 pages, $4.95. A cross-referenced index to Steele's book, 1st edition.
Lisp periodicals include:
1. LISP Pointers. Published by ACM SIGPLAN six times a year. Volume 1, Number 1 was April-May 1987. Subscriptions: ACM Members $12; ACM Student Members $7; Non-ACM members $25. Mail checks payable to the ACM to ACM Inc., PO Box 12115, Church Street Station, New York, NY 10249.
2. LISP and Symbolic Computation, Kluwer Academic Press. Volume 1 was published in 1989. (Robert Kessler <kessler@cons.cs.utah.edu> and Carolyn Talcott <clt@sail.stanford.edu> are the editors). ISSN 0892-4635. Subscriptions: Institutions $169; Individuals $80. Add $8 for air mail. Kluwer Academic Publishers, PO Box 322, 3300 AH Dordrecht, The Netherlands, or Kluwer Academic Publishers, PO Box 358, Accord Station, Hingham, MA 02018-0358.
A full table of contents of all published issues, aims and scope, and
instructions for authors are available by anonymous ftp from
ftp.std.com:/Kluwer/journals/
as the files lisp.toc and lisp.inf.
3. Proceedings of the biannual ACM Lisp and Functional Programming Conference. (First one was in 1980.)
4. Proceedings of the annual Lisp Users and Vendors Conference.
Implementation-specific questions:
1. Lucid. See the wizards.doc file that comes with the Lucid release. It describes functions, macros, variables and constants that are not official parts of the product and are not supported. Constructs described in this file include: the interrupt facility, the source file recording facility, the resource facility, multitasking, writing your own streams, lisp pipes, i/o buffers, the compiler, floating-point functions, memory management, debugger information, the window tool kit, extensions to the editor, the foreign function interface, clos information, delivery toolkit information, and Lucid lisp training classes. The wizards.doc file also covers i/o constructs, functions for dealing with DEFSTRUCT, functions and constants for dealing with procedure objects, functions and constants for dealing with code objects, function for mapping objects, additional keyword argument to DISKSAVE, function used in the implementation of arrays, function for monitor-specific behavior for a process, additional keyword argument to RUN-PROGRAM, and load-time evaluation.
Many books on Scheme are worth reading even if you use Common Lisp, because many of the issues are similar. Scheme is a simpler language to learn, so it is often used in introductory computer science classes. See the Scheme FAQ for a list of introductions and references for Scheme. The two key introductions are Abelson and Sussman's "Structure and Interpretation of Computer Programs" and Friedman and Felleisen's "The Little LISPer".
Special Topics:
Garbage Collection:
Wilson, Paul R., "Uniprocessor Garbage Collection Techniques"
Proceedings of the 1992 International Workshop on Memory Management.
Springer Lecture Notes #637. Surveys garbage collection techniques.
Includes an excellent bibliography. Available by anonymous ftp from
cs.utexas.edu:/pub/garbage/gcsurvey.ps.
The BibTeX format of the bibliography is also available in this
directory, along with several other papers. Contact wilson@cs.utexas.edu
for more info.
There are several books about Lisp programming style, including:
1. Molly M. Miller and Eric Benson "Lisp Style and Design" Digital Press, 1990. 214 pages, ISBN 1-55558-044-0, $26.95. How to write large Lisp programs and improve Lisp programming style. Uses the development of Lucid CL as an example.
2. Robin Jones, Clive Maynard, and Ian Stewart. "The Art of Lisp Programming" Springer-Verlag, 1989. 169 pages, ISBN 0-387-19568-8 ($33).
3. W. Richard Stark. "LISP, Lore, and Logic: An Algebraic View of LISP Programming, Foundations, and Applications" Springer-Verlag, 1990. 278 pages. ISBN 0-387-97072-X paper ($42). Self-modifying code, self-reproducing programs, etc.
4. CMU CL User's Manual, Chapter 7, (talks about writing efficient code). It is available by anonymous ftp from any CMU CS machine (e.g., ftp.cs.cmu.edu [128.2.206.173]) as the file /afs/cs.cmu.edu/project/clisp/docs/cmu-user/cmu-user.ps [when getting this file by anonymous ftp, one must cd to the directory in one atomic operation, as some of the superior directories on the path are protected from access by anonymous ftp.]
5. See also Norvig's book, SICP (Abelson & Sussman), SAP (Springer and Friedman).
6. Hallvard Tretteberg's Lisp Style Guide is available by anonymous ftp in ftp.think.com:/public/think/lisp/style-guide.text. There is a fair bit of overlap between Hallvard's style guide and the notes below and in part 3 of this FAQ.
7. Rajeev Sangal "Programming Paradigms in Lisp" McGraw-Hill, 1991. ISBN 0-07-054666-5.
8. Rodney A. Brooks. "Programming in Common Lisp" John Wiley & Sons, New York, 1985. 303 pages. ISBN 0-471-81888-7. Chapter 5 discusses Lisp programming style.
Here are some general suggestions/notes about improving Lisp programming style, readability, correctness and efficiency:
General Programming Style Rules:
GOOD:
(defun foo (x y)
(let ((z (+ x y 10)))
(* z z)))
BAD:
(defun foo(x y)(let((z(+ x y 10)))(* z z)))
(defun foo ( x y )
(let ( ( z (+ x y 10) ) )
( * z z )
)
)
Although the Lisp reader and compiler don't care which you
use, most experienced Lisp programmers find the first example
much easier to read than the last two.
The following functions often abused or misunderstood by novices. Think twice before using any of these functions.
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.
To improve the readability of your code,
(IF (FOO X)
(PROGN (PRINT "hi there") 23)
34)
should be written using COND instead.
Lisp Idioms:
Documentation:
Issues related to macros:
(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.
(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.
File Modularization:
Stylistic preferences:
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:
(apply #'append list-of-lists)
may look like a call with only two arguments, it becomes a function call to APPEND, with the LIST-OF-LISTS spread into actual arguments. As a result it will have as many arguments as there are elements in LIST-OF-LISTS, and hence may run into problems with the CALL-ARGUMENTS-LIMIT. Use REDUCE or MAPCAN instead:
(reduce #'append list-of-lists :from-end t)
(mapcan #'copy-list list-of-lists)
The second will often be more efficient (see note below about choosing the right algorithm). Beware of calls like (apply f (mapcar ..)).
(eval-when (compile load eval)
(defconstant RED 1)
(defconstant GREEN 2)
(defconstant BLUE 3))
(case color
(#.RED ...)
(#.GREEN ...)
(#.BLUE ...)
...)
(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.
(proclaim '(optimize (safety 0) (speed 3) (space 1)))
since this yields a global effect. Instead, add the optimizations
as local declarations to small pieces of well-tested,
performance-critical code:
(defun well-tested-function ()
(declare (optimize (safety 0) (speed 3) (space 1)))
..)
Such optimizations can remove run-time type-checking; type-checking
is necessary unless you've very carefully checked your code
and added all the appropriate type declarations.
- Some programmers feel that you shouldn't add declarations to
code until it is fully debugged, because incorrect
declarations can be an annoying source of errors. They recommend
using CHECK-TYPE liberally instead while you are developing the code.
On the other hand, if you add declarations to tell the
compiler what you think your code is doing, the compiler can
then tell you when your assumptions are incorrect.
Declarations also make it easier for another programmer to read
your code.
- Declaring the type of variables to be FIXNUM does not
necessarily mean that the results of arithmetic involving the
fixnums will be a fixnum; it could be a BIGNUM. For example,
(declare (type fixnum x y))
(setq z (+ (* x x) (* y y)))
could result in z being a BIGNUM. If you know the limits of your
numbers, use a declaration like
(declare (type (integer 0 100) x y))
instead, since most compilers can then do the appropriate type
inference, leading to much faster code.
- Don't change the compiler optimization with an OPTIMIZE
proclamation or declaration until the code is fully debugged
and profiled. When first writing code you should say
(declare (optimize (safety 3))) regardless of the speed setting.
- Depending on the optimization level of the compiler, type
declarations are interpreted either as (1) a guarantee from
you that the variable is always bound to values of that type,
or (2) a desire that the compiler check that the variable is
always bound to values of that type. Use CHECK-TYPE if (2) is
your intention.
- If you get warnings about unused variables, add IGNORE
declarations if appropriate or fix the problem. Letting such
warnings stand is a sloppy coding practice.
To produce efficient code,
- choose the right algorithm. For example, consider seven possible
implementations of COPY-LIST:
(defun copy-list (list)
(let ((result nil))
(dolist (item list result)
(setf result (append result (list item))))))
(defun copy-list (list)
(let ((result nil))
(dolist (item list (nreverse result))
(push item result))))
(defun copy-list (list)
(mapcar #'identity list))
(defun copy-list (list)
(let ((result (make-list (length list))))
(do ((original list (cdr original))
(new result (cdr new)))
((null original) result)
(setf (car new) (car original)))))
(defun copy-list (list)
(when list
(let* ((result (list (car list)))
(tail-ptr result))
(dolist (item (cdr list) result)
(setf (cdr tail-ptr) (list item))
(setf tail-ptr (cdr tail-ptr))))))
(defun copy-list (list)
(loop for item in list collect item))
(defun copy-list (list)
(if (consp list)
(cons (car list)
(copy-list (cdr list)))
list))
The first uses APPEND to tack the elements onto the end of the list.
Since APPEND must traverse the entire partial list at each step, this
yields a quadratic running time for the algorithm. The second
implementation improves on this by iterating down the list twice; once
to build up the list in reverse order, and the second time to reverse
it. The efficiency of the third depends on the Lisp implementation,
but it is usually similar to the second, as is the fourth. The fifth
algorithm, however, iterates down the list only once. It avoids the
extra work by keeping a pointer (reference) to the last cons of the
list and RPLACDing onto the end of that. Use of the fifth algorithm
may yield a speedup. Note that this contradicts the earlier dictum to
avoid destructive functions. To make more efficient code one might
selectively introduce destructive operations in critical sections of
code. Nevertheless, the fifth implementation may be less efficient in
Lisps with cdr-coding, since it is more expensive to RPLACD cdr-coded
lists. Depending on the implementation of nreverse, however,
the fifth and second implementations may be doing the same
amount of work. The sixth example uses the Loop macro, which usually
expands into code similar to the third. The seventh example copies
dotted lists, and runs in linear time, but isn't tail-recursive.
There is a long-running discussion of whether pushing items
onto a list and then applying NREVERSE to the result is faster or
slower than the alternatives. According to Richard C. Waters (Lisp
Pointers VI(4):27-34, October-December 1993), the NREVERSE strategy is
slightly faster in most Lisp implementations. But the speed difference
either way isn't much, so he argues that one should pursue the option
that yields the clearest and simplest code, namely using NREVERSE.
Here's code for a possible implementation of NREVERSE. As is
evident, most of the alternatives to using NREVERSE involve
essentially the same code, just reorganized.
(defun nreverse (list)
;; REVERSED is the partially reversed list,
;; CURRENT is the current cons cell, which will be reused, and
;; REMAINING are the cons cells which have not yet been reversed.
(do* ((reversed nil)
(current list remaining)
(remaining (cdr current) (cdr current)))
((null current)
reversed)
;; Reuse the cons cell at the head of the list:
;; reversed := ((car remaining) . reversed)
(setf (cdr current) reversed)
(setf reversed current)))
- use type declarations liberally in time-critical code, but
only if you are a seasoned Lisp programmer. Appropriate type
declarations help the compiler generate more specific and
optimized code. It also lets the reader know what assumptions
were made. For example, if you only use fixnum arithmetic,
adding declarations can lead to a significant speedup. If you
are a novice Lisp programmer, you should use type declarations
sparingly, as there may be no checking to see if the
declarations are correct, and optimized code can be harder to
debug. Wrong declarations can lead to errors in otherwise
correct code, and can limit the reuse of code in other
contexts. Depending on the Lisp compiler, it may also
be necessary to declare the type of results using THE, since
some compilers don't deduce the result type from the inputs.
- check the code produced by the compiler by using the
disassemble function
Books about Lisp implementation include:
1. John Allen "Anatomy of Lisp" McGraw-Hill, 1978. 446 pages. ISBN 0-07-001115-X Discusses some of the fundamental issues involved in the implemention of Lisp.
2. Samuel Kamin "Programming Languages, An Interpreter-Based Approach" Addison-Wesley, Reading, Mass., 1990. ISBN 0-201-06824-9 Includes sources to several interpreters for Lisp-like languages. The source for the interpreters in the book is available by anonymous FTP from a.cs.uiuc.edu:/pub/kamin/kamin.distr/ Tim Budd reimplemented the interpreters in C++, and has made them available by anonymous ftp from cs.orst.edu:/pub/budd/kamin/
3. Sharam Hekmatpour "Lisp: A Portable Implementation" Prentice Hall, 1985. ISBN 0-13-537490-X. Describes a portable implementation of a small dynamic Lisp interpreter (including C source code).
4. Peter Henderson "Functional Programming: Application and Implementation" Prentice-Hall (Englewood Cliffs, NJ), 1980. 355 pages.
5. Peter M. Kogge "The Architecture of Symbolic Computers" McGraw-Hill, 1991. ISBN 0-07-035596-7. Includes sections on memory management, the SECD and Warren Abstract Machines, and overviews of the various Lisp Machine architectures.
6. Daniel P. Friedman, Mitchell Wand, and Christopher T. Haynes "Essentials of Programming Languages" MIT Press, 1992, 536 pages. ISBN 0-262-06145-7. Teaches fundamental concepts of programming language design by using small interpreters as examples. Covers most of the features of Scheme. Includes a discussion of parameter passing techniques, object oriented languages, and techniques for transforming interpreters to allow their implementation in terms of any low-level language. Also discusses scanners, parsers, and the derivation of a compiler and virtual machine from an interpreter. Includes a few chapters on converting code into a continuation passing style. Source files available by anonymous ftp from cs.indiana.edu:/pub/eopl/ [129.79.254.191].
7. Peter Lee, editor, "Topics in Advanced Language Implementation", The MIT Press, Cambridge, Mass., 1991. Articles relevant to the implementation of functional programming languages.
8. Also see the proceedings of the biannual ACM Lisp and Functional Programming conferences, the implementation notes for CMU Common Lisp, Norvig's book, and SICP (Abelson & Sussman).
9. Christian Queinnec "Les Langages Lisp" InterEditions (in French), 1994. 500 pages. ISBN 2-7296-0549-5, 61-2448-1. (?) Cambridge University Press (in English), 1996. ISBN 0-521-56247-3.
The book covers Lisp, Scheme and other related dialects,
their interpretation, semantics and compilation.
All of the programs described in the book are available by
anonymous ftp from
ftp.inria.fr:/INRIA/Projects/icsla/Books/LiSP94Sep05.tar.gz
For more information, see the book's URL
file://ftp.inria.fr/INRIA/Projects/icsla/WWW/LiSP.html
or contact the author at Christian.Queinnec@inria.fr
Many Lisp functions can be defined in terms of other Lisp functions. For example, CAAR can be defined in terms of CAR as (defun caar (list) (car (car list))) It is then natural to ask whether there is a "minimal" or smallest set of primitives necessary to implement the language.
There is no single "best" minimal set of primitives; it all depends on the implementation. For example, even something as basic as numbers need not be primitive, and can be represented as lists. One possible set of primitives might include CAR, CDR, and CONS for manipulation of S-expressions, READ and PRINT for the input/output of S-expressions and APPLY and EVAL for the guts of an interpreter. But then you might want to add LAMBDA for functions, EQ for equality, COND for conditionals, SET for assignment, and DEFUN for definitions. QUOTE might come in handy as well. If you add more specialized datatypes, such as integers, floats, arrays, characters, and structures, you'll need to add primitives to construct and access each.
AWKLisp is a Lisp interpreter written in awk, available by anonymous ftp from ftp.cs.cmu.edu:/user/ai/lang/lisp/impl/awk/. It has thirteen built-in functions: CAR, CDR, CONS, EQ, ATOM, SET, EVAL, ERROR, QUOTE, COND, AND, OR, LIST.
A more practical notion of a "minimal" set of primitives might be to look at the implementation of Scheme. While many Scheme functions can be derived from others, the language is much smaller than Common Lisp. See Dybvig's PhD thesis, R. Kent Dybvig, "Three Implementation Models for Scheme", Department of Computer Science Technical Report #87-011, University of North Carolina at Chapel Hill, Chapel Hill, North Carolina, April 1987. for a justification of a particularly practical minimal set of primitives for Scheme.
In a language like Common Lisp, however, there are a lot of low-level primitive functions that cannot be written in terms of the others, such as GET-UNIVERSAL-TIME, READ-CHAR, WRITE-CHAR, OPEN, and CLOSE, for starters. Moreover, real Common Lisp implementations are often built upon primitives that aren't part of the language, per se, and certainly not intended to be user-accessible, such as SYS:%POINTER-REF.
Beside the references listed in [1-4], some other relevant references include:
McCarthy, John, "Recursive Functions of Symbolic Expressions and
their Computation by Machine, Part I", CACM 3(4):185-195, April 1960.
[Defines five elementary functions on s-expressions.]
McCarthy, John, "A Micro-Manual for Lisp — not the whole Truth",
ACM SIGPLAN Notices, 13(8):215-216, August 1978.
[Defines the Lisp programming language in 10 rules and gives
a small interpreter (eval) written in this Lisp.]
McCarthy, John, et al., "LISP 1.5 Programmer's Manual", 2nd edition,
MIT Press, 1965, ISBN 0-262-13011-4 (paperback).
[Gives five basic functions, CAR, CDR, CONS, EQ, and ATOM.
Using composition, conditional expressions (COND), and
recursion, LAMBDA, and QUOTE, these basic functions may be used
to construct the entire class of computable functions of
S-expressions. Gives the functions EVAL and APPLY in
M-expression syntax.]
Abelson and Sussman's SICP, especially chapters 4 and 5 on the
implementation of meta-circular and explicit-control evaluators.
Steele and Gabriel's "The Evolution of LISP".
Glossary of acronyms: CAR Originally meant "Contents of Address portion of Register", which is what CAR actually did on the IBM 704. CDR Originally meant "Contents of Decrement portion of Register", which is what CDR actually did on the IBM 704. Pronounced "Cudder" /kUdd@r/ (as in "a cow chews its cdr"). The first syllable is pronounced like "could". LISP Originally from "LISt Processing" GUI Graphical User Interface CLOS Common Lisp Object System. The object oriented programming standard for Common Lisp. Based on Symbolics FLAVORS and Xerox LOOPS, among others. Pronounced either as "See-Loss" or "Closs". See also PCL. PCL Portable Common Loops. A portable CLOS implementation. Available by anonymous ftp from parcftp.xerox.com:pcl/. LOOPS Lisp Object Oriented Programming System. A predecessor to CLOS on Xerox Lisp machines. X3J13 Subcommittee of the ANSI committee X3 which is working on the ANSI Standardization of Common Lisp. ANSI American National Standards Institute dpANS draft proposed American National Standard (what an ANS is called while it's in the public review stage of standardization). CL Common Lisp SC22/WG16 The full name is ISO/IEC JTC 1/SC 22/WG 16. It stands for International Organization for Standardization/ International Electrotechnical Commission, Joint Technical Committee 1 Subcommittee 22 (full name "Information Technology — Programming Languages and their Environments"), Working Group 16. This long-winded name is the ISO working group working on an international Lisp standard, (i.e., the ISO analogue to X3J13). CLtL1 First edition of Guy Steele's book, "Common Lisp the Language". CLtL2 Second edition of Guy Steele's book, "Common Lisp the Language".
The LISP-JOBS mailing list exists to help programmers find Lisp programming positions, and to help companies with Lisp programming positions find capable Lisp programmers. (Lisp here means Lisp-like languages, including Scheme.)
Material appropriate for the list includes Lisp job announcements and should be sent to ai+lisp-jobs@cs.cmu.edu. Resumes should NOT be sent to the list.
[Note: The 'ai+' part of the mailing list name is used for directing submissions to the appropriate mail-server. The list is NOT restricted to AI-related Lisp jobs — all Lisp job announcements are welcome.]
As a matter of policy, the contents of this mailing list is considered confidential and will not be disclosed to anybody.
To subscribe, send a message to ai+query@cs.cmu.edu with subscribe lisp-jobs <First Name> <Last Name>, <Affiliation/Organization> in the message body.
(If your mailer objects to the "+", send subscription requests to "ai+query"@cs.cmu.edu, job announcements to "ai+lisp-jobs"@cs.cmu.edu, etc.)
For help on using the query server, send mail to ai+query@cs.cmu.edu with help in the message body.
Job postings sent to the list are automatically archived in ftp.cs.cmu.edu:/user/ai/jobs/lisp/
If you have any other questions, please send them to ai+@cs.cmu.edu
ILISP is a powerful GNU-Emacs interface to many dialects of Lisp, including Lucid, Allegro, {A}KCL, IBCL, and CMU. Written by Chris McConnell <ccm+@cs.cmu.edu> and now maintained by Marco Antoniotti <marcoxa@cs.nyu.edu> and Rick Busdiecker <rfb@lehman.com>. It is available by anonymous ftp from h.gp.cs.cmu.edu:/usr/rfb/ilisp/ [128.2.254.156] as the file ilisp-5.6.tar.gz. It is also available in the CMU AI Repository in ftp.cs.cmu.edu:/user/ai/lang/lisp/util/emacs/ilisp/ If you want to be on the ilisp mailing list, to hear about new releases and patches, send mail to ilisp-request@lehman.com. Please send any comments, code, or bug reports to ilisp@lehman.com.
Franz Inc.'s GNU-Emacs/Lisp interface includes an online Common Lisp manual. (The manual is available by license from Franz Inc. Contact info@franz.com for more information.) The Emacs-Lisp interface (without the online Common Lisp reference manual and some Allegro-specific code) is available free from ftp.franz.com:/pub/emacs/eli-2.0.11.tar.gz and takes advantage of GNU-Emacs 19.X's newest features, including support for mouse input, pulldown menus, and multifont text. The interface also supports Epoch 3.2 and 4.2, and LEmacs 19.6 and 19.8. For discussion of the Franz lisp-emacs interface, join the allegro-cl-request@cs.berkeley.edu mailing list. (See also [1-2] for a hardcopy version of the Common Lisp reference manual.)
The cl-shell package provides a major mode (cl-shell-mode) for running Common Lisp (CL) as an Emacs subprocess. It provides a general mechanism for communication between CL and Emacs which does not rely on extra processes, and should therefore be easily portable to any version of CL. Features include direct (i.e., not through a temp file) evaluation and in-package compilation of forms from lisp-mode buffers, type-ahead and a history mechanism for the cl-shell buffer, and pop-up help facilities for the CL functions documentation, macroexpand and describe. Extensions for Lucid Common Lisp provide pop-up arglists and source file editing. Other extensions are provided to allow editing source files of CLOS or Flavors methods. Cl-shell is available on the Lucid tape (in the goodies directory) or via anonymous ftp from whitechapel.media.mit.edu (18.85.0.125).
Lucid includes some other Emacs-Lisp interfaces in its goodies directory.
Harlequin's LispWorks includes an Emacs-Lisp interface.
Venue's Medley has an optional EMACS Interface.
GNU-Emacs itself is available by anonymous ftp from prep.ai.mit.edu.
Edebug, a debugger for Emacs Lisp, and some utilities for Common Lisp debugging (Dave Gillespie's version of cl.el) are available by anonymous ftp from a.cs.uiuc.edu:/pub/edebug/ To join the Edebug mailing list edebug@cs.uiuc.edu send mail to edebug-request@cs.uiuc.edu. For more information, write to Daniel LaLiberte <liberte@cs.uiuc.edu>.
Both association lists (alists) and hash tables may be used to represent tabular data. Hash tables have an O(1) running time and alists an O(n) running time, so hash tables are ultimately more efficient than alists. However, if the alists are small, they can be more efficient than hash tables, which have a large initial overhead.
Alists can sometimes be more efficient if the keys are sorted according to frequency, with the most heavily accessed keys appearing at the front of the list. But one doesn't always know this kind of information, and even then the frequency distribution may be flat.
In Allegro CL 4.1 [SPARC; R1], the rule of thumb is that for less than 24 elements, linear search using alists beats hashing. In Lucid CL 4.0.1 HP 9000/700, the break-even point is at 10 elements. The break-even points vary in other lisps from as low as 4 elements to as high as 100 elements. So if you're using alists in your code, using hash tables instead may speed up your program.
A potential problem may occur, however, when the keys of an EQ or EQL hash table are Lisp objects such as conses or arrays (or other objects that are identified by their addresses). In most implementations, such tables must be re-hashed after garbage collection. If your application causes frequent GCs, this can adversely affect the performance of hash table lookup. Since EQL-hashing and =-hashing of fixnums generally don't require rehashing after GC, one way of avoiding this problem is to include a unique identifier in each key object and hash on that instead. Another solution is to use an EQUAL hash table if the keys are conses or an EQUALP hash table if the keys are arrays or other (non-circular!) structures.
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.
This is a tough question to answer, as you probably expected. In many cases, it appears to be. Lisp does not require the programmer to specify the data type of variables, so generic arithmetic operators may have to perform type checking at runtime in order to determine how to proceed. However, Lisp code can also be denser (i.e. there is more expressed in a single line) than many other languages: the Lisp expression (+ A B) is more powerful than the C expression A+B (the Lisp version supports bignums, rationals, and complex numbers, while the C version only supports limited-size integers and floating point); therefore, one may claim that it is reasonable that the Lisp version take longer than the C version (but don't expect everyone to accept this rationalization). Solutions to this include hardware support (e.g. processors that support type tags in data, such as SPARC and Symbolics Lisp Machines), declarations, and specialized variants of functions (e.g. in MacLisp, + accepts and returns only fixnums, +$ accepts and returns only flonums, and PLUS is generic).
At one time, the MIT PDP-10 MacLisp compiler was compared to DEC's PDP-10 Fortran compiler. When appropriate declarations were supplied in the Lisp code, the performance of compiled Lisp arithmetic rivaled that of the Fortran code. It would hardly be fair to compare Lisp without declarations to Fortran, since the Fortran compiler would have more information upon which it could base its optimizations. A more recent test found that numeric code compiled with optimizations using CMU CL is within the same ballpark as highly optimized Fortran code. For unoptimized Fortran code, CMU CL was about 4 times faster. Even the speed of numeric code generated by other Lisp compilers (AKCL, Allegro, Lucid) was well within an order of magnitude of good Fortran and C compilers (although slower than CMU CL). Inspection of the emitted C code from AKCL doesn't reveal many obvious sources of inefficiency. (Since AKCL compiles Lisp into C, there are many cases where KCL code is as fast as hand-written C code.)
See the paper peoplesparc.berkeley.edu:/pub/papers/fastlisp.ps.Z for a discussion of the speed of Lisp vis a vis Fortran or C.
Since Lisp is a good language for rapid prototyping, it is easy for a mediocre programmer (or even a good programmer, who isn't being careful) to generate a large amount of inefficient Lisp code. A good example is the use of APPEND to link successive lists together, instead of keeping a pointer to the tail of the list. Often a programmer can obtain significant speed increases by using a time/space profiler to identify the functions which waste time (often small functions which are called frequently) and rewriting those functions.
#' 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.
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.
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).
Use (funcall (find-symbol "SYMBOL-NAME" :pkg-name) ...).
CDR-coding is a space-saving way to store lists in memory. It is normally only used in Lisp implementations that run on processors that are specialized for Lisp, as it is difficult to implement efficiently in software. In normal list structure, each element of the list is represented as a CONS cell, which is basically two pointers (the CAR and CDR); the CAR points to the element of the list, while the CDR points to the next CONS cell in the list or NIL. CDR-coding takes advantage of the fact that most CDR cells point to another CONS, and further that the entire list is often allocated at once (e.g. by a call to LIST). Instead of using two pointers to implement each CONS cell, the CAR cell contains a pointer and a two-bit "CDR code". The CDR code may contain one of three values: CDR-NORMAL, CDR-NEXT, and CDR-NIL. If the code is CDR-NORMAL, this cell is the first half of an ordinary CONS cell pair, and the next cell in memory contains the CDR pointer as described above. If the CDR code is CDR-NEXT, the next cell in memory contains the next CAR cell; in other words, the CDR pointer is implicitly thisaddress+1, where thisaddress is the memory address of the CAR cell. If the CDR code is CDR-NIL, then this cell is the last element of the list; the CDR pointer is implicitly a reference to the object NIL. When a list is constructed incrementally using CONS, a chain of ordinary pairs is created; however, when a list is constructed in one step using LIST or MAKE-LIST, a block of memory can be allocated for all the CAR cells, and their CDR codes all set to CDR-NEXT (except the last, which is CDR-NIL), and the list will only take half as much storage (because all the CDR pointers are implicit).
If this were all there were to it, it would not be difficult to implement in software on ordinary processors; it would add a small amount of overhead to the CDR function, but the reduction in paging might make up for it. The problem arises when a program uses RPLACD on a CONS cell that has a CDR code of CDR-NEXT or CDR-NIL. Normally RPLACD simply stores into the CDR cell of a CONS, but in this case there is no CDR cell — its contents are implicitly specified by the CDR code, and the word that would normally contain the CDR pointer contains the next CONS cell (in the CDR-NEXT case) to which other data structures may have pointers, or the first word of some other object (in the CDR-NIL case). When CDR-coding is used, the implementation must also provide automatic "forwarding pointers"; an ordinary CONS cell is allocated, the CAR of the original cell is copied into its CAR, the value being RPLACD'ed is stored into its CDR, and the old CAR cell is replaced with a forwarding pointer to the new CONS cell. Whenever CAR or CDR is performed on a CONS, it must check whether the location contains a forwarding pointer. This overhead on both CAR and CDR, coupled with the overhead on CDR to check for CDR codes, is generally enough that using CDR codes on conventional hardware is infeasible.
There is some evidence that CDR-coding doesn't really save very much memory, because most lists aren't constructed at once, or RPLACD is done on them enough that they don't stay contiguous. At best this technique can save 50% of the space occupied by CONS cells. However, the savings probably depends to some extent upon the amount of support the implementation provides for creating CDR-coded lists. For instance, many system functions on Symbolics Lisp Machines that operate on lists have a :LOCALIZE option; when :LOCALIZE T is specified, the list is first modified and then copied to a new, CDR-coded block, with all the old cells replaced with forwarding pointers. The next time the garbage collector runs, all the forwarding pointers will be spliced out. Thus, at a cost of a temporary increase in memory usage, overall memory usage is generally reduced because more lists may be CDR-coded. There may also be some benefit in improved paging performance due to increased locality as well (putting a list into CDR-coded form makes all the "cells" contiguous). Nevertheless, modern Lisps tend to use lists much less frequently, with a much heavier reliance upon code, strings, and vectors (structures).
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.
There is no standard for dumping a Lisp image. Here are the commands from some lisp implementations: Lucid: DISKSAVE Symbolics: Save World [CP command] CMU CL: SAVE-LISP Franz Allegro: EXCL:DUMPLISP (documented) SAVE-IMAGE (undocumented) Medley: IL:SYSOUT or IL:MAKESYS MCL: SAVE-APPLICATION <pathname> &key :toplevel-function :creator :excise-compiler :size :resources :init-file :clear-clos-caches KCL: (si:save-system "saved_kcl") LispWorks: LW:SAVE-IMAGE Be sure to garbage collect before dumping the image. You may need to experiment with the kind of garbage collection for large images, and may find better results if you build the image in stages.
There is no standard for running a Unix shell command from Lisp, especially since not all Lisps run on top of Unix. Here are the commands from some Lisp implementations: Allegro: EXCL:RUN-SHELL-COMMAND (command &key input output error-output wait if-input-does-not-exist if-output-exists if-error-output-exists) Lucid: RUN-PROGRAM (name &key input output error-output (wait t) arguments (if-input-does-not-exist :error) (if-output-exists :error) (if-error-output-exists :error)) KCL: SYSTEM For example, (system "ls -l"). You can also try RUN-PROCESS and EXCLP, but they don't work with all versions of KCL. CMU CL: RUN-PROGRAM (program args &key (env *environment-list*) (wait t) pty input if-input-does-not-exist output (if-output-exists :error) (error :output) (if-error-exists :error) status-hook before-execve) LispWorks: FOREIGN:CALL-SYSTEM-SHOWING-OUTPUT
To toggle source file recording and cross-reference annotations, use Allegro: excl:*record-source-file-info* excl:*load-source-file-info* excl:*record-xref-info* excl:*load-xref-info* LispWorks: (toggle-source-debugging nil)
Memory management: CMU CL: (bytes-consed-between-gcs) [this is setfable] Lucid: (change-memory-management &key growth-limit expand expand-reserved) Allegro: *tenured-bytes-limit* LispWorks: LW:GET-GC-PARAMETERS (use LW:SET-GC-PARAMETERS to change them)
Environment Variable Access: Allegro: (sys:getenv var) (sys:setenv var value) or (setf (sys:getenv var) value) Lucid: (environment-variable var) (set-environment-variable var value) CMU CL 17: (cdr (assoc (intern var :keyword) *environment-list*)) {A}KCL, GCL: (system:getenv var) CLISP: (system::getenv var)
Exiting/Quitting: CLISP: EXIT Allegro: EXIT (&optional excl::code &rest excl::args &key excl::no-unwind excl::quiet) LispWorks: BYE (&optional (arg 0)) Lucid: QUIT (&optional (lucid::status 0)) CMU CL: QUIT (&optional recklessly-p)
The Symbolics Zetalisp character set includes the following
characters not present in other Lisps (^ means control):
^] >= greater than or equal to
^< <= less than or equal to
^z != not equal to
^^ == equivalent to
^e not
^g pi
^l +/- plus/minus
^h lambda
^f epsilon
^w <--> left/right arrow
^x <-- left arrow
^y --> right arrow
^a down arrow
^k up arrow
^d up caret
^_ down caret
^t forall
^u there exists
^b alpha
^c beta
^i gamma
^j delta
^o partial delta
^n infinity
^m circle +
^v circle x
other special characters to look out for are the font-change characters,
which are represented as a ^f followed by a digit or asterisk. a digit
means to push font #n onto the stack; an asterisk means to pop the most
recent font from the stack. you can clean up the code by replacing "\^f."
with "". in format statements, ^p and ^q are used to delimit text to
be printed in a particular character style.
*** history: where did lisp come from?
john mccarthy developed the basics behind lisp during the 1956 dartmouth
summer research project on artificial intelligence. he intended it as an
algebraic list processing (hence the name) language for artificial
intelligence work. early implementations included the ibm 704, the ibm
7090, the dec pdp-1, the dec pdp-6 and the dec pdp-10. the pdp-6 and
pdp-10 had 18-bit addresses and 36-bit words, allowing a cons cell to
be stored in one word, with single instructions to extract the car and
cdr parts. the early pdp machines had a small address space, which
limited the size of lisp programs.
milestones in the development of lisp:
1956 dartmouth summer research project on ai.
1960-65 lisp1.5 is the primary dialect of lisp.
1964- development of bbnlisp at bbn.
late 60s lisp1.5 diverges into two main dialects:
interlisp (originally bbnlisp) and maclisp.
early 70s development of special-purpose computers known as lisp
machines, designed specificly to run lisp programs.
xerox d-series lisp machines run interlisp-d.
early mit lisp machines run lisp machine lisp
(an extension of maclisp).
1969 anthony hearn and martin griss define standard lisp to
port reduce, a symbolic algebra system, to a variety
of architectures.
late 70s macsyma group at mit developed nil (new implementation
of lisp), a lisp for the vax.
stanford and lawrence livermore national laboratory
develop s-1 lisp for the mark iia supercomputer.
franz lisp (dialect of maclisp) runs on stock-hardware
unix machines.
gerald j. sussman and guy l. steele developed scheme,
a simple dialect of lisp with lexical scoping and
lexical closures, continuations as first-class objects,
and a simplified syntax (i.e., only one binding per symbol).
advent of object-oriented programming concepts in lisp.
flavors was developed at mit for the lisp machine,
and loops (lisp object oriented programming system) was
developed at xerox.
early 80s development of spice-lisp at cmu, a dialect of maclisp
designed to run on the scientific personal integrated
computing environment (spice) workstation.
1980 first biannual acm lisp and functional programming conf.
1981 psl (portable standard lisp) runs on a variety of platforms.
1981+ lisp machines from xerox, lmi (lisp machines inc)
and symbolics available commercially.
april 1981 grass roots definition of common lisp as a description
of the common aspects of the family of languages (lisp
machine lisp, maclisp, nil, s-1 lisp, spice lisp, scheme).
1984 publication of cltl1. common lisp becomes a de facto
standard.
1986 x3j13 forms to produce a draft for an ansi common lisp
standard.
1987 lisp pointers commences publication.
1990 steele publishes cltl2 which offers a snapshot of
work in progress by x3j13. (unlike cltl1, cltl2
was not an output of the standards process and was
not intended to become a de facto standard. read
the second edition preface for further explanation
of this important issue.) includes clos,
conditions, pretty printing and iteration facilities.
1992 x3j13 creates a draft proposed american national
standard for common lisp. this document is the
first official successor to cltl1.
[note: this summary is based primarily upon the history section of the
draft ansi specification. more detail and references can be obtained from
that document. see [4-12] for information on obtaining a copy.]
gabriel and steele's "the evolution of lisp", which appeared in the
1993 acm history of programming languages conference, is available by
anonymous ftp from
ftp.cs.umbc.edu:/pub/memoization/misc/ [130.85.100.53]
as evolution-of-lisp.ps.z.
brad miller maintains a lisp history web page at
http://www.cs.rochester.edu/u/miller/lisp-history.html
*** how do i find the argument list of a function? how do i get the function name from a function object?
there is no standard way to find the argument list of a function,
since implementations are not required to save this information.
however, many implementations do remember argument information, and
usually have a function that returns the lambda list. here are the
commands from some lisp implementations:
lucid: arglist
allegro: excl::arglist
symbolics: arglist
lispworks: lw:function-lambda-list
cmu common lisp, new compiler:
#+(and :cmu :new-compiler)
(defun arglist (name)
(let* ((function (symbol-function name))
(stype (system:%primitive get-vector-subtype function)))
(when (eql stype system:%function-entry-subtype)
(cadr (system:%primitive header-ref function
system:%function-entry-type-slot)))))
the draft ansi standard does include function-lambda-expression and
function-keywords, which can be used to create an arglist function.
if you're interested in the number of required arguments you could use
(defun required-arguments (name)
(or (position-if #'(lambda (x) (member x lambda-list-keywords))
(arglist name))
(length (arglist name))))
to extract the function name from the function object, as in
(function-name #'car) ==> 'car
use the following vendor-dependent functions:
symbolics: (si::compiled-function-name
As a result, there is the potential of portability clashes between systems that use the same macro characters. This question lists the non-standard macro character usage of major Lisp systems, in an effort to avoid such conflicts.
There is a proposal in the ANSI draft to have COMPILE-FILE and LOAD bind *READTABLE*, which would allow one to locally redefine syntax through private readtables. Unfortunately, this doesn't help with the Infix Package, where one wants to globally extend syntax.
There is no portable way in Common Lisp of determining whether a file is a directory or not. Calling DIRECTORY on the pathname will not always work, since the directory could be empty. For UNIX systems (defun DIRECTORY-P (pathname) (probe-file (concatenate 'string pathname "/."))) seems to work fairly reliably. (If "foo" is a directory, then "foo/." will be a valid filename; if not, it will return NIL.) This won't, of course, work on the Macintosh, or on other operating systems (e.g., MVS, CMS, ITS). On the Macintosh, use DIRECTORYP.
Moreover, some operating systems may not support the concept of directories, or even of a file system. For example, recent work on object-oriented technology considers files to be collections of objects. Each type of collection defines a set of methods for reading and writing the objects "stored" in the collection.
There's no standard function for finding the current directory from within a Lisp program, since not all Lisp environments have the concept of a current directory. Here are the commands from some Lisp implementations: Lucid: WORKING-DIRECTORY (which is also SETFable) PWD and CD also work Allegro: CURRENT-DIRECTORY (use excl:chdir to change it) CMU CL: DEFAULT-DIRECTORY LispWorks: LW:*CURRENT-WORKING-DIRECTORY* (use LW:CHANGE-DIRECTORY to change it)
Allegro also uses the variable *default-pathname-defaults* to resolve relative pathnames, maintaining it as the current working directory. So evaluating (truename "./") in Allegro (and on certain other systems) will return a pathname for the current directory. Likewise, in some VMS systems evaluating (truename "[]") will return a pathname for the current directory.
There is no portable way of creating a new directory from within a Lisp program.
A Lisp machine (or LISPM) is a computer which has been optimized to run lisp efficiently and provide a good environment for programming in it. The original Lisp machines were implemented at MIT, with spinoffs as LMI (defunct) and Symbolics (bankrupt). Xerox also had a series of Lisp machines (Dandylion, Dandytiger), as did Texas Instruments (TI Explorer). The TI and Symbolics Lisp machines are currently available as cards that fit into Macintosh computers (the so-called "Lisp on a chip").
Optimizations typical of Lisp machines include:
- Hardware Type Checking. Special type bits let the type be checked efficiently at run-time.
- Hardware Garbage Collection.
- Fast Function Calls.
- Efficient Representation of Lists.
- System Software and Integrated Programming Environments.
For further information, see:
Paul Graham, "Anatomy of a Lisp Machine", AI Expert, December 1988.
Pleszkun and Thazhuthaveetil, "The Architecture of Lisp Machines", IEEE Computer, March 1987.
Ditzel, Schuler and Thomas, "A Lisp Machine Profile: Symbolics 3650", AI Expert, January 1987.
Peter M. Kogge, "The Architecture of Symbolic Computers", McGraw-Hill 1991. ISBN 0-07-035596-7.
[Derived from a post by Arthur Pendragon <apendragon@delphi.com>.]
FBOUNDP tests whether the symbol is globally bound to an operator (e.g., a function, macro, or special form). SYMBOL-FUNCTION returns the contents of a symbol's "function slot" if the symbol names a function. But if the symbol names a macro or special form, it is completely unspecified what a call to SYMBOL-FUNCTION will return. Instead, use code like the following to test whether a symbol names a function:
(defun fbound-to-function-p (symbol) (and (fboundp symbol) (not (macro-function symbol)) (not (special-operator-p symbol))))
READ-FROM-STRING is one of the rare functions that takes both &OPTIONAL and &KEY arguments:
READ-FROM-STRING string &OPTIONAL eof-error-p eof-value
&KEY :start :end :preserve-whitespace
When a function takes both types of arguments, all the optional arguments must be specified explicitly before any of the keyword arguments may be specified. In the example above, :START becomes the value of the optional EOF-ERROR-P parameter and 3 is the value of the optional EOF-VALUE parameter.
To get the desired result, you should use (READ-FROM-STRING "foobar" t nil :START 3) If you need to understand and use the optional arguments, please refer to CLTL2 under READ-FROM-STRING, otherwise, this will behave as desired for most purposes.
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.
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*)
I assume you mean that it didn't seem to modify the original list. There are several possible reasons for this. First, many destructive functions are not *required* to modify their input argument, merely *allowed* to; in some cases, the implementation may determine that it is more efficient to construct a new result than to modify the original (this may happen in Lisp systems that use "CDR coding", where RPLACD may have to turn a CDR-NEXT or CDR-NIL cell into a CDR-NORMAL cell), or the implementor may simply not have gotten around to implementing the destructive version in a truly destructive manner. Another possibility is that the nature of the change that was made involves removing elements from the front of a list; in this case, the function can simply return the appropriate tail of the list, without actually modifying the list. And example of this is:
(setq *a* (list 3 2 1)) (delete 3 *a*) => (2 1) *a* => (3 2 1)
Similarly, when one sorts a list, SORT may destructively rearrange the pointers (cons cells) that make up the list. SORT then returns the cons cell that now heads the list; the original cons cell could be anywhere in the list. The value of any variable that contained the original head of the list hasn't changed, but the contents of that cons cell have changed because SORT is a destructive function:
(setq *a* (list 2 1 3)) (sort *a* #'<) => (1 2 3) *a* => (2 3)
In both cases, the remedy is the same: store the result of the function back into the place whence the original value came, e.g.
(setq *a* (delete 3 *a*)) *a* => (2 1)
Why don't the destructive functions do this automatically? Recall that they are just ordinary functions, and all Lisp functions are called by value. They see the value of the argument, not the argument itself. Therefore, these functions do not know where the lists they are given came from; they are simply passed the cons cell that represents the head of the list. Their only obligation is to return the new cons cell that represents the head of the list. Thus "destructive" just means that the function may munge the list by modifying the pointers in the cars and cdrs of the list's cons cells. This can be more efficient, if one doesn't care whether the original list gets trashed or not.
One thing to be careful about when doing this (storing the result back into the original location) is that the original list might be referenced from multiple places, and all of these places may need to be updated. For instance:
(setq *a* (list 3 2 1)) (setq *b* *a*) (setq *a* (delete 3 *a*)) *a* => (2 1) *b* => (3 2 1) ; *B* doesn't "see" the change (setq *a* (delete 1 *a*)) *a* => (2) *b* => (3 2) ; *B* sees the change this time, though
One may argue that destructive functions could do what you expect by rearranging the CARs of the list, shifting things up if the first element is being deleted, as they are likely to do if the argument is a vector rather than a list. In many cases they could do this, although it would clearly be slower. However, there is one case where this is not possible: when the argument or value is NIL, and the value or argument, respectively, is not. It's not possible to transform the object referenced from the original cell from one data type to another, so the result must be stored back. Here are some examples:
(setq *a* (list 3 2 1)) (delete-if #'numberp *a*) => NIL *a* => (3 2 1) (setq *a* nil *b* '(1 2 3)) (nconc *a* *b*) => (1 2 3) *a* => NIL
The names of most destructive functions (except for sort, delete, rplaca, rplacd, and setf of accessor functions) have the prefix N.
In summary, the two common problems to watch out for when using destructive functions are:
1. Forgetting to store the result back. Even though the list is modified in place, it is still necessary to store the result of the function back into the original location, e.g., (setq foo (delete 'x foo))
If the original list was stored in multiple places, you may
need to store it back in all of them, e.g.
(setq bar foo)
...
(setq foo (delete 'x foo))
(setq bar foo)
2. Sharing structure that gets modified. If it is important to preserve the shared structure, then you should either use a nondestructive operation or copy the structure first using COPY-LIST or COPY-TREE. (setq bar (cdr foo)) ... (setq foo (sort foo #'<)) ;;; now it's not safe to use BAR
Note that even nondestructive functions, such as REMOVE, and UNION, can return a result which shares structure with an argument. Nondestructive functions don't necessarily copy their arguments; they just don't modify them.
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.
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.
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.
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.
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.
DOTIMES, DOLIST, DO and LOOP all use assignment instead of binding to update the value of the iteration variables. So something like
(let ((l nil)) (dotimes (n 10) (push #'(lambda () n) l)))
will produce 10 closures over the same value of the variable N. To avoid this problem, you'll need to create a new binding after each assignment:
(let ((l nil)) (dotimes (n 10) (let ((n n)) (push #'(lambda () n) l))))
Then each closure will be over a new binding of n.
This is one reason why programmers who use closures prefer MAPC and MAPCAR to DOLIST.
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))
This question lists a variety of problems to watch out for when debugging code. This is sort of a catch-all question for problems too small to merit a question of their own. See also question [1-3] for some other common problems.
Functions:
* (flet ((f ...)) (eq #'f #'f)) can return false.
* The function LIST-LENGTH is not a faster, list-specific version of the sequence function LENGTH. It is list-specific, but it's slower than LENGTH because it can handle circular lists.
* Don't confuse the use of LISTP and CONSP. CONSP tests for the presence of a cons cell, but will return NIL when called on NIL. LISTP could be defined as (defun listp (x) (or (null x) (consp x))).
* Use the right test for equality: EQ tests if the objects are identical — numbers with the same value need not be EQ, nor are two similar lists necessarily EQ. Similarly for characters and strings. For instance, (let ((x 1)) (eq x x)) is not guaranteed to return T. EQL Like EQ, but is also true if the arguments are numbers of the same type with the same value or character objects representing the same character. (eql -0.0 0.0) is not guaranteed to return T. EQUAL Tests if the arguments are structurally isomorphic, using EQUAL to compare components that are conses, bit-vectors, strings or pathnames, and EQ for all other data objects (except for numbers and characters, which are compared using EQL). Except for strings and bit-vectors, arrays are EQUAL only if they are EQ. EQUALP Like EQUAL, but ignores type differences when comparing numbers and case differences when comparing characters. = Compares the values of two numbers even if they are of different types. CHAR= Case-sensitive comparison of characters. CHAR-EQUAL Case-insensitive comparison of characters. STRING= Compares two strings, checking if they are identical. It is case sensitive. STRING-EQUAL Like STRING=, but case-insensitive.
* Some destructive functions that you think would modify CDRs might modify CARs instead. (E.g., NREVERSE.)
* READ-FROM-STRING has some optional arguments before the keyword parameters. If you want to supply some keyword arguments, you have to give all of the optional ones too.
* If you use the function READ-FROM-STRING, you should probably bind *READ-EVAL* to NIL. Otherwise an unscrupulous user could cause a lot of damage by entering #.(shell "cd; rm -R *") at a prompt.
* Only functional objects can be funcalled in CLtL2, so a lambda expression '(lambda (..) ..) is no longer suitable. Use #'(lambda (..) ..) instead. If you must use '(lambda (..) ..), coerce it to type FUNCTION first using COERCE.
Methods:
* PRINT-OBJECT methods can make good code look buggy. If there is a problem with the PRINT-OBJECT methods for one of your classes, it could make it seem as though there were a problem with the object. It can be very annoying to go chasing through your code looking for the cause of the wrong value, when the culprit is just a bad PRINT-OBJECT method.
Initialization:
* Don't count on array elements being initialized to NIL, if you don't specify an :initial-element argument to MAKE-ARRAY. For example, (make-array 10) => #(0 0 0 0 0 0 0 0 0 0)
Iteration vs closures:
* DO and DO* update the iteration variables by assignment; DOLIST and DOTIMES are allowed to use assignment (rather than a new binding). (All CLtL1 says of DOLIST and DOTIMES is that the variable "is bound" which has been taken as _not_ implying that there will be separate bindings for each iteration.)
Consequently, if you make closures over an iteration variable
in separate iterations they may nonetheless be closures over
the same variable and hence will all refer to the same value
— whatever value the variable was given last. For example,
(let ((fns '()))
(do ((x '(1 2) (cdr x)))
((null x))
(push #'(lambda () x)
fns))
(mapcar #'funcall (reverse fns)))
returns (nil nil), not (1 2), not even (2 2). Thus
(let ((l nil))
(dolist (a '(1 2 3) l)
(push #'(lambda () a)
l)))
returns a list of three closures closed over the same bindings, whereas
(mapcar #'(lambda (a) #'(lambda () a)) '(1 2 3))
returns a list of closures over distinct bindings.
Defining Variables and Constants:
* (defvar var init) assigns to the variable only if it does not already have a value. So if you edit a DEFVAR in a file and reload the file only to find that the value has not changed, this is the reason. (Use DEFPARAMETER if you want the value to change upon reloading.) DEFVAR is used to declare a variable that is changed by the program; DEFPARAMETER is used to declare a variable that is normally constant, but which can be changed to change the functioning of a program.
* DEFCONSTANT has several potentially unexpected properties:
- Once a name has been declared constant, it cannot be used a
the name of a local variable (lexical or special) or function
parameter. Really. See page 87 of CLtL2.
- A DEFCONSTANT cannot be re-evaluated (eg, by reloading the
file in which it appears) unless the new value is EQL to the
old one. Strictly speaking, even that may not be allowed.
(DEFCONSTANT is "like DEFPARAMETER" and hence does an
assignment, which is not allowed if the name has already
been declared constant by DEFCONSTANT.)
Note that this makes it difficult to use anything other
than numbers, symbols, and characters as constants.
- When compiling (DEFCONSTANT name form) in a file, the form
may be evaluated at compile-time, load-time, or both.
(You might think it would be evaluated at compile-time and
the _value_ used to obtain the object at load-time, but it
doesn't have to work that way.)
Declarations:
* You often have to declare the result type to get the most efficient arithmetic. Eg,
(the fixnum (+ (the fixnum e1) (the fixnum e2)))
rather than
(+ (the fixnum e1) (the fixnum e2))
* Declaring the iteration variable of a DOTIMES to have type FIXNUM does not guarantee that fixnum arithmetic will be used. That is, implementations that use fixnum-specific arithmetic in the presence of appropriate declaration may not think _this_ declaration is sufficient. It may help to declare that the limit is also a fixnum, or you may have to write out the loop as a DO and add appropriate declarations for each operation involved.
FORMAT related errors:
* When printing messages about files, filenames like foo~ (a GNU-Emacs backup file) may cause problems with poorly coded FORMAT control strings.
* Beware of using an ordinary string as the format string, i.e., (format t string), rather than (format t "~A" string).
* FORMAT returns NIL, so if you added a format statement at the end of a function for debugging purposes, and that function normally returns a value to the caller, you may have changed the behavior of your program.
Miscellaneous:
* Be careful of circular lists and shared list structure.
* Watch out for macro redefinitions.
* A NOTINLINE may be needed if you want SETF of SYMBOL-FUNCTION to affect calls within a file. (See CLtL2, page 686.)
* When dividing two numbers, beware of creating a rational number where you intended to get an integer or floating point number. Use TRUNCATE or ROUND to get an integer and FLOAT to ensure a floating point number. This is a major source of errors when porting ZetaLisp or C code to Common Lisp.
* If your code doesn't work because all the symbols are mysteriously in the keyword package, one of your comments has a colon (:) in it instead of a semicolon (;).
* If you redefine a function while in the debugger, the redefinition may not take effect immediately. This will happen, for example, when the execution stack is halted near the invocation of the function. The function pointer on the stack will still be pointing to the old definition. Go up the stack a few levels before restarting to avoid reusing the old definition.
Hardly ever. Any time you think you need to use EVAL, think hard about it. EVAL is useful when implementing a facility that provides an external interface to the Lisp interpreter. For instance, many Lisp-based editors provide a command that prompts for a form and displays its value. Inexperienced macro writers often assume that they must explicitly EVAL the subforms that are supposed to be evaluated, but this is not so; the correct way to write such a macro is to have it expand into another form that has these subforms in places that will be evaluated by the normal evaluation rules. Explicit use of EVAL in a macro is likely to result in one of two problems: the dreaded "double evaluation" problem, which may not show up during testing if the values of the expressions are self-evaluating constants (such as numbers); or evaluation at compile time rather than runtime. For instance, if Lisp didn't have IF and one desired to write it, the following would be wrong:
(defmacro if (test then-form &optional else-form) ;; this evaluates all the subforms at compile time, and at runtime ;; evaluates the results again. `(cond (,(eval test) ,(eval then-form)) (t ,(eval else-form))))
(defmacro if (test then-form &optional else-form) ;; this double-evaluates at run time `(cond ((eval ,test) (eval ,then-form)) (t (eval ,else-form)))
This is correct:
(defmacro if (test then-form &optional else-form) `(cond (,test ,then-form) (t ,else-form)))
The following question (taken from an actual post) is typical of the kind of question asked by a programmer who is misusing EVAL:
I would like to be able to quote all the atoms except the first in a list of atoms. The purpose is to allow a function to be read in and evaluated as if its arguments had been quoted.
This is the wrong approach to solving the problem. Instead, he should APPLY the CAR of the form to the CDR of the form. Then quoting the rest of the form is unnecessary. But one wonders why he's trying to solve this problem in the first place, since the toplevel REP loop already involves a call to EVAL. One gets the feeling that if we knew more about what he's trying to accomplish, we'd be able to point out a more appropriate solution that uses neither EVAL nor APPLY.
On the other hand, EVAL can sometimes be necessary when the only portable interface to an operation is a macro.
Most likely your program is altering itself, and the most common way this may happen is by performing destructive operations on embedded constant data structures. For instance, consider the following:
(defun one-to-ten-except (n) (delete n '(1 2 3 4 5 6 7 8 9 10))) (one-to-ten-except 3) => (1 2 4 5 6 7 8 9 10) (one-to-ten-except 5) => (1 2 4 6 7 8 9 10) ; 3 is missing
The basic problem is that QUOTE returns its argument, *not* a copy of it. The list is actually a part of the lambda expression that is in ONE-TO-TEN-EXCEPT's function cell, and any modifications to it (e.g., by DELETE) are modifications to the actual object in the function definition. The next time that the function is called, this modified list is used.
In some implementations calling ONE-TO-TEN-EXCEPT may even result in the signalling of an error or the complete aborting of the Lisp process. Some Lisp implementations put self-evaluating and quoted constants onto memory pages that are marked read-only, in order to catch bugs such as this. Details of this behavior may vary even within an implementation, depending on whether the code is interpreted or compiled (perhaps due to inlined DEFCONSTANT objects or constant folding optimizations).
All of these behaviors are allowed by the draft ANSI Common Lisp specification, which specifically states that the consequences of modifying a constant are undefined (X3J13 vote CONSTANT-MODIFICATION:DISALLOW).
To avoid these problems, use LIST to introduce a list, not QUOTE. QUOTE should be used only when the list is intended to be a constant which will not be modified. If QUOTE is used to introduce a list which will later be modified, use COPY-LIST to provide a fresh copy.
For example, the following should all work correctly:
o (remove 4 (list 1 2 3 4 1 3 4 5)) o (remove 4 '(1 2 3 4 1 3 4 5)) ;; Remove is non-destructive. o (delete 4 (list 1 2 3 4 1 3 4 5)) o (let ((x (list 1 2 4 1 3 4 5))) (delete 4 x)) o (defvar *foo* '(1 2 3 4 1 3 4 5)) (delete 4 (copy-list *foo*)) (remove 4 *foo*) (let ((x (copy-list *foo*))) (delete 4 x))
The following, however, may not work as expected:
o (delete 4 '(1 2 3 4 1 3 4 5))
Note that similar issues may also apply to hard-coded strings. If you want to modify elements of a string, create the string with MAKE-STRING.
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)))
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.
Look for problems with your macro definitions, such as a macro that is missing a quote. When compiled, this definition essentially becomes a constant. But when interpreted, the body of the macro is executed each time the macro is called.
For example, in Allegro CL the following code will behave differently when interpreted and compiled: (defvar x 10) (defmacro foo () (incf x)) (defun bar () (+ (foo) (foo))) Putting a quote before the (incf x) in the definition of foo fixes the problem.
If you use (SETF (SYMBOL-FUNCTION 'foo) ...) to change the definition of a built-in Lisp function named FOO, be aware that this may not work correctly (i.e., as desired) in compiled code in all Lisps. In some Lisps, the compiler treats certain symbols in the LISP package specially, ignoring the function definition. If you want to redefine a standard function try proclaiming/declaring it NOTINLINE prior to compiling any use that should go through the function cell. (Note that this is not guarranteed to work, since X3J13 has stated that it is not permitted to redefine any of the standard functions).
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.
The Allegro CL 3.0 Web Version for Windows is a full functional free version of our Dynamic Object Oriented Programming Development System for ANSI standard CLOS, with some limitations*. This version includes an in-core native 32-bit compiler, a drag & drop Interface Builder, full debugging and development tools and an editor. We sell a supported version of this software, Allegro CL for Windows, without these limitations. For more information, call 1-800-3-CLOS-NOW or 1-510-548-3600, fax 1-510-548-8253, or send email to info@franz.com. Franz's web page is located at the URL http://www.franz.com/ Suggestions and bug reports should be sent to web@franz.com. Since this software is unsupported, they may not get back to you, but the input is still welcome. * The limitations are: limited heap size, no foreign function support, missing compile-file, missing disassembler and missing save-image. The documentation fully explains these capabilities.
CLiCC (Common Lisp to C Compiler) generates C-executables from Common Lisp application programs. CLiCC is not a Common Lisp system, and hence does not include any program development or debugging support. CLiCC is intended to be used as an add-on to existing Common Lisp systems for generating portable applications. (CLiCC has been tested in Allegro CL, Lucid CL, CMU CL, CLISP, and AKCL. It should run in any CLtL1 lisp with CLOS.) CLiCC supports CL_0, a subset of Common Lisp + CLOS, which excludes EVAL and related functions. At present CL_0 is based on CLtL1, but is headed towards CLtL2 and ANSI-CL. The generated C code (ANSI-C or K&R-C compatible) may be compiled using a conventional C compiler on the target machine, and must be linked with the CLiCC runtime library in order to generate executables. CLiCC has a foreign function interface. CLiCC is available by anonymous ftp from ftp.informatik.uni-kiel.de:/pub/kiel/apply/clicc-0.6.4.tar.gz [134.245.15.114]. CLiCC was developed by Wolfgang Goerigk <wg@informatik.uni-kiel.de>, Ulrich Hoffman <uho@informatik.uni-kiel.de>, and Heinz Knutzen <hk@informatik.uni-kiel.de> of Christian-Albrechts-Universitaet zu Kiel, Institut fuer Informatik und Praktische Mathematik, Preusserstr. 1-9, D-24105 Kiel, Germany. The authors welcome suggestions and improvements and would appreciate receiving email even if you just used CLiCC successfully. For more information, send mail to clicc@informatik.uni-kiel.de.
CLISP is a Common Lisp (CLtL1 + parts of CLtL2) implementation by Bruno Haible of Karlsruhe University and Michael Stoll of Munich University, both in Germany. It runs on microcomputers (DOS, OS/2, Atari ST, Amiga 500-4000) as well as on Unix workstations (Linux, Sun4, Sun386, HP9000/800, SGI, Sun3 and others) and needs only 1.5 MB of RAM. It is free software and may be distributed under the terms of GNU GPL. German and English versions are available, French coming soon. CLISP includes an interpreter, a compiler, a subset of CLOS (e.g., no MOP) and, for some machines, a screen editor. Packages running in CLISP include PCL and, on Unix machines, CLX and Garnet. Available by anonymous ftp from ma2s2.mathematik.uni-karlsruhe.de:/pub/lisp/clisp/ [129.13.115.2] For more information, contact haible@ma2s2.mathematik.uni-karlsruhe.de. There is a mailing list for users of CLISP. It is the proper forum for questions about CLISP, installation problems, bug reports, application packages etc. For information about the list and how to subscribe, send mail to listserv@ma2s2.mathematik.uni-karlsruhe.de, with the two lines help information clisp-list in the message body. A Sybase SQL interface interface for CLIPS is available by anonymous ftp from wuarchive.wustl.edu:packages/clips2sybase/. For more information, write to Sherry Steib <sherry@informatics.wustl.edu>.
CMU Common Lisp (CMU CL) is free, and runs on HPs, Sparcs (Mach, SunOs, and Solaris), DecStation 3100 (Mach), SGI MIPS (Iris), DEC Alpha/OSF1, IBM RT (Mach) and requires 16mb RAM, 25mb disk. It includes an incremental compiler, Hemlock emacs-style editor, source-code level debugger, code profiler and is mostly X3J13 compatible, including the new loop macro. It is available by anonymous ftp from ftp.cs.cmu.edu:/afs/cs.cmu.edu/project/clisp/release [128.2.206.173] Login with username "anonymous" and "userid@host" (your email address) as password. Due to security restrictions on anonymous ftps (some of the superior directories on the path are protected against outside access), it is important to "cd" to the source directory with a single command. Don't forget to put the ftp into binary mode before using "get" to obtain the compressed/tarred files. The binary releases are contained in files of the form <version>-<machine>_<os>.tar.Z Other files in this directory of possible interest are 17f-source.tar.gz, which contains all the ".lisp" source files used to build version 17f. A listing of the current contents of the release area is in the file FILES. You may also use "dir" or "ls" to see what is available. Bug reports should be sent to cmucl-bugs@cs.cmu.edu.
ECoLisp is a Common Lisp implementation which compiles Lisp functions into C functions that use the C stack and standard procedure call conventions. This lets Lisp and C code be easily mixed. It can be used as a C library from any C application. It is available by anonymous ftp from ftp.di.unipi.it:/pub/lang/lisp/ [131.114.4.36] ftp.icsi.berkeley.edu:/pub/ai/ecl/ [128.32.201.7] as the file ecl-??.tar.gz where ?? is the version number. This is an alpha release. So far it has been tested on Sun workstations (SunOS 4.x), SGI (IRIX 4.x), and IBM PC (DOS/go32). For more information, please contact Giuseppe Attardi <attardi@di.unipi.it> or <attardi@icsi.berkeley.edu>.
GNU Common Lisp (GCL) is a free implementation of Common Lisp (CLtL1) based originally on Austin Kyoto Common Lisp (AKCL). Versions 1.0 and above of GCL (aka versions 1-625 and above of AKCL) are available under the GNU General Public Library License v2.0, and no longer require the kcl.tar file to build the system. For information on previous versions of AKCL, see the KCL entry. GCL generates C code which it compiles with the local optimizing C compiler (e.g., GCC). It is intended to eventually support the ANSI standard for Common Lisp. GCL runs on Sparc, IBM RT, RS/6000, DecStation 3100, hp300, hp800, Macintosh (under A/UX), mp386, IBM PS2, IBM RT_AIX, Silicon Graphics 4d, Sun3, Sun4, Sequent Symmetry, IBM 370, NeXT, Vax, and IBM PC 386/486 (linux, bsd). GCL version 1.0 and above are available by anonymous ftp from ftp.cli.com:/pub/gcl/ [192.31.85.129] math.utexas.edu:/pub/gcl/ [128.83.133.215] as the file gcl-X.X.tgz (e.g., gcl-2.1.tgz), where X.X should be replaced with the version number; you'll generally want the largest version number. The bandwidth to math.utexas.edu is higher than cli. The file pcl-gcl-1.0.tgz contains a port of PCL (CLOS) to GCL. The file xgcl-2.tgz contains an interface to X Windows for GCL, including a low-level interface to Xlib, and in addition to being available from the above sites, is also available from ftp.cs.utexas.edu:/pub/novak/xgcl/ http://www.cs.utexas.edu/users/novak/ For more information, write to William Schelter <wfs@math.utexas.edu> (or <wfs@cli.com>, <wfs@rascal.ics.utexas.edu>). GCL is under continuing development, and folks interested in helping should send him email. Andy Wang <awang@plains.nodak.edu> has compiled GCL 1.0 for Linux 1.1.50 (using gcc 2.5.8 and libc 4.5.26) and made the resulting binaries available by anonymous ftp from sunsite.unc.edu:/pub/Linux/Incoming/gcl-1.0.bin.tgz
Kyoto Common Lisp (KCL) is free, but requires a license. Conforms to CLtL1. KCL was written by T. Yuasa <yuasa@tutics.tut.ac.jp> and M. Hagiya <hagiya@is.s.u-tokyo.ac.jp> at Kyoto University in 1984. Austin Kyoto Common Lisp (AKCL) is a collection of ports, bug fixes and improvements to KCL by Bill Schelter (<wfs@cli.com> or <wfs@rascal.ics.utexas.edu>). Since 1994, AKCL versions 1-625 and higher are covered by the GNU GPL, so generally one will generally not need KCL (see GCL above for details). {A}KCL generates C code which it compiles with the local C compiler. Both are available by anonymous ftp from rascal.ics.utexas.edu:/pub/ [128.83.138.20] ftp.cli.com:/pub/ [192.31.85.1] utsun.s.u-tokyo.ac.JP:/pub/ [133.11.11.11] KCL is in the file kcl.tar, and AKCL is in the file akcl-xxx.tar.Z (take the highest value of xxx). To obtain KCL, one must first sign and mail a copy of the license agreement to: Special Interest Group in LISP, c/o Taiichi Yuasa, Department of Computer Science, Toyohashi University of Technology, Toyohashi 441, JAPAN. Runs on Sparc, IBM RT, RS/6000, DecStation 3100, hp300, hp800, Macintosh (under A/UX), mp386, IBM PS2, Silicon Graphics 4d, Sun3, Sun4, Sequent Symmetry, IBM 370, NeXT and Vax. For the beta test version of the DOS port, see the files akclexe.zip and go32sexe.zip in math.utexas.edu:/pub/msdos/akcl-beta/ Commercial versions of {A}KCL are available from Austin Code Works, 11100 Leafwood Lane, Austin, TX 78750-3409, Tel. 512-258-0785, Fax 512-258-1342, E-mail guthery@acw.com, including a CLOS for AKCL. See also Ibuki, below.
PowerLisp is a Common Lisp development environment for the Macintosh. It consists of a Common Lisp interpreter, native-code 680x0 compiler, 680x0 macro assembler, disassembler, incremental linker and multi-window text editor. It requires a Macintosh with at least a 68020 processor (any Mac except a Plus, SE or Classic) and system 7.0 or later. About 2 megabytes of RAM are required to run it, and to do much with it you need more like 5 or 6 megabytes. Like any Common Lisp system, the more memory the better. PowerLisp has the ability to run in the background. While executing a Common Lisp program, the user may switch to another application as it continues to run. You can also edit programs while a Common Lisp program is running. PowerLisp is targeted to be compatible with CTLTL2 without CLOS (for now) but some Common Lisp functions are not yet implemented. Upcoming versions should include the remaining language features. The current released version is 1.10. PowerLisp is available from America Online and Genie as a shareware program ($50). It is also available from the Lisp Repository, as ftp.cs.cmu.edu:/user/ai/lang/lisp/impl/powerlsp/v1_10/powerlsp.hqx Written by Roger Corman. For more information, send mail to PowerLisp@aol.com, roger@island.com or rogerc34@aol.com (RogerC34 on America Online).
RefLisp is a small Lisp interpreter. Versions exist for MS Windows, MS-DOS and UNIX (AIX). The MS-DOS version supports CGA/EGA/VGA graphics and the Microsoft Mouse. The interpreter is a shallow-binding (i.e., everything has dynamic scope), reference counting design making it suitable for experimenting with real-time and graphic user interface programming. Common Lisp compatibility macros are provided, and most of the examples in "Lisp" by Winston & Horn have been run on RefLisp. RefLisp makes no distinction between symbol-values and function-values, so a symbol can be either but not both. RefLisp comes with an ASCII manual and many demonstration programs, including an analogue clock which never stops for garbage collection. It is written in ANSI C and is in the public domain. Source and binaries are available from the author's Web site at http://www.ozemail.com.au/~birchb/reflisp.html and from the Lisp Utilities repository by anonymous ftp from ftp.cs.cmu.edu:/user/ai/lang/lisp/impl/reflisp/ For further information, send email to the author Bill Birch <birchb@ozemail.com.au>.
WCL is an implementation of Common Lisp for Sparc based workstations. It is available free by anonymous ftp from cdr.stanford.edu:/pub/wcl/ [36.93.0.31] as the files wcl2.2-solaris-src.tar.gz, wcl2.2-solaris-bins.tar.gz, wcl2.2-sunos4-src.tar.gz, wcl2.2-sunos4-bins.tar.gz, and wgdb4.2-sunos4.tar.gz. It includes a native solaris version (but with no dynamic .o loading or wgdb yet...), can use any version of GCC 2.X (GCC 2.1 is no longer required), and includes separate binary and source distribution so that recompilation is no longer needed to install WCL and WGDB. The wcl2.2-*.tar.gz files contain the WCL distribution, including CLX and PCL; wgdb4.2-sunos4.tar.gz contains a version of the GDB debugger which has been modified to grok WCL's Lisp. WCL provides a large subset of Common Lisp as a Unix shared library that can be linked with Lisp and C code to produce efficient and small applications. For example, the executable for a Lisp version of the canonical ``Hello World!'' program requires only 40k bytes under SunOS 4.1 for SPARC. WCL provides CLX R5 as a shared library, and comes with PCL and a few other utilities. For further information on WCL, see the paper published in the proceedings of the 1992 Lisp and Functional Programming Conference, a copy of which appears in the wcl directory as lfp-paper.ps, or look in the documentation directory of the WCL distribution. Written by Wade Hennessey <wade@sunrise.stanford.edu>. Please direct any questions to wcl@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.
XLISP is free, and runs on the IBM PC (MSDOS), Windows 95, Apple Macintosh, and Unix. It should run on anything with an Ansi C compiler. It was written by David Michael Betz, 18 Garrison Drive, Bedford, NH 03110, 603-472-2389 (H&W), DavidBetz@aol.com or dbetz@xlisper.mv.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.1g* is the same as XLISP 2.0, but modified by Tom Almy <toma@sail.labs.tek.com> to bring it closer to Common Lisp, in addition to fixing several bugs. The latest version of XLISP can be obtained by anonymous ftp from ftp.cs.cmu.edu:/user/ai/lang/lisp/impl/xlisp/ [128.2.206.173] It may also be available (in possible older versions) from ftp.biostr.washington.edu:/pub/xlisp [128.95.10.115] wasp.eng.ufl.edu:/pub [128.227.116.1] A Macintosh port of version 2.1e (and the C source code to its interface) is also available, from Macintosh ftp sites such as sumex.stanford.edu:/info-mac/dev/xlisp-21e2.hqx mac.archive.umich.edu:/mac/development/languages/xlisp2.1e2.sit.hqx The Macintosh version was written by Brian Kendig, <bskendig@netcom.com>. To obtain a copy through US mail, send email to Tom Almy, toma@sail.labs.tek.com. A Windows version of the statistical version of xlisp is available by anonymous ftp from ftp.cica.indiana.edu:/util/wxlslib.zip A version of XLISP-PLUS 2.1g that includes an experimental byte code compiler is available by anonymous ftp from umnstat.stat.umn.edu:/pub/xlispstat/xlisponly/ [128.101.51.1] as the file xlisp21gbc.tar.gz. Write to Luke Tierney <luke@stat.umn.edu> for more information.
Allegro Common Lisp:
Allegro Common Lisp 4.2 runs on a variety of platforms, including Sparcs, RS6000, HP700, Silicon Graphics, DecStation (prices start at $4,500) and NeXT ($2,000). It requires 12mb RAM for the 680x0 and 16mb for RISC. It includes native CLOS, X-windows support, Unix interface, incremental compilation, generational garbage collection, and a foreign function interface. Options include Allegro Composer (development environment, including debugger, inspector, object browser, time/space code profiler, and a graphical user interface, $1,500), Common LISP Interface Manager (CLIM 2.0 is a portable high-level user interface management system. CLIM 2.0 for Allegro CL supports both Motif and Openlook and Windows, ($1,000). Franz also markets Allegro CL 3.0 for Windows 3.1, Windows NT and Windows95 for $595 (discount prices of $449 are sometimes advertised in various AI magazines). A Professional version with royalty free runtime distribution and source code is available for $2495. Allegro CL for Windows provides 32-bit compilation, complete CLOS, an integrated development environment, visual drag & drop Interface Builder, interface to the Windows API, DLL support, and free runtime delivery. Write to: Franz Inc., 1995 University Avenue, Berkeley, CA 94704 or call 1-800-333-7260, 510-548-3600, fax 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. To receive Franz Flash, Franz's electronic newsletter, send mail to flash@franz.com. Files related to the products (e.g., patches, Franz's GNU-Emacs/Lisp interface, the Allegro FAQ) are available by anonymous ftp from ftp.franz.com:/pub/ [192.48.96.9] http://www.franz.com/
CLOE:
CLOE (Common Lisp Operating Environment) is a cross-development environment for IBM PCs (MSDOS) and Symbolics Genera. It includes CLOS, condition error system, generational garbage collection, incremental compilation, code time/space profiling, and a stack-frame debugger. It costs from $625 to $4000 and requires 4-8mn RAM and a 386 processor. Write to: Symbolics, 6 New England Tech Center, 521 Virginia Road, Concord, MA 01742, call 1-800-394-5522 or 508-287-1000 or fax 508-287-1099.
Golden Common Lisp:
Golden Common Lisp (GCLisp 4.4) runs on IBM PCs under DOS, Windows, OS/2, and Windows NT, costing $2,000 ($250 extra for Gold Hill Windows), and includes an incremental compiler, foreign function interface, interactive debugger, SQL interface, and emacs-like editor. It supports DDE and other Windows stuff, and is CLtL1 compatible. Supports PCL/CLOS. It requires 4mb RAM, and 12mb disk. See a review in PC-WEEK 4/1/91 comparing GCLisp with an older version of MCL. Write to: Gold Hill Computers, 26 Landsdowne Street, Cambridge, MA 02139, call 617-621-3300, or fax 617-621-0656.
Harlequin LispWorks:
LispWorks (R) from Harlequin runs on a variety of Unix platforms, including Sun Sparc and clones (SunOS and Solaris), IBM RS/6000 (AIX), DEC MIPS (Ultrix), DEC Alpha (OSF/1), HP PA (HP-UX), and SGI (IRIX). LispWorks uses menus and graphics to provide convenient, user friendly access to its wide array of powerful tools. A C/C++ interface, an SQL interface, and a fully integrated Prolog compiler are a standard part of LispWorks. CLIM 2.0 is also available.
+ COMMON LISP: CLtL2 compatible, native CLOS/MOP, generational GC,
C/C++ interface.
+ ENVIRONMENT: Prolog, Emacs-like editor/listener/shell, defadvice,
defsystem, cross-referencing, lightweight processes,
debugger, mail reader, extensible hypertext online doc, LALR
parser generator.
+ BROWSERS/GRAPHERS: files, objects, classes, generic functions,
source code systems, specials, compilation warnings.
+ GRAPHICS: CLX, CLUE, Toolkit, CAPI, Open Look, Motif,
interface builder.
+ INTEGRATED PRODUCTS: CLIM 2.0, KnowledgeWorks (RETE engine).
For further information, contact by e-mail worldwide: lispworks-request@harlequin.com (OR @harlequin.co.uk) or in the US: FAX: 617-252-6505 Voice: 800-WORKS-4-YOU (800-967-5749) or 617-374-2400 or 617-252-0052 Mail: Harlequin Inc., One Cambridge Center, Cambridge, MA 02142 or in Europe: FAX: 0223-872-519 (OR 44-1223-872-519 from outside UK) Voice: 0223-873-800 OR -872-522 (OR 44-1223-873-800 from outside UK) Telex: 818440 harlqn g Mail: Harlequin Ltd., Barrington Hall, Barrington, Cambridge, CB2 5RG
For more information, see their web page at the URL http://www.harlequin.com/
Harlequin FreeLisp:
Harlequin Inc. is shipping FreeLisp (TM), which has been developed specifically to meet the Lisp teaching requirements of the academic community in terms of both functionality and price. FreeLisp is a reduced implementation of Harlequin's premier Common Lisp development environment, LispWorks (R). FreeLisp runs under on PC's under Windows, and has many of the environmental features as LispWorks but does not include a compiler. For prices and information about FreeLisp, contact by e-mail worldwide lispworks-request@harlequin.com (OR @harlequin.co.uk) or in the US: fax: 617-252-6505 voice: 800-WORKS-4-YOU (800-967-5749) or 617-374-2400 or 617-252-0052 mail: Harlequin Inc., One Cambridge Center, Cambridge, MA 02142 or in Europe: fax: 0223-872-519 (OR 44-1223-872-519 from outside UK) voice: 0223-873-800 OR -872-522 (OR 44-1223-873-800 from outside UK) Telex: 818440 harlqn g mail: Harlequin Ltd., Barrington Hall, Barrington, Cambridge, CB2 5RG Freelisp is available at the URL http://www.harlequin.com/freelisp/
Ibuki Common Lisp:
Ibuki Common Lisp (IBCL) v02/01 is a commercialized and improved version of Kyoto Common Lisp. It runs on over 30 platforms, including Sun3, Sparc, Dec (Ultrix), Apollo, HP 9000, IBM RS/6000, Silicon Graphics and IBM PCs (under AIX). It includes an incremental compiler, interpreter, and C/Fortran foreign function interface. It generates C code from the Lisp and compiles it using the local C compiler. Image size is about 3mb. Cost is $2800 (workstations), $3500 (servers), $700 (IBM PCs). Supports CLOS and CLX ($200 extra). Source code is available at twice the cost. Ibuki now also has a product called CONS which compiles Lisp functions into linkable Unix libraries. Write to: Ibuki Inc., PO Box 1627, Los Altos, CA 94022, or call 415-961-4996, fax 415-961-8016, or send email to Richard Weyhrauch, rww@ibuki.com or support@ibuki.com.
LinkLisp:
LinkLisp is a Lisp implementation for Windows that supports a large subset of Common Lisp. It is DLL and VBX callable from C/C++ and Visual Basic. It costs $249. For more information, write to Conscious Computing, 3100 Connecticut Avenue NW, Suite 202, Washington, DC 20008, call 202-483-6350, or fax 202-462-9110.
Lucid Common Lisp:
Lucid Common Lisp runs on a variety of platforms, including PCs (AIX), Apollo, HP, Sun-3, Sparc, IBM RT, IBM RS/6000, Decstation 3100, Silicon Graphics, and Vax. Lucid includes native CLOS, a foreign function interface, and generational garbage collection. CLIM is available for Lucid as a separate product. See also the comments in question [1-2] on the wizards.doc file that comes with the release.
[Note: Lucid encountered financial difficulties because of forays into C-related products; the Lisp end of the company remained strong. Harlequin announced on 23-NOV-94 that they have acquired the rights to the Lisp-related technology of Lucid, Inc., that they will market and support Lucid Common Lisp alongside their LispWorks products, and that they have hired several former Lucid employees for this purpose.]
For further information, contact by e-mail worldwide: lispworks-request@harlequin.com (OR @harlequin.co.uk) or in the US: FAX: 617-252-6505 Voice: 800-WORKS-4-YOU (800-967-5749) or 617-374-2400 or 617-252-0052 Mail: Harlequin Inc., One Cambridge Center, Cambridge, MA 02142 or in Europe: FAX: 0223-872-519 (OR 44-1223-872-519 from outside UK) Voice: 0223-873-800 OR -872-522 (OR 44-1223-873-800 from outside UK) Telex: 818440 harlqn g Mail: Harlequin Ltd., Barrington Hall, Barrington, Cambridge, CB2 5RG
Macintosh Common Lisp:
Macintosh Common Lisp (MCL) is an object-oriented dynamic language (OODL) from Digitool, Inc. MCL 4.0 will work on any Power Macintosh with at least 16 MB of RAM, 28 MB of disk storage, and Macintosh System Software 7.5 or later. MCL 3.1 will work on any 68K-based Macintosh with at least 8 MB of RAM, 15 MB of disk storage, and Macintosh System 6.x or 7.x. Both versions are included on CD-ROM together with extensive documentation, runtime sources, development utilities, and sample code. A CD-ROM drive is required for installation.
MCL implements the industry standard Common Lisp programming language and CLOS (as defined in Common Lisp: The Language, second edition), and is fully integrated with the Macintosh family of personal computers.
MCL is a completely integrated development environment, including a fast incremental compiler which produces efficient native PPC code or 680x0 code, a window-based debugger, a source code stepper, a dynamic object inspector, a stack backtrace inspector, a programmable Macintosh-style emacs-like editor, online documentation, and an interactive interface toolkit. MCL supports multiple processes and provides both high-level object-oriented user interface class library and complete low-level access to the Macintosh Toolbox.
Using MCL, you can create a standalone double-clickable Macintosh application. A license is required to distribute an application created with MCL. Licenses are available to include the MCL compiler in a distributed application.
MCL may be purchased individually or as a subscription; site licenses are also available. For more information, mailto:info@digitool.com; for orders, mailto:orders@digitool.com, call (617) 441-5000 or fax (617) 576-7680. See http://www.digitool.com/MCL-price-list.html for current pricing.
Medley:
Medley 2.0 is a Common Lisp development environment that includes a native CLOS w/MOP, window toolkit, window-based debugger, incremental compiler, structure editor, inspectors, stepper, cross-referencer (Masterscope), code analysis tools, and browsers. It is the successor to InterLisp-D. It runs on a variety of platforms, including Suns, DecStations, 386/486s, IBM RS/6000, MIPS, HP, DEC Alpha, and Xerox 1186. The price for Unix machines is $3,195 for the developer version and $1,250 for the runtime version. Medley also runs under DOS 4.0 or higher ($795 developer version, $300 runtime version, and $250 student version). Instructional licenses are also available at $250/copy for DOS (to a max of $1,250) and $1,000/copy for Unix (to a max of $5,000). For more information, write to Venue, 1624 Franklin Street, Suite 1212, Oakland, CA 94612, call 800-228-5325 or 510-835-8856, fax 510-835-8251, or send email to aisupport.mv@envos.xerox.com.
muLISP-90:
muLISP-90 v7.1 is a small Lisp which runs on IBM PCs (or the HP 95LX palmtop), MS-DOS version 2.1 or later. It isn't Common Lisp, although there is a Common Lisp compatibility package which augments muLISP-90 with over 450 Common Lisp special forms, macros, functions and control variables. Includes a screen-oriented editor and debugger, a window manager, an interpreter and a compiler. Among the example programs is DOCTOR, an Eliza-like program. The runtime system allows one to create small EXE or COM executables. Uses a compact internal representation of code to minimize space requirements and speed up execution. The kernel takes up only 50k of space. Costs $150. muLISP-XM is a version of muLISP-90 that can take advantage of up to 4 gigabytes of extended memory and costs $300. Write to Soft Warehouse, Inc., 3660 Waialae Avenue, Suite 304, Honolulu, HI 96816-3236, call 808-734-5801, or fax 808-735-1105.
NanoLISP:
NanoLISP 2.0 is a Lisp interpreter for DOS systems that supports a large subset of the Common Lisp (CLtL2) standard, including lexical and dynamic scoping, four lambda-list keywords, closures, local functions, macros, output formatting, generic sequence functions, transcendental functions, 2-d arrays, bit-arrays, sequences, streams, characters double-floats, hash-tables and structures. Runs in DOS 2.1 or higher, requiring only 384k of RAM. Cost is $100. Write to: Microcomputer Systems Consultants, PO Box 6646, Santa Barbara, CA 93160 or call 805-967-2270.
Poplog Common Lisp:
Poplog Common Lisp is an incremental compiler and X-based development environment for Common Lisp. Poplog Common Lisp provides a compact and memory-efficient implementation which has recently been upgraded to include support for CLtL2, including a native CLOS implementation.
The Poplog environment also includes efficient incremental compilers for Prolog, Standard ML and Pop-11, a language-sensitive editor and supports easy dynamic linking to C, Fortran etc. Poplog has over 400 customers in 36 countries.
Poplog runs on a variety of platforms including Sun SPARC (SunOS 4.1, Solaris 2.x), HP-RISC (HP-UX), Silicon Graphics (IRIX), PC UNIX (SCO, Linux), DECstation (Ultrix) and under VMS on both VAX and Alpha.
For more information, contact: Integral Solutions Ltd, 3 Campbell Court, Bramley, Basingstoke, Hants. RG26 5EG, UK. Call +44 (0)1256 882028, fax +44 (0)1256 882182 Email isl@isl.co.uk
In North America, contact: Computable Functions, Inc., 35 South Orchard Drive, Amherst, MA 01002. Call 413-253-7637, fax 413-545-1249.
Procyon Common Lisp:
Procyon Common Lisp runs on either the Apple Macintosh or IBM PC (386/486 or OS/2 native mode), costing 450 pounds sterling ($675) educational, 1500 pounds ($2250) commercial. It requires 2.5mb RAM on the Macintosh and 4mb RAM on PCs (4mb and more than 4mb recommended respectively). It is a full graphical environment, and includes a native CLOS with meta-object protocol, incremental compilation, foreign function interface, object inspector, text and structure editors, and debugger. Write to: Scientia Ltd., St. John's Innovation Centre, Cowley Road, Cambridge, CB4 4WS, UK, with phone +44-223-421221, fax +44-223-421218. E-mail: 100142.341@compuserve.com. [NOTE: The rights to the MS Windows version of Procyon were sold to Franz who are marketing and developing it as Allegro CL\PC. See Allegro's entry for more information. The MS Windows version of Procyon is no longer available from Scientia. Expertelligence no longer distributes any version of Procyon.]
Software Engineer:
Software Engineer 2.1 is a Lisp for Windows that creates small stand-alone executables (no royalties or run-time libraries required). It is a subset of Common Lisp, but includes CLOS. Supports DDE and Windows API calls. It requires 2mb RAM, but can use up to 16mb of memory, generating 286/386 specific code. It costs $350. Write to: Raindrop Software, 833 Arapaho Road, Suite 104, Richardson, TX 75081, call 214-234-2611, fax 214-234-2674, or send email to 70632.3126@compuserve.com.
Star Sapphire Common LISP:
Star Sapphire Common LISP 3.4 provides a subset of Common Lisp and includes an emacs-like editor, compiler, debugger, DOS graphics and CLOS. It runs on IBM PCs (MSDOS or Windows), requires 640k RAM, a hard disk, and costs $100. Write to: Sapiens Software Corporation, PO Box 3365, Santa Cruz, CA 95063-3365, call 408-458-1990, fax 408-425-0905/9220. Copies may also be ordered from the Programmers' Shop at 800-421-8006. Sapiens Software also has a Lisp-to-C translator in beta-test.
Top Level Common Lisp:
Top Level Common Lisp includes futures, a debugger, tracer, stepper, foreign function interface and object inspector. It runs on Unix platforms, requiring 8mb RAM, and costs $687. Write to: Top Level, 100 University Drive, Amherst, MA 01002, call (413) 549-4455, or fax (413) 549-4910.
Lisps which run on special-purpose hardware (Lisp Machines) include
o Symbolics 1-800-394-5522 (508-287-1000) fax 508-287-1092 6 Concord Farms, 555 Virginia Road, Concord, MA 01742. In Germany: Symbolics Systemhaus GmbH, Mergenthalerallee 77, 65760 Eschborn, (49) 6196-47220, fax (49) 6196-481116. Symbolics Open Genera runs on DEC 3000 Workstations (models 600 and 800 APX with the OSF/1 operating system), at a price of $18,500.
o TI Explorers Texas Instruments Incorporated, Data Systems Group, P.O. Box 181153 DSG-230, Austin, Texas 78718
o Xerox Interlisp. See Medley above.
Lisp-to-C Translator translates Common Lisp into human-readable ANSI C. Release 3.2 supports such features as CLOS, the condition system, Lisp type declaration heeding, and Mac, Windows, and Alpha compatibility. (Release 3.0, introduced in 1992, eliminated the old requirement that the garbage collector had to be called explicitly). Works with Lucid, Symbolics, Allegro, Harlequin and MCL. It costs $11,995. Write to: Chestnut Software, Inc., 2 Park Plaza, Suite 205, Boston, MA, 02116, call 617-542-9222, fax 617-542-9220, or e-mail Mr. Kenneth J. Koocher <ken@chestnut.com>.
Some Lisp compilers (AKCL, Ibuki) and Scheme compilers (Bigloo, Hobbit/SCM, Scheme->C) compile into C.
Scheme implementations are listed in the Scheme FAQ posting,
Free Scheme implementations include PC-Scheme, PCS/Geneva, MIT Scheme (aka C-Scheme), SCM, Hobbit, Gambit, T, Oaklisp, Elk, Scheme->C, SIOD (Scheme in One Defun), XScheme, Fools' Lisp, Scheme48, UMB Scheme, VSCM, Pixie Scheme, HELP (a lazy Scheme), Similix, FDU Scheme, PseudoScheme, Scheme84 and Scheme88.
Commercial Scheme implementations include Chez Scheme, MacScheme, and EdScheme.
Of the free Scheme implementations, the following are implemented in Lisp:
Peter Norvig's book "Paradigms of AI Programming" has a chapters about Scheme interpreters and compilers, both written in Common Lisp. The software from the book is available by anonymous ftp from mkp.com:/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 swiss-ftp.ai.mit.edu:/archive/pseudo/pseudo-2-8.tar.Z [18.43.0.152] It is Scheme implemented on top of Common Lisp, and runs in Lucid, Symbolics CL, VAX Lisp under VMS, and Explorer CL. It should be easy to port to other Lisps. It was written by Jonathan Rees (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.
Scheme84 is in the public domain, and available by mail from Indiana University. It runs on the VAX in Franz Lisp under either VMS or BSD Unix. To receive a copy, send a tape and return postage to: Scheme84 Distribution, Nancy Garrett, c/o Dan Friedman, Department of Computer Science, Indiana University, Bloomington, Indiana. Call 1-812-335-9770 or send mail to nlg@indiana.edu for more information. It will also run in Jeff Dalton's port of Franz Lisp to Net/Free/386BSD on 386-like machines. (See the Lisp FAQ for information on Franz Lisp.)
Scheme88 is a re-implementation of Scheme84 to run in Common Lisp. It available by anonymous ftp from rice.edu:/public/scheme88.sh and also from the Scheme Repository.
Franz Lisp:
[Franz Lisp is a dialect of Lisp that predates Common Lisp. It is very similar to MacLisp. It lacks full lexical scoping.]
The official archive site for Franz List Opus 38.92 and 38.93b (the last public domain releases) is ftp.cs.cmu.edu:/user/ai/lang/others/franzlsp/ It includes the official version from the ucbvax ftp site before its demise, Barry Schein's port of 38.92, the UC Davis port of 38.92, and Jeff Dalton's port of 38.92 (see below). For more information, contact ai+franzlsp@cs.cmu.edu.
An implementation of (Berkeley) Franz Lisp Opus 38.92 for 386/486 machines running NetBSD 0.9 (and possibly also 386BSD and FreeBSD) is available by anonymous ftp from macbeth.cogsci.ed.ac.uk:/pub/franz-for-NetBSD/ The implementation generates C code and hence is quite portable. It has been tested on 68K Suns, VAX 750s, and ICL Perqs running PNX. A reference manual is included in the distribution. For more information, write to Jeff Dalton <J.Dalton@ed.ac.uk>, or see the URL http://www.aiai.ed.ac.uk/~jeff/franz-for-386.html
PC LISP is a Lisp interpreter for IBM PCs (MSDOS) available from any site that archives the group comp.binaries.ibm.pc, such as wuarchive.wustl.edu:/mirrors/msdos/lisp/pclisp30.zip PC-LISP is a Franz LISP dialect and is by no means Common LISP compatible. It is also available directly from the author by sending 2 blank UNFORMATTED 360K 48TPI IBM PC diskettes, a mailer and postage to: Peter Ashwood-Smith, 8 Du Muguet, Hull, Quebec, CANADA, J9A-2L8; phone 819-595-9032 (home). Source code is available from the author for $15.
EuLisp:
Feel (Free and Eventually Eulisp) is an initial implementation of the EuLisp language. It can be retrieved by anonymous FTP from ftp.bath.ac.uk:/pub/eulisp/ as the file feel-0.75.tar.Z. feel-0.75.sun4.Z is the Sparc executable. The EuLisp language definition is in the same directory. Feel is also available from ftp.gmd.de:/languages/lisp/eulisp/ [129.26.8.84] It includes an integrated object system, a module system, condition system, and support for parallelism (threads). EuLisp (European Lisp) is sort of like an extended Scheme. The program is a C-based interpreter, and a bytecode interpreter/compiler will be available sometime soon. The distribution includes an interface to the PVM library, support for TCP/IP sockets, and libraries for futures, Linda, and CSP. Feel is known to run on Sun3, Sun4, Stardent Titan, Alliant Concentrix 2800, Orion clippers, DEC VAX, DECstation 3000, Gould UTX/32, and Inmos T800 transputer (using CS-Tools). (All bar the last four have a threads mechanism.) It can run in multi-process mode on the first three machines, and hopefully any other SysV-like machine with shared memory primitives. Porting Feel to new machines is reasonably straightforward. It now also runs on MS-DOS machines. Written by Pete Broadbery <pab@maths.bath.ac.uk>.
Apply/Eu2C is an EuLisp->C compiler available from ISST. Eu2C runs on top of Franz Allegro CL 4.1 and compiles EuLisp-Modules into C source code which then must be compiled by an ANSI C-compiler (currently only GCC is supported). The Eu2C implementation provides EuLisp 0.99 level-0, with the exception of concurrency. Future versions of Eu2C will include a C interface and straight module compilation. The development of Apply/Eu2C was supported by the German Federal Ministry for Research and Technology (BMFT) within the joint project APPLY. The partners of this project are the Christian Albrechts University Kiel, the Fraunhofer Institute for Software Engineering and Systems Engineering (ISST), the German National Research Center for Computer Science(GMD), and VW-Gedas. The main goal of APPLY project is to develop a Lisp system which consistently supports the efficient execution of applications and simplifies their integration into current software environments. Towards that end, ISST is investigating strategies for the compilation of EuLisp-Modules into efficient stand-alone C-Programs. The Eu2C compiler is the first step along this path. Eu2C is available by anonymous ftp from ftp.isst.fhg.de:/APPLY/Distribution/. Please send bug reports and comments to ulrich.kriegel@isst.fhg.de or ingo.mohr@isst.fhg.de. If you're using Eu2C, please send them a message with "Apply/Eu2C" in the subject line to be added to the mailing list of users.
More information about EuLisp may be found in Lisp and Symbolic Computation 6(1-2), August 1993 which was devoted to EuLisp.
JLISP: jlisp is a lisp interpreter designed to be used as an embedded interpreter and is easily interfaced with C/C++. jlisp is easily extended. It is available by anonymous ftp from ftp.ee.rochester.edu:/pub/weisberg/jlisp-1.03.tar.gz For more information, write to Jeff Weisberg <weisberg@ee.rochester.edu>
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.
Le-Lisp includes a compiler, color and graphic output, a debugger, a pretty printer, performance analysis tools, tracing, and incremental execution. Le-Lisp currently runs on Unix, VMS, and Windows 3.1. Note that Le-Lisp is neither Common Lisp nor Scheme. Le-Lisp was originally developed in 1980 at Inria, the French national computer science laboratory, by a team led by Jerome Chailloux for work on VLSI design. It was based on several earlier Lisps in the MacLisp family, but was not directly derived from MacLisp. Le-Lisp enjoyed a large success in the French academic world because it was small, fast, and portable, being based on a abstract machine language called LLM3. In 1983, for example, Le-Lisp ran on Z-80 machines running CP/M. In 1987, Ilog was formed as an offshoot of Inria to commercialize and improve Le-Lisp and several products which had been developed with it, including a portable graphic interface system and an expert system shell. Since then, Ilog has continued to grow and expand the use of Le-Lisp into industrial markets around the world. Ilog is the largest European Lisp vendor, and continues to develop new products and markets for Lisp. In 1992, Ilog released the next major version of Le-Lisp, Le-Lisp version 16. This version modernizes Le-Lisp for use in the industrial world, adding lexical closures and special-form-based semantics for static analysis, a new object system based on the EuLisp object system (TELOS), an enhanced module system for application production, a conservative GC for integration with C and C++, and compilation to C for portability and efficiency on a wide range of processors. For pricing and other information, write to ILOG, 2 Avenue Gallieni, BP 85, 94253 Gentilly Cedex, France, call 33-1-46-63-66-66, fax 33-1-46-63-15-82, or send email to Jerome Chailloux (chaillou@ilog.fr).
CLISP v6.89 is a library of functions which extends the C programming language to include some of the functionality of Lisp. Requires ANSI C. Costs $349 with no run-time fee. Write to Drasch Computer Software, 187 Slade Road, Ashford, CT 06278, or call or fax 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.
Lily (LIsp LibrarY) is a C++ class library that lets C++ programmers write LISP-style code. Includes some example programs from Winston's Lisp book recoded in Lily. Most or all of chapters 17 (Symbolic Pattern Matching), 18 (Expert Problem Solving), and 23 (Lisp in Lisp) are implemented in the examples. Lily works with GNU G++ (2.4.5) and Turbo C++ for Windows. Lily is available by anonymous ftp from sunsite.unc.edu:/pub/packages/development/libraries/ [152.2.22.81] as lily-0.1.tar.gz. This site is fairly slow; a copy is available from the Lisp Utilities collection. For more information, contact Roger Sheldon <sheldon@kong.gsfc.nasa.gov>.
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.
Dylan is a new Object-Oriented Dynamic Language (OODL), based on Scheme, CLOS, and Smalltalk. The purpose of the language is to retain the benefits of OODLs and also allow efficient application delivery. The design stressed keeping Dylan small and consistent, while allowing a high degree of expressiveness. Dylan is consistently object-oriented; it is not a procedural language with an object-oriented extension. A manual/specification for the language is available from Apple Computer. Send email to 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 newsgroup comp.lang.dylan is gatewayed to the info-dylan mailing list.
Send mail to the -request version of the list to be added to it. You can also send an email message to majordomo@cambridge.apple.com with "subscribe info-dylan" or "unsubscribe info-dylan" in the body, and likewise for the other lists, mutatis mutandis.
Apple hasn't announced plans to release Dylan as a product.
The directory cambridge.apple.com:pub/dylan contains some documents pertaining to Dylan, including a FAQ list.
======== THOMAS ========
Thomas is a compiler for a language that is compatible with the language described in the book "Dylan(TM) an object-oriented dynamic language" by Apple Computer Eastern Research and Technology, April 1992. Thomas was written at Digital Equipment Corporation's Cambridge Research Laboratory. Thomas is NOT Dylan(TM) and was built with no direct input, aid, assistance or discussion with Apple.
Thomas is available to the public by anonymous ftp at crl.dec.com:/pub/DEC/Thomas gatekeeper.pa.dec.com:/pub/DEC/Thomas swiss-ftp.ai.mit.edu:/archive/Thomas
The Thomas system is written in Scheme and runs under MIT's CScheme, DEC's Scheme->C, and Marc Feeley's Gambit. It can run on a wide range of machines including the Macintosh, PC compatibles, Vax, MIPS, Alpha, and 680x0. Thomas generates IEEE compatible Scheme code.
A ready-made version of Thomas 1.1 interpreter built upon MacGambit 2.0 as a double-clickable Macintosh application is available by anonymous ftp from cambridge.apple.com:/pub/dylan/gambit/ as the file thomas-1.1-interp.hqx.
For discussion of Thomas, send a note to info-thomas-request@crl.dec.com to be added to the mailing list.
DEC CRL's goals in building Thomas were to learn about Dylan by building an implementation, and to build a system they could use to write small Dylan programs. As such, Thomas has no optimizations of any kind and does not perform well.
The original development team consisted of: Matt Birkholz (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.
======== Marlais ========
Marlais is a simple interpreter for a language strongly resembling Dylan. It is available by anonymous ftp from ftp.cis.ufl.edu:/pub/Marlais cambridge.apple.com:/pub/dylan/Marlais travis.csd.harris.com:/pub/ Currently runs on i386 and i486 (OS/2 or Linux), IBM PC/RT, IBM RS/6000, HP9000/300, HP9000/700, DECstations (Ultrix), SGI (IRIX), Sony News, Apple Macintosh (A/UX), Sun3, Sun4, Vax (4.3bsd and ultrix), m88k (Harris Nighthawk running CX/UX), MIPS M/120, Sequent Symmetry, Encore Multimax. Contact Joe Wilson <jnw@cis.ufl.edu> or Brent Benson <brent@ssd.csd.harris.com> for more information.
================
The Gwydion Project at CMU is developing an innovative new software development environment based on the Dylan language (and, in the process, will make available a very high-quality implementation of Dylan). This project includes many of the same people responsible for CMU Common Lisp. (In Welsh mythology, Gwydion is the uncle of Dylan and nephew of Math.) A Mosaic page describing the project goals, how they fit in with the Dylan language, and copies of the Dylan language manual and latest approved design notes is available as http://legend.gwydion.cs.cmu.edu/gwydion/ For more information, write to gwydion-group@cs.cmu.edu.
Mindy (Mindy Is Not Dylan Yet) is a Dylan-like language from the Gwydion Project. Mindy is intended for use as a development tool while work on the "real" high-performance Dylan implementation progresses. Mindy is available by anonymouse ftp from legend.gwydion.cs.cmu.edu as the file /afs/cs.cmu.edu/project/gwydion/release/mindy.tar.gz. Send bug reports to gwydion-bugs@cs.cmu.edu; support will be minimal.
When Apple Computer acquired Coral Software in January 1989, they re-released Coral's Allegro Common Lisp and its optional modules as Macintosh Allegro Common Lisp (now just Macintosh Common Lisp). Coral's other product, Pearl Lisp, was discontinued at that time. Pearl Lisp provides a subset of the functionality of MACL 1.3 and is not even fully CLtL1-compatible (e.g., the implementation of defstruct is different).
Despite rumors to the contrary, Pearl Lisp is not and never was public domain. Nevertheless, Pearl Lisp and its documentation were placed in the "Moof:Goodies:Pearl Lisp" folder on the first pressing of "Phil and Dave's Excellent CD", the precursor to the current Apple Developer's CD-ROM series. Apple removed Pearl from later versions of the developer CD-ROM distribution because of complaints from other Lisp vendors. If you own a copy of Pearl Lisp or a copy of this CD-ROM, you can make it runnable under System 7 with some slight modifications using ResEdit. To repeat, Pearl Lisp is NOT public domain, so you must own a copy to use it.
To make it runnable, one needs to use ResEdit to make changes to the BNDL and FREF resources so that it will connect to its icons properly. This will make it respond to double-clicks in the normal manner and make it be properly linked to its files. Detailed instructions for modifying Pearl Lisp using ResEdit may be obtained from the Lisp Utilities Repository by anonymous ftp from ftp.cs.cmu.edu:/user/ai/lang/lisp/impl/pearl/ as the file pearl.txt.
After you've made the changes, it will run under System 7 on 68000s and 68030s if you turn off 32-bit addressing. It seems to bomb on a Quadra.
If you need a more powerful Lisp or one that is compatible with the standard for Common Lisp, consider purchasing Macintosh Common Lisp.
Before posting to any discussion group, please read the rest of this FAQ, to make sure your question isn't already answered.
Scheme-related mailing lists and newsgroups are listed in the Scheme FAQ, and AI-related mailing lists and newsgroups are listed in the AI FAQ.
First of all, there are several Lisp-related newsgroups: comp.lang.lisp General Lisp-related discussions. See below for archive information.
comp.lang.clos Discussion related to CLOS, PCL, and object-oriented programming in Lisp. Gatewayed to commonloops@cis.ohio-state.edu. (or equivalently, comp.lang.clos@cis.ohio-state.edu) See below for info on the newsgroup's archives.
comp.org.lisp-users Discussions related to Association of Lisp Users. Gatewayed to the ALU mailing list. This is an organizational mailing list/newsgroup, not a technical forum.
comp.std.lisp For discussion of emerging standards for the Lisp language, including "de facto" standards. Moderated by Brad Miller <miller@cs.rochester.edu>. Submissions should be sent to lisp-standards@cs.rochester.edu Archived on ftp.cs.rochester.edu:/pub/archives/lisp-standards/ Gatewayed to a mailing list (send mail to lisp-standards-request@cs.rochester.edu to join).
comp.lang.lisp.mcl Discussions related to Macintosh Common Lisp. This newsgroup is gatewayed to the info-mcl@digitool.com mailing list and archived on digitool.com.
comp.lang.lisp.franz Discussion of Franz Lisp, a dialect of Lisp. (Note: *not* Franz Inc's Allegro.)
comp.lang.lisp.x Discussion of XLISP, a dialect of Lisp, and XScheme.
comp.sys.xerox Discussions related to using Medley (name exists for historical reasons, and is likely to change soon). Gatewayed to the info-1100 mailing list.
comp.sys.ti.explorer TI Explorers Lisp machines.
comp.windows.garnet Garnet, a Lisp-based GUI.
comp.ai and subgroups General AI-related dicusssion.
The newsgroup comp.lang.lisp is archived on ftp.gmd.de:/usenet/comp.lang.lisp/ [129.26.8.84] by month, from 1989 onward. Individual files are in rnews format. (They contain articles prefixed by a header line "#! rnews <nchars> archive" where <nchars> is the number of characters in the article following the header. That format is convenient for various news processing programs (e.g. relaynews) and is rather easy to process from a lisp program too.) A copy of the GMD archives for comp.lang.lisp is available on cambridge.apple.com:/pub/comp.lang.lisp/.
We list several mailing lists below. In general, to be added to a mailing list, send mail to the "-request" version of the address. This avoids flooding the mailing list with annoying and trivial administrative requests. [To subscribe to info-dylan, or other mailing lists based at cambridge.apple.com, send a message to majordomo@cambridge.apple.com with "subscribe <list_name>" in the message body. Likewise use "unsubscribe <list_name>" to cancel your subscription and "help" to get help.]
General Lisp Mailing Lists:
common-lisp@ai.sri.com Technical discussion of Common Lisp. lisp-utilities@cs.cmu.edu Low volume moderated mailing list associated with the Lisp Utilities Repository at CMU. (Also known as cl-utilities@cs.cmu.edu) lisp-faq@think.com A mailing list concerning the contents of this FAQ posting only.
alu@freud.arc.nasa.gov Forum for use by members (current and prospective) of the Association of Lisp Users. It is bidirectionally gatewayed into the newsgroup comp.org.lisp-users. This is an organizational mailing list, not a technical forum.
Particular Flavors of Lisp:
info-mcl@digitool.com Macintosh Common Lisp. Gatewayed to the comp.lang.lisp.mcl newsgroup. info-mcl-digest@digitool.com Automatically generated digest format version of the info-mcl mailing list.
cmucl-bugs@cs.cmu.edu CMU Common Lisp bug reports
slug@ai.sri.com Symbolics Lisp Users Group Archived on warbucks.ai.sri.com and ftp.ai.sri.com:/pub/slug.
allegro-cl@cs.berkeley.edu Franz Allegro Common Lisp
amiga-lisp@contessa.phone.net Lisp on the Amiga
kcl@cli.com Kyoto Common Lisp Archived in ftp.cli.com:/pub/kcl/kcl-mail-archive kcl@rascal.ics.utexas.edu Forwards to kcl@cli.com.
lispworks@harlequin.com LispWorks
clisp-list@ma2s2.mathematik.uni-karlsruhe.de CLISP To subscribe, send mail to listserv@ma2s2.mathematik.uni-karlsruhe.de with "subscribe clisp-list <your full name>" in the message body. Use "help" to get a help message back and "unsubscribe clisp-list" to remove yourself from the list.
info-ti-explorer@sumex-aim.stanford.edu TI Explorer Lisp Machine bug-ti-explorer@sumex-aim.stanford.edu TI Explorer Lisp Machine
info-1100@cis.ohio-state.edu Xerox/Envos Lisp machine environment, InterLisp-D, and Medley. Gatewayed to the newsgroup comp.sys.xerox. Will be moving to info-1100@anzus.com.
franz-friends@cs.berkeley.edu The Franz Lisp Language. franz-composers@cs.berkeley.edu Maintainers of Franz Lisp.
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@gmd.de GINA and CLM lispworks@harlequin.co.uk LispWorks winterp@netcom.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) Discussion related to CLOS, PCL, and object-oriented programming in Lisp. The name is in honor of the first freely-available implementation of CLOS, Xerox PARC's Portable Common Loops, and was originally the mailing list for discussing that implementation. Now gatewayed to the comp.lang.clos newsgroup. The mailing list is archived on nervous.cis.ohio-state.edu in the directory pub/lispusers/commonloops. The CLOS code repository is in pub/lispusers/clos.
Miscellaneous:
stat-lisp-news-request@umnstat.stat.umn.edu Use of Lisp and Lisp-based systems in statistics. Lisp-Jobs@cis.ohio-state.edu Job offers requiring a knowledge of Lisp. See [1-7].
Electronic Journals:
Electronic Journal of Functional and Logic Programming (EJFLP)
EJFLP is a refereed journal that will be distributed for free via e-mail.
The aim of EJFLP is to create a new medium for research investigating the
integration of the functional, logic and constraint programming paradigms.
For instructions on submitting a paper, send an empty mail message with
Subject: Help
to
submissions@ls5.informatik.uni-dortmund.de.
You will receive an acknowledgment of your submission within a few hours.
To subscribe to the journal, send an empty mail message to
subscriptions@ls5.informatik.uni-dortmund.de
You will receive an acknowledgment of your subscription within
a few days.
If there are any problems with the mail-server, send mail to
ejflp.op@ls5.informatik.uni-dortmund.de.
The editorial board is: Rita Loogen (RWTH Aachen), Herbert Kuchen (RWTH
Aachen), Michael Hanus (MPI-Saarbruecken), Manuel MT Chakravarty (TU
Berlin), Martin Koehler (Imperial College London), Yike Guo (Imperial
College London), Mario Rodriguez-Artalejo (Univ. Madrid), Andy Krall
(TU Wien), Andy Mueck (LMU Muenchen), Tetsuo Ida (Univ. Tsukuba,
Japan), Hendrik C.R. Lock (IBM Heidelberg), Andreas Hallmann (Univ.
Dortmund), Peter Padawitz (Univ. Dortmund), Christoph Brzoska (Univ.
Karlsruhe).
As of December 8, 1994, Common Lisp is now an official ANSI Standard: ANSI X3.226:1994 American National Standard for Programming Language Common LISP (X3J13).
Copies of the ANSI/X3.226 standard may be purchased from the American National Standards Institute 11 West 42nd Street New York, NY 10036 For more information, visit the ANSI home page at http://www.ansi.org/
A web version of the ANSI Common Lisp standard is not available. The official ANSI standard is available only in hardcopy form.
However, Kent Pitman (kmp@harlequin.com) of Harlequin, Inc. has, with permission from ANSI and X3, written an HTML document that is based on ANSI standard for Common Lisp. This version is not a definitive reference, but is much more practical for most casual browsing. It is also cross-referenced against some design documents. The document is available for online browsing at http://www.harlequin.com/books/HyperSpec/FrontMatter/index.html Subject to some legal restrictions, you can download a copy for your own use and get much better performance. Visit http://www.harlequin.com/books/HyperSpec/ for information on downloading your own copy. The .tar.gz file is just a little over 2MB, and unpacks into a set of files that is just a little over 15MB.
Copies of the TeX sources and Unix-compressed DVI files for the *draft* version of the standard may be obtained by anonymous FTP from parcftp.xerox.com:/pub/cl/ [13.1.64.94] The files corresponding to the second Public Review of Common Lisp are in the directory /pub/cl/dpANS2/*. These files correspond to draft 14.10, also known as document X3J13/93-102, which was forwarded by X3J13 to X3 in October, 1993. (The files from the first draft are in the directory /pub/cl/dpANS1/*.) The draft is about 1500 pages long. The file Reviewer-Notes.text should be read before ftping the other files.
For more information, write to X3 Secretariat, Attn: Lynn Barra, 1250 Eye Street NW, Suite 200, Washington, DC 20005-3922, call 202-626-5738, fax 202-638-4922, or send email to x3sec@itic.nw.dc.us.
The international working group on Lisp is ISO/IEC JTC1/SC22/WG16. Pierre Parquier (parquier@ilog.fr) is the WG16 Convenor. Kent Pitman (kmp@harlequin.com) is the International Representative of X3J13 to WG16 and is also Project Editor for WG16. WG16 is working on the design of a dialect of Lisp called ISLISP (which is neither a subset nor a superset of Common Lisp). A Committee Draft (CD) of the ISLISP specification has been registered by WG16 as ``CD13816: Information Technology - Programming languages, their environments and system software interfaces - Programming language ISLISP.'' The CD, which WG16 internally refers to as version 15.6, is available by anonymous FTP from ma2s2.mathematik.uni-karlsruhe.de:/pub/lisp/islisp/ [129.13.115.2] in the directory islisp-15.6/. The draft has passed its first CD letter ballot. A second WG16 letter ballot will be held to determine whether this Committee Draft will become a Draft International Standard (DIS); this is expected to happen by April 1996.
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" ("Claws"), depending on taste. PCL (Portable Common Loops) is a portable CLOS implementation, and is available by anonymous ftp from parcftp.xerox.com:/pub/pcl/ [13.1.64.94] Also in the same directory are sources for CLX R5 and an inspecter.
Most Common Lisp implementations now include their own CLOS
implementations. Common Lisp implementations with native CLOS include:
MCL, {A}KCL, Allegro CL (including Allegro CL
AI_ATTIC is an anonymous ftp collection of classic AI programs and other information maintained by the University of Texas at Austin. It includes Parry, Adventure, Shrdlu, Doctor, Eliza, Animals, Trek, Zork, Babbler, Jive, and some AI-related programming languages. This archive is available by anonymous ftp from ftp.cc.utexas.edu:/pub/AI_ATTIC/ [128.83.186.13] (AKA bongo.cc.utexas.edu). For more information, contact atticmaster@bongo.cc.utexas.edu.
Analogical Reasoning:
SME is the Structure-Mapping Engine, as described in Falkenhainer, Forbus, and Gentner's 1987 AIJ article. Available from multivac.ils.nwu.edu:/pub/SME For further information, contact Brian Falkenhainer <falkenhainer@parc.xerox.com> or Ken Forbus <forbus@ils.nwu.edu>.
Benchmarks:
Gabriel Lisp Benchmarks are available by anonymous ftp as ai.toronto.edu:/pub/gabriel-lisp-benchmarks.tar.Z. The benchmarks are described in the book "Performance Evaluation of Lisp Systems", by Richard Gabriel.
Lucid CL contains a set of benchmarks in its goodies/ directory, including Bob Boyer's logic programming benchmark, a benchmark to create and browse through an AI-like database of units, a CLOS speed test, a compilation speed test, TAKR (the 100 function version of TAK that tries to defeat cache memory effects), CTAK (A version of the TAKeuchi function that uses the CATCH/THROW facility), STAK (A version of the TAKeuchi function with special variables instead of parameter passing), DERIV and DDERIV (Symbolic derivative benchmarks written by Vaughn Pratt), DESTRU (a destructive operation benchmark), DIV2 (a benchmark which divides by 2 using lists of n ()'s), the FFT benchmark written by Harry Barrow, FPRINT (a benchmark to print to a file), FRPOLY (a Franz Lisp benchmark by Fateman based on polynomial arithmentic), Forest Baskett's PUZZLE benchmark (originally written in Pascal), the TPRINT benchmark to read and print to the terminal, a benchmark that creates and traverses a tree structure, and TRIANG (board game benchmark). Some of the benchmarks may work only in Lucid.
Blackboard Architectures:
The UMass GBB system (V1.2) is available by anonymous ftp from ftp.cs.umass.edu:/gbb. The commercial GBB product is not. Work on the UMass GBB project (and funding) ended over 2 years ago. Many researchers using it have opted for the commercial release. The UMass research system remains available, but the two should not be confused as the commercial system is substantially improved and extended. The commercial system is available from Blackboard Technology Group, 401 Main Street, Amherst, Massachusetts 01002, telephone 800-KSS-8990 or 413-256-8990, fax 413-256-3179.
For a tutorial on how to build a blackboard system, see the paper P. R. Kersten and Avi C. Kak, "A Tutorial on LISP Object-Oriented Programming for Blackboard Computation (Solving the Radar Tracking Problem)", International Journal of Intelligent Systems 8:617-669, 1993 Although samples of the code are given in the paper, the full source code is available in a separate technical report from the School of Electrical Engineering at Purdue University. If you are interested in getting a copy of the technical report, send mail to Avi Kak <kak@ecn.purdue.edu>. (The circumstances under which the software was developed prevent them from making the source code available by anonymous FTP. However, the full source code is printed in the technical report.)
Case-based Reasoning:
CL-Protos is a Common Lisp implementation of the case-based reasoning system developed by E. Ray Bareiss and Bruce W. Porter of the University of Texas/Austin AI Lab. It runs on Sun3, TI Explorer, HP 9000, and Symbolics, and gobbles a huge amount of memory. Common Lisp implementation by Rita Duran, Dan Dvorak, Jim Kroger, Hilel Swerdlin, and Ben Tso. For more information, bug reports, or comments, contact either Dan Dvorak <dvorak@cs.utexas.edu> or Ray Bareiss <bareiss@ils.nwu.edu> or Erik Eilerts <eilerts@cs.utexas.edu> Available by anonymous ftp from cs.utexas.edu:/pub/porter
The complete code for "Inside Case-Based Reasoning" by Riesbeck and Schank, 1989, is available by anonymous ftp from cs.umd.edu:/pub/schank/icbr/ This includes code for an instructional version of CHEF by Kristian Hammond and MICRO-xxx. Contact Bill Andersen <waander@cs.umd.edu> for more information.
CLOS Software: See question [5-6].
Constraint Programming and Non-determinism:
SCREAMER:
Screamer is an extension of Common Lisp that adds support for nondeterministic programming. Screamer consists of two levels. The basic nondeterministic level adds support for backtracking and undoable side effects. On top of this nondeterministic substrate, Screamer provides a comprehensive constraint programming language in which one can formulate and solve mixed systems of numeric and symbolic constraints. Together, these two levels augment Common Lisp with practically all of the functionality of both Prolog and constraint logic programming languages such as CHiP and CLP(R). Furthermore, Screamer is fully integrated with Common Lisp. Screamer programs can coexist and interoperate with other extensions to Common Lisp such as CLOS, CLIM and Iterate.
In several ways Screamer is more efficient than other implementations of backtracking languages. First, Screamer code is transformed into Common Lisp which can be compiled by the underlying Common Lisp system. Many competing implementations of nondeterministic Lisp are interpreters and thus are far less efficient than Screamer. Second, the backtracking primitives require fairly low overhead in Screamer. Finally, this overhead to support backtracking is only paid for those portions of the program which use the backtracking primitives. Deterministic portions of user programs pass through the Screamer to Common Lisp transformation unchanged. Since in practise, only small portions of typical programs utilize the backtracking primitives, Screamer can produce more efficient code than compilers for languages in which backtracking is more pervasive.
Screamer is fairly portable across most Common Lisp implementations. It currently runs under Genera 8.1.1 and 8.3 on both Symbolics 36xx and Ivory machines, under Lucid 4.0.2 and 4.1 on Sun SPARC machines, under MCL 2.0 and 2.0p2 on Apple Macintosh machines, and under Poplog Common Lisp on Sun SPARC machines. It should run under any implementation of Common Lisp which is compliant with CLtL2 and with minor revision could be made to run under implementations compliant with CLtL1 or dpANS.
Screamer is available by anonymous FTP from ftp.ai.mit.edu:/pub/screamer.tar.Z Contact Jeffrey Mark Siskind <qobi@ai.mit.edu> for further information. Screamer is also available from the Common Lisp Repository.
The Screamer Tool Repository, a collection of user-contributed Screamer code, is available by anonymous ftp from ftp.cis.upenn.edu:/pub/screamer-tools/ or by WWW from http://www.cis.upenn.edu/~screamer-tools/home.html Please direct all inquires about the repository to screamer-repository@cis.upenn.edu.
Defeasible Reasoning:
An implementation of J. Paris and A. Vencovska's model of belief is available by anonymous ftp from ftp.cs.cmu.edu:/user/ai/areas/reasonng/defeasbl/belief/ Paris and Vencovska's paper (Artificial Intelligence, 64(2), December 1993) provides a mathematical model of an agent's belief in an event by identifying it with his ability to imagine the event within the context of his previous experience. This approach leads to beliefs having properties different from those normally ascribed to it. The implementation was written by Ian Pratt <ipratt@cs.man.ac.uk> and Jens Doerpmund <dorpmunj@cs.man.ac.uk> and runs in Common Lisp.
Eliza and Similar Programs:
See Peter Norvig's book and AI_ATTIC (question [6-1] above).
The doctor.el is an implementation of Eliza for GNU-Emacs emacs-lisp. Invoke it with "Meta-X doctor"
muLISP-87 (a MSDOS Lisp sold by Soft Warehouse) includes a Lisp implementation of Eliza.
Implementations of ELIZA for other languages are mentioned in the AI FAQ.
The original Parry (in MLISP for a PDP-10) is available in labrea.stanford.edu:/pub/parry.tar.Z.
Other programs, such as RACTER, are listed in part 4 of the AI FAQ.
Expert Systems:
FOCL is an expert system shell and machine learning program written in Common Lisp. The machine learning program extends Quinlan's FOIL program by containing a compatible explanation-based learning component. FOCL learns Horn Clause programs from examples and (optionally) background knowledge. The expert system includes a backward-chaining rule interpreter and a graphical interface to the rule and fact base. For details on FOCL, see: Pazzani, M. and Kibler, D., "The role of prior knowledge in inductive learning", Machine Learning 9:54-97, 1992. It is available by anonymous ftp from ics.uci.edu:/pub/machine-learning-programs/ as the files README.FOCL-1-2-3, FOCL-1-2-3.cpt.hqx (a binhexed, compacted Macintosh application), FOCL-1-2-3.tar.Z (Common Lisp source code), and FOCL-1-2-3-manual.hqx (binhexed manual). If you use a copy of FOCL, or have any comments or questions, send mail to 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 ftp.gmd.de:/gmd/ai-research/Software/Babylon/ [129.26.8.84] as a BinHexed stuffit archive, on the Web via the URL http://www.gmd.de/ on the Apple CD-ROM, or with the book "The AI Workbench BABYLON", which contains *full source code* of BABYLON and the stand-alone version for the Mac. The book describes the use of BABYLON in detail.
OPS5 is a public domain Common Lisp implementation of the OPS5 production system interpreter written by Charles Forgy. It is available from the CMU AI Repository in ftp.cs.cmu.edu:/user/ai/areas/expert/ops5/ and includes the original port by George Wood and Jim Kowalski (ops5orig.tar.gz), and a later port by Mark Kantrowitz (ops5.tar.gz). The latter has been tested under Allegro, Lucid, CMU CL, Ibuki CL and MCL.
Frame Languages:
FrameWork is a portable generic frame system available from the CMU AI Repository, in ftp.cs.cmu.edu:/user/ai/areas/kr/systems/frames/framewrk/
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 <kessler@cs.utah.edu> 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 <franconi@irst.it>.
Genetic Algorithms:
GECO (Genetic Evolution through Combination of Objects) is a genetic algorithm shell written by George Williams, <george@hsvaic.boeing.com>. It is available by anonymous ftp from cambridge.apple.com:/pub/mcl2/contrib/ as the following files: GECO-v1.0.cpt.hqx binhex'd Compact Pro archive GECO-v1.0.tar.Z compressed tar file for Unix machines (no MCL fonts) GECO.abstract a brief description It runs in MCL 2.0, but should be portable among CLtL2 compliant Common Lisps.
GAL is a genetic algorithm suite written by Bill Spears of NRL. The MCL2.0 port was done by Howard Oakley <howard@quercus.demon.co.uk> and is available from cambridge.apple.com:/pub/MCL2/contrib as GAL.sea.hqx. Improvements and adaptations should be sent to Bill Spears, but questions on the MCL port should be directed to Howard Oakley.
Other genetic algorithms code is available ftp.aic.nrl.navy.mil:/pub/galist including Genesis (source-code/ga-source/genesis.tar.Z) and the archives of the GA-List mailing list. A survey of free and commercial genetic algorithms implementations is available in information/ga-software-survey.txt.
Knowledge Representation:
KNOWBEL is an implementation of Telos (a sorted/temporal logic system) by Bryan M. Kramer, <kramer@ai.toronto.edu>. It is available by anonymous ftp from ai.toronto.edu:/pub/kr/ as the files knowbel.tar.Z and manual.txt.tar.Z Runs in Allegro CL on Sparcstations and Silicon Graphics 4d and in MCL on Apple Macintoshes.
SNePS (Semantic Network Processing System) is the implementation of a fully intensional theory of propositional knowledge representation and reasoning. SNePS includes a module for creating and accessing propositional semantic networks, path-based inference, node-based inference based on SWM (a relevance logic with quantification) that uses natural deduction and can deal with recursive rules, forward, backward and bi-directional inference, nonstandard logical connectives and quantifiers, an assumption based TMS for belief revision, a morphological analyzer and a generalized ATN (GATN) parser for parsing and generating natural language, SNePSLOG, a predicate-logic-style interface to SNePS, XGinseng, an X-based graphics interface for displaying, creating and editing SNePS networks, SNACTor, a preliminary version of the SNePS Acting component, and SNIP 2.2, a new implementation of the SNePS Inference Package that uses rule shadowing and knowledge migration to speed up inference. SNeRE (the SNePS Rational Engine), which is part of Deepak Kumar's dissertation about the integration of inference and acting, will replace the current implementation of SNACTor. SNePS is written in Common Lisp, and has been tested in Allegro CL 4.1, Lucid CL 4.0, TI Common Lisp, CLISP May-93, and CMU CL 17b. It should also run in Symbolics CL, AKCL 1.600 and higher, VAX Common Lisp, and MCL. The XGinseng interface is built on top of Garnet. SNePS 2.1 is free according to the GNU General Public License version 2. The SNePS distribution is available by anonymous ftp from ftp.cs.buffalo.edu:/pub/sneps/ [128.205.32.9] as the file rel-x-yyy.tar.Z, where 'x-yyy' is the version. The other files in the directory are included in the distribution; they are duplicated to let you get them without unpacking the full distribution if you just want the bibliography or manual. If you use SNePS, please send a short message to shapiro@cs.buffalo.edu and snwiz@cs.buffalo.edu. Please also let them know whether you'd like to be added to the SNUG (SNePS Users Group) mailing list.
COLAB (COmpilation LABoratory) is a hybrid knowledge representation system emphasizing the horizontal and vertical compilation of knowledge bases. It is comprised of cooperating subsystems — CONTAX, FORWARD, RELFUN and TAXON — which deal with different knowledge representation and reasoning formalisms. Each subsystem can also be used as stand-alone system. CONTAX deals with constraint nets and constraint-propagation techniques. Relational knowledge in the form of Horn rules is processed by forward (FORWARD) and backward (RELFUN) chaining. Taxonomic knowledge is represented by intensional concept definitions which are automatically arranged in a subsumption hierarchy (TAXON). The COLAB software was developed at DFKI and the University of Kaiserslautern and runs in Common Lisp. (The subsystems have been tested in AKCL and Lucid CL, and possibly also Allegro CL and Symbolics CL.) All the subsystems are available free of charge for research purposes. o RELFUN is a logic-programming language with call-by-value (eager), non-deterministic, non-ground functions, and higher-order operations. It accepts freely interchangeable LISP-style and PROLOG-style syntaxes. For sources to RELFUN and copies of relevant papers, contact Dr. Harold Boley, DFKI, Postfach 2080, W-6750 Kaiserslautern, Germany, call +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.
URANUS is a logic-based knowledge representation language. Uranus is an extension of Prolog written in Common Lisp and using the syntax of Lisp. Uranus extends Prolog with a multiple world mechanism for knowledge representation and term descriptions to provide functional programming within the framework of logic programming. It is available free by anonymous ftp from etlport.etl.go.jp:/pub/uranus/ftp/ [192.31.197.99] for research purposes only. For more information contact the author, Hideyuki Nakashima <nakashim@etl.go.jp>.
Languages and Alternate Syntaxes:
Generalized Lisp (or Glisp for short) is a coordinated set of high level syntaxes for Common Lisp. Initially GLisp consists of three dialects: Mlisp, Plisp and ordinary Lisp, together with an extensible framework for adding others. Mlisp (Meta-Lisp) is an Algol-like syntax for people who don't like writing parentheses. For example, one can write print("abc", stream) instead of (print "abc" stream). Plisp (Pattern Lisp) is a pattern matching rewrite-rule language. Plisp is a compiler-compiler; its rules are optimized for writing language translators. All dialects may be freely intermixed in a file. The translators for all dialects are written in Plisp, as is the Glisp translator framework itself. Support routines for the translators are written in Mlisp and/or Lisp. All dialects are translated to Common Lisp and execute in the standard Common Lisp environment. Glisp is available by anonymous ftp from apple.com or ftp.apple.com:/dts/mac/lisp/glisp.tar.Z GLISP runs in MCL and has to be modified for other Common Lisp implementations.
CGOL is algol-like language that is translated into Lisp before execution. It was developed originally by Vaughn Pratt. A Common Lisp implementation of CGOL is available by anonymous ftp from peoplesparc.berkeley.edu:/pub/cgol.1.tar.Z [128.32.131.14] (The number "1" may increase if newer versions are posted.) It was written by a UC Berkeley graduate student, Tom Phelps, as a term project, so there may still be some rough edges. There is a lot of documentation in the distribution, including the "original" CGOL memo (pratt.memo). For more information, contact Richard Fateman <fateman@peoplesparc.berkeley.edu>.
StarLisp Simulator. The StarLisp Simulator simulates *Lisp, one of the programming langauges used to program the Connection Machine. StarLisp runs under Symbolics, Lucid, Allegro, and Franz, and is available by anonymous ftp from think.com:/cm/starlisp/starsim-f19-sharfile The "CM5 *Lisp Tutorial" is available by anonymous ftp from arp.anu.edu.au:/ARP/papers/starlisp/ [150.203.20.2] in Andrew "ez" and postscript formats. Write to Zdzislaw Meglicki <Zdzislaw.Meglicki@cisr.anu.edu.au> for more information about the tutorial.
InterLisp->Common-Lisp Translator — ftp.ai.sri.com:/pub/pkarp/lisp/ilisp/ Other InterLisp to Common Lisp translators may be found in the LispUsers archive listed above.
The Yale Haskell system runs in CMU Common Lisp, Lucid CL, and AKCL. It is available by anonymous ftp from Chalmers animal.cs.chalmers.se:/pub/haskell/yale/ [129.16.225.66] Glasgow ftp.dcs.glasgow.ac.uk:/pub/haskell/yale/ [130.209.240.50] Yale nebula.cs.yale.edu:/pub/haskell/yale/ [128.36.13.1] as the files haskell-beta-2-source.tar.Z — full sources haskell-beta-2-sparc.tar.Z — sparc executable
Lisp Tools:
See the Common Lisp Repository in [6-2].
The Automatic Memoization Facility adds a practical memoization facility to Common Lisp. Automatic memoization is a technique by which an existing function can be transformed into one that "remembers" previous arguments and their associated results, yielding large performance gains for certain types of applications. This facility extends the ideas from Norvig's book into what is needed for a practical tool for us in large programs. It adds facilities for bookkeeping and timing, and lets you evaluate of the timing advantages of memoization, and save hash tables to disk for automatic reuse in later sessions. The code is available by anonymous ftp from archive.cs.umbc.edu:/pub/Memoization [130.85.100.53]. Contact Marty Hall <hall@aplcenmp.apl.jhu.edu> for more information. The code includes an overview of memoization and its applications.
PLisp - A Common Lisp front end to Postscript. This translates many Common Lisp functions to postscript as well as manage the environment and many lispisms (&optional and &rest arguments, multiple values, macros, ...). Available via anonymous ftp nebula.cs.yale.edu:/pub/plisp/plisp.tar.Z [128.36.13.1] Written by John Peterson <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 ftp.ai.sri.com:/pub/pkarp/regexp/. Contact pkarp@ai.sri.com for more information.
ifi.informatik.uni-stuttgart.de:/pub/xit/cl-utilities/ contains three small utilities: completion.lisp A simple filename completion program. cl-utilities.lisp Some macros for dealing with points, regions, and some miscellaneous macros. copy-objects.lisp Code for copying instances.
think.com:/think/lisp contains some useful lisp code (most of it Symbolics dependent) including: lisp-lint.lisp A set of compiler style checkers that warn when a function call does not conform to Common Lisp.
MEASURES is a system to handle engineering numbers and measures in Common Lisp. It runs in Allegro CL, LispWorks, MCL, and Symbolics CL. Written by Roman Cunis. Some documentation can be found in the file measures.doc and examples in measures-example.lisp. It is available from the Common Lisp Repository ftp.cs.cmu.edu:/user/ai/lang/lisp/lisp/syntax/ in the file measures-2.0.tar.gz. For further information, contact Ralf Moeller, University of Hamburg, Bodenstedtstr 16, 2000 Hamburg 50, Germany, call 40-4123-6134, fax 40-4123-6530, or send email to moeller@informatik.uni-hamburg.de.
DEFTABLE provides a macro that unifies the interface to Common Lisp's table-like data structures (e.g., association lists, property lists, and hash tables). Written by Peter Norvig <norvig@harlequin.com>. It is available by anonymous ftp from ftp.ai.mit.edu:/pub/lptrs/deftable.lisp [128.52.32.6] and also the Lisp Utilities Repository. An article describing deftable was published in ACM Lisp Pointers 5(4):32-38, December 1992.
SEQUEL (SEQUEnt processing Language) is designed both as a general purpose AI language for generating type-secure and efficient Lisp programs and as a very high level specification language for implementing logics on the computer. Designed at the University of Leeds, SEQUEL compiles sequent-calculus specifications of arbitrary logics to working proof assistants. The sequent calculus specifications are compiled into Horn clauses and from Horn clauses into virtual machine instructions of an abstract machine SLAM (SequeL Abstract Machine) which then translates these instructions into efficient Lisp code using WAM-style compilation techniques. Although a functional programming language, SEQUEL includes facilities for backtracking usually associated with logic programming, and supports a pattern-matching method of building functions based on Prolog notation. The Lisp code generated from SEQUEL functions is completely portable and runs in most Common Lisp implementations. It is comparable in efficiency with hand-written code. SEQUEL also supports optional static type-checking in the manner of SML and similar languages. With type-checking enabled, all inputs and loaded files are type-checked and the resulting Lisp programs are type-secure. The SEQUEL compiler uses the information gleaned from type-checking to add compiler directives within the generated Lisp functions to produce optimized Lisp programs. SEQUEL includes a UNIX-style top level with its own trace package and type-checking debugger. SEQUEL is also of interest to automated reasoning researchers. It provides a very powerful means of generating proof assistants and theorem provers that have a very fast performance using WAM-derived compilation techniques. The theorem provers are automatically verified. It includes a facility for Datalog and an efficient occurs-check Horn-clause-to-Lisp compiler, a mouse driven graphical interface for all proof assistants and theorem provers built under SEQUEL (currently available only under Lucid). Several demonstration theorem provers for different logics, including FOL, Clarke's logic of space, partial evaluation, set theory, and constructive type theory are available. SEQUEL runs under Kyoto CL, Lucid CL, and CMU Common Lisp. SEQUEL is available free for non-commercial purposes by anonymous ftp from agora.leeds.ac.uk:/scs/logic/ [129.11.144.130] and includes LaTeX documentation in the distribution. For more information, contact Mark Tarver <mark@scs.leeds.ac.uk> or <csc6mt@gps.leeds.ac.uk>.
ILU (Xerox PARC Inter-Language Unification) is a system for promoting language interoperability via interfaces between units of program structure called "modules". ILU currently supports Common Lisp, ANSI C, C++, and Modula-3. The Common Lisp support provides CLOS `network objects' that communicate via RPC between Lisp processes, as well between Lisp and other languages. ILU is available by anonymous ftp from parcftp.parc.xerox.com:/pub/ilu/1.6.4/ilu-1.6.4.tar.gz Write to Bill Janssen <janssen@parc.xerox.com> for more information.
Machine Learning:
ID3: A Lisp implementation of ID3 and other machine learning algorithms are available by anonymous ftp from the machine learning group at the University of Texas as cs.utexas.edu:/pub/mooney
COBWEB/3 is a concept formation system available free after signing a license agreement. Contact cobweb@ptolemy.arc.nasa.gov for more information.
RWM (Refinement With Macros) is a Common Lisp program for learning problem solving strategies. RWM takes a high level description of a problem as input and successively refines it into a sequence of "easier" subproblems, which collectively constitute a strategy for solving the given problem. RWM also learns macro moves which are useful for efficiently solving the problem. A short documentation and some example problems/strategies are included. To get a copy of this description, send mail to the Bilkent University Archieve Server bilserv@trbilun.bitnet with "send RWM.tar.Z" in the body of the message. For further information, contact H. Altay Guvenir <guvenir@trbilun.bitnet>.
Mathematics:
MockMma — peoplesparc.berkeley.edu:/pub/mma.tar.Z [128.32.131.14] A Mathematica-style parser written in Common Lisp. Written by Richard Fateman; fateman@renoir.Berkeley.EDU. Runs in any valid Common Lisp. Tested in Allegro, KCL and Lucid.
rascal.ics.utexas.edu:/pub/ 128.83.138.20 Maxima for Common Lisp (License required from National Energy Software Center at Argonne.) Ported by Bill Schelter.
QUAIL (Quantitative Analysis in Lisp) extends Common Lisp to better support quantitative analysis. It includes an object-oriented quantitative analysis programming environment based on CLOS. Quail was developed by the Statistical Computing Laboratory of the Department of Statistics and Actuarial Science of the University of Waterloo. It includes a variety of mathematical and statistical capabilities, such as symbolic and numerical differentiation, numerical integration, probability calculations (e.g., pseudo-random number generation), and statistical response models. The object-oriented graphics display facilities include building blocks for arbitrary graphics, a collection of stock statistical graphics, function plotting, 3d-rotating function and surface plots, and graphical browsers. Quail currently runs in MCL, but a Franz and CLX based version is forthcoming. It is available by anonymous ftp from setosa.uwaterloo.ca:/pub/Quail/ [129.97.141.101] You must read the file README-I-MEAN-IT and return a signed copy of the license agreement ($10 annual license fee) before using the software. For further information, contact Dr. R. W. Oldford, <rwoldford@watstat.waterloo.edu> or <rwoldford@watstat.uwaterloo.ca>.
Medical Reasoning:
TMYCIN — sumex-aim.stanford.edu:/tmycin The TMYCIN rule based system.
Music:
Common Music is a music composition language written in Common Lisp and CLOS that outputs music (directly or through scorefiles) to a variety of synthesis packages, such as the Music Kit, Common Lisp Music, MIDI, and CSound. Common Music runs under MCL 2.0, Allegro CL 3.1.2 (NeXT), AKCL 1.615 (NeXT), Allegro CL 4.1 beta (SGI Iris), and AKCL 6.15 (Sun4). It is available by anonymous ftp from ccrma-ftp.stanford.edu:/pub/Lisp/cm.tar.Z [36.49.0.93] ftp.zkm.de:/pub/cm.tar.Z [192.101.28.17] To be added to the mailing list, send mail to cmdist-request@ccrma.stanford.edu. For further information, contact Rick Taube, <hkt@zkm.de> or <hkt@ccrma.stanford.edu>. [Note: In the Common Music sources, there is a generic portable Lisp Listener style interpreter that supports command dispatching in addition to Lisp evaluation. It is the file ./utils/tl.lisp.]
Common Lisp Music (CLM) is a software synthesis and signal processing package (CL-MUSIC) and a package that makes it relatively easy to take advantage of the Motorola DSP 56000 (CL-MUSIC-56). It is available by anonymous ftp from ccrma-ftp.stanford.edu:/pub/Lisp/clm.tar.Z [36.49.0.93] Basic documentation is in clm.wn (or clm.rtf) and ins.lisp. CLM runs on NeXT under Allegro CL or KCL and on SGI Indigo under Allegro CL. The non-56000 version should run on any machine with C and Common Lisp. Send bug reports or suggestions to Bil Schottstaedt <bil@ccrma.stanford.edu>.
Common Music Notation (CMN) is a western music notation package based on Common Lisp, CLOS (pcl), PostScript, and the Adobe Sonata font. It is available by anonymous ftp from ccrma-ftp.stanford.edu:/pub/Lisp/cmn.tar.Z [36.49.0.93] To be added to the mailing list (same list as for Common Music), send mail to cmdist-request@ccrma.stanford.edu. Please send bug reports and suggestions to Bil Schottstaedt <bil@ccrma.stanford.edu>.
Natural Language Processing:
The Xerox part-of-speech tagger is available by anonymous ftp from parcftp.xerox.com:/pub/tagger/tagger-1-0.tar.Z. It is implemented in Common Lisp and has been tested in Allegro CL 4.1, CMU CL 17e, and Macintosh CL 2.0p2. For more information, contact the authors, Jan Pedersen <pedersen@parc.xerox.com> and Doug Cutting <cutting@apple.com>.
Natural Language Generation:
FUF is a natural language generation system based on Functional Unification Grammars implemented in Common Lisp. It includes a unifier, a large grammar of English (surge), a user manual and many examples. FUF is available by anonymous ftp from cs.columbia.edu:/pub/fuf/ black.bgu.ac.il:/pub/fuf/ as the files fuf5.2.tar.Z and surge.tar.Z. For further information, contact the author, Michael Elhadad <elhadad@bengus.bgu.ac.il>. [A WAM-based C compiler for FUF is in the works.]
Neural Networks:
ANSIL — nervous.cis.ohio-state.edu:/pub/lispusers/ansil/ "Advanced Network Simulator in Lisp" email: ansil@cis.ohio-state.edu
Object-Oriented Programming:
PCL — parcftp.xerox.com:/pcl/ [13.1.64.94] Portable Common Loops (PCL) is a portable implementation of the Common Lisp Object System (CLOS). A miniature CLOS implementation called Closette is available pcl/mop/closette.lisp.
CLOS-on-KEE — zaphod.lanl.gov:/pub/ A subset of CLOS that is implemented on top of KEE. Contact egdorf%zaphod@LANL.GOV (Skip Egdorf) for more info.
MCS (Meta Class System) — ftp.gmd.de:/lang/lisp/mcs/ [129.26.8.84] Portable object-oriented extension to Common Lisp. Integrates the functionality of CLOS (the Common Lisp Object System), and TELOS, (the object system of LeLisp Version 16 and EuLisp). MCS provides a metaobject protocol which the user can specialize. Runs in any valid Common Lisp. Contact: Harry Bretthauer and Juergen Kopp, German National Research Center for Computer Science (GMD), AI Research Division, P.O. Box 1316, D-5205 Sankt Augustin 1, FRG, email: juergen.kopp@gmd.de
CommonORBIT (also called CORBIT) is an object-oriented extension of Common Lisp. It uses a prototype (classless) model of OOP, is easy to use and yet has many sophisticated features found also in KL-ONE type languages. CommonORBIT is a Common Lisp reimplementation of ORBIT, which was originally conceived by Luc Steels around 1981-1983. Because of its delegation-based rather than class-based inheritance, CommonORBIT offers extreme flexibility to define and change practically anything at run-time. Because of the generic functions, it fits well into regular Lisp code. It can co-exist with CLOS but remains completely separate. The source code of CommonORBIT is in the public domain and available by anonymous ftp from the Lisp Utilities Repository, ftp.cs.cmu.edu:/user/ai/lang/lisp/ in the oop/non-clos/corbit/ subdirectory as the file corbit.tar.gz. Documentation is available as the files corbit.msword.hqx, corbit.ps or corbit.text. A stripped-down version of CORBIT, known as BOOPS (Beginner's Object-Oriented Programming System), is also available from the repository as boops.tar.Z. For further information, contact the author, Koenraad de Smedt <desmedt@ruls40.LeidenUniv.nl>.
Parser Generators:
Mark Johnson <mj@cs.brown.edu> has written a LALR parser generator for Common Lisp. It is fairly small (about 500 lines of code) and can be found in the Common Lisp Repository above.
IPG (Incremental Parser Generator) is available by email from Jan Rekers <rekers@cwi.nl>. It is an appendix to his thesis. It is written in LeLisp, but should be portable to other Lisp dialects.
Zebu 2.8.5 is a parser generator for Common Lisp by Joachim H. Laubsch <laubsch@hplabs.hpl.hp.com>. It is an extention written in Common Lisp of the Scheme version. It generates a LALR(1) parsing table. To parse a string with a grammar, only this table and a driver need to be loaded. The present version of Zebu contains the ability to define several grammars and parsers simultaneously, a declarative framework for specifying the semantics, as well as efficiency related improvements. The current version compiles a grammar with 300 productions (including dumping of the tables to disk) in approx 2 minutes and 30 seconds on a HP 9000/370. This implimentation has been tested in Lucid CL, Allegro CL, and MCL 2.0b. The current version can also produce a generator in addition to a parser. A copy may be found on cambridge.apple.com:/pub/mcl2/contrib/zebu-2.2.tar.Z.
Probabilistic Reasoning and Statistics:
BELIEF is a Common Lisp implementation of the Dempster and Kong fusion and propagation algorithm for Graphical Belief Function Models and the Lauritzen and Spiegelhalter algorithm for Graphical Probabilistic Models. It includes code for manipulating graphical belief models such as Bayes Nets and Relevance Diagrams (a subset of Influence Diagrams) using both belief functions and probabilities as basic representations of uncertainty. It is available by anonymous ftp from ftp.stat.washington.edu [128.95.17.34] and by email from the author, Russell Almond <almond@stat.washington.edu>. Contact the author at almond@statsci.com for information about a commercial version GRAPHICAL-BELIEF currently in the prototype stages.
XLISP-STAT is an extensible statistics package which runs in XLISP. It has recently been ported to Common Lisp, and is available as umnstat.stat.umn.edu:/pub/xlispstat/CL/CLS1.0A1.tar.Z [128.101.51.1] The CL port does not yet include the lisp-stat dynamic graphics package, only the numerics. The XLisp version is available from the above site and several mirror sites, such as mac.archive.umich.edu, and runs on the Apple Macintosh, Unix systems running X11 (Vax, PMAX, Sun3, Encore Multimax, and Cray XMP), Sun workstations running SunView, and the Commodore Amiga. An experimental version for DOS computers running Microsoft Windows 3.0 is also available. Documentation is available online, in the tutorial introduction pub/xlispstat/xlispstat.doc.tar.Z and also in the book Luke Tierney, "Lisp-Stat: An Object Oriented Environment for Statistical Computing and Dynamic Graphics", Wiley, 1990, 397 pages. ISBN 0-471-50916-7. For more information, write to Lisp-Stat Information, School of Statistics, 270 Vincent Hall, University of Minnesota, Minneapolis, MN 55455, or send e-mail to lispstat-info@umnstat.stat.umn.edu.
CLASP (Common Lisp Analytical Statistics Package) provides the basic functionality of a statistics package. It is implemented on top of CLOS and CLIM on a variety of platforms, and uses BBN's SciGraph package for plotting. The CLIM interface includes a "notebook" that is both a "desktop" for icons and a Lisp interactor pane. The Common Lisp Instrumentation Package (CLIP) is available along with CLASP. CLIP is designed to allow AI system developers andevaluators a portable way to define and manage "alligator clips" for instrumenting their programs. CLIP produces data about program behavior in CLASP format, as well as other commonly used data formats. It currently has facilities to support experiment design, such as scenario scripting and factorial combination of independent variables, and can collect data in summary form (at the end of each trial) or based upon the occurrence of specific events (both periodic and non-periodic). CLASP is available by anonymous ftp from ftp.cs.umass.edu:/pub/eksl/clasp/ and CLIP is in the directory ftp.cs.umass.edu:/pub/eksl/clip/ A tutorial on CLASP can be found in ftp.cs.umass.edu:/pub/eksl/clasp-tutorial/ Bugs should be reported to clasp-support@cs.umass.edu. For more information, contact Dave Hart <dhart@cs.umass.edu>.
IDEAL is a LISP system developed for building and evaluating influence diagrams and Bayesian networks. It is accompanied with a graphical user interface (CLIM-based) for constructing, editing, and solving belief networks and influence diagrams. For more information, write to srinivas@rpal.rockwell.com.
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.
ABTWEAK is a complete hierarchical, non-linear planner that extends David Chapman's (MIT 1986) TWEAK planner as described by Yang (Waterloo) and Tenenberg (Rochester) in 1989. This implementation includes a complete search strategy suited to abstraction hierarchies known as LEFT-WEDGE (Woods 1991). This planner and related work predates that of SNLP. ABTWEAK is available by anonymous ftp from logos.uwaterloo.ca:/pub/abtweak/Abtweak.tar.Z For more information, send mail to Qiang Yang <qyang@logos.uwaterloo.ca>. Also, source, all related papers, and manuals are available via WWW at the home page of Steve Woods <sgwoods@logos.uwaterloo.ca>, on URL http://logos.uwaterloo.ca/students/sgwoods/sgwoods.html, or via the Logic Programming and Artificial Intelligence Group (LPAIG) page on URL http://logos.uwaterloo.ca/.
RHETORICAL is a planning and knowledge tool available by anonymous ftp from ftp.cs.rochester.edu:/pub/packages/knowledge-tools in the files rhet-19-40.tar.Z and cl-lib-3-11.tar.Z. The files tempos-3-6.tar.Z and timelogic-5-0.tar.Z add James Allen's interval logic to Rhet. It runs on Symbolics Genera and Allegro Common Lisp. Written by Brad Miller <miller@cs.rochester.edu>.
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.
A simple route planning agent implemented in Soar6 is available by anonymous ftp from earth.med.ohio-state.edu:/pub/IEEE-Soar-code/route-planning.soar6. This is the complete code for the agent described in the IEEE Expert article: Smith, J. W. and Johnson, T. R., "A stratified approach to specifying, designing, and building knowledge systems", IEEE Expert, 8(3):15-25, 1993.
SNLP is a domain independent systematic nonlinear planner, available by anonymous ftp from cs.washington.edu:/pub/snlp.tar.Z Contact weld@cs.washington.edu 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.
Planning Testbeds:
TILEWORLD is a planning testbed/simulator developed at SRI International by Martha Pollack, Michael Frank and Marc Ringuette. TILEWORLD originally ran under Lucid CL, but was later extended and ported to Allegro CL by Badr H. Al-Badr and Steve Hanks. The new tileworld is available by anonymous ftp from cs.washington.edu as the file new-tileworld.tar.Z It includes an X interface. Contact 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 with arms that roams around the simulated world. It is available by anonymous ftp from cs.washington.edu:/pub/ai/truckworld.tar.Z It includes an X interface. Contact Steve Hanks <hanks@cs.washington.edu> for more information. Send mail to truckworld-users-request@cs.washington.edu to be added to the mailing list.
ARS MAGNA is a simulated world intended for use as a testbed for planning and mapping programs. The simulated agent is a robot in an indoors environment. High-level sensing and action are provided, realistically modelled on current vision and robotics research. It is written in Nisp, a macro package running on top of Common Lisp. It is available by anonymous ftp from dept.cs.yale.edu:/pub/nisp/ as file ars-magna.tar.Z. It includes an X display. Contact Sean Engelson <engelson@cs.yale.edu> for more information.
Qualitative Reasoning:
QSIM is a qualitative reasoning system implemented in Common Lisp. It is available by anonymous ftp from cs.utexas.edu:/pub/qsim Contact Ben Kuipers <kuipers@cs.utexas.edu> for more information.
QPE is the Qualitative Process Engine, an envisioner for QP theory. QPE is publically available from multivac.ils.nwu.edu:/pub/QPE Maintained by Ken Forbus <forbus@ils.nwu.edu>.
Theorem Proving:
MVL (Multi-Valued Logic) is a theorem proving system written in Common Lisp. MVL is a bilattice-based reasoning system. By changing the bilattice, you can use MVL to do truth maintenance, nonmonotonic reasoning, first-order reasoning, and a variety of other reasoning strategies. MVL is available by anonymous ftp from t.uoregon.edu:/mvl/mvl.tar.Z [128.223.56.46] as mvl.tar.Z. A user's manual may be found in the file manual.tex. For more information, contact Matthew L. Ginsberg, <ginsberg@t.stanford.edu> or <ginsberg@cs.stanford.edu>. Matthew asks that you send him an email message if you retrieve the system by anonymous ftp.
Boyer-Moore ftp.cli.com:/pub/nqthm/nqthm.tar.Z Contact: kaufman@cli.com rascal.ics.utexas.edu:/pub/ 128.83.138.20 nqthm/ Boyer and Moore's theorem prover. Also available from ftp.cli.com:/pub/nqthm. proof-checker/ Matt Kaufmann's proof checking enhancements to nqthm. The mailing list nqthm-users-request@cli.com is for users of the Boyer-Moore theorem-prover, NQTHM.
DTP is a general first-order theorem prover incorporating intelligent backtracking and subgoal caching, as well as a trace facility that can display proof spaces graphically. Implemented in CLtL2 Common Lisp, it runs in Franz Allegro, Lucid, and Macintosh (MCL) Common Lisp. DTP is available on the Web at http://logic.stanford.edu/dtp/ or by anonymous ftp from meta.stanford.edu:/pub/dtp/ [36.8.0.54] Contact Don Geddis <Geddis@CS.Stanford.EDU> for more information.
RRL (Rewrite Rule Laboratory) — herky.cs.uiowa.edu:/public/rrl [128.255.28.100]
FRAPPS (Framework for Resolution-based Automated Proof Procedures) is a portable resolution theorem-prover written in Common Lisp. It is available via anonymous ftp from a.cs.uiuc.edu:/pub/frapps [128.174.252.1]. If you take a copy of FRAPPS, please send a short note to Prof. Alan M. Frisch <frisch@cs.uiuc.edu>.
Truth Maintenance:
The truth maintenance system and problem solver implementations described in the book "Building Problem Solvers" by Ken Forbus and Johan de Kleer are available by anonymous ftp from parcftp.xerox.com:/pub/bps/. Includes a constraint propagation system similar to Steele's Constraints system, among other things. For more information send mail to Johan de Kleer <deKleer@parc.xerox.com>.
Virtual Reality:
VEOS (Virtual Environment Operating Shell) is an extendible environment for prototyping distributed applications for Unix. The programmer's interface uses XLISP 2.1. Although intended for distributed Virtual Reality applications at The Human Interface Technology Lab in Seattle, it should be appropriate for other applications. VEOS uses heavyweight sequential processes, corresponding roughly to unix processes. VEOS runs on DEC/5000, Sun4, and Silicon Graphics VGX and Indigo. VEOS is available by anonymous ftp from milton.u.washington.edu:/public/veos/ [128.95.136.1] as veos.tar.Z. If you use the software, the authors ask that you send them mail to veos-support@hitl.washington.edu.
Vision:
OBVIUS — white.stanford.edu:/obvius/ [36.121.0.16] whitechapel.media.mit.edu:/obvius/ [18.85.0.125] Object-Based Vision and Image Understanding System (OBVIUS), is a Common Lisp image processing package. Provides a library of image processing routines (e.g., convolutions, fourier transforms, statistical computations, etc.) on gray or binary images and image-sequences (no color support yet), an X windows display interface, postscript printer output, etc. It uses a homebrew interface to X11 (i.e., it does not use clx or clue). However, they eventually hope to port Obvius to a clx/clue platform. Written by David Heeger <heeger@white.stanford.edu> and Eero Simoncelli <eero@central.cis.upenn.edu>. Runs in Lucid-4.0. Includes LaTeX documentation and User's Guide.
Miscellaneous:
ftp.csrl.aoyama.ac.jp:/YY/ YY window toolkit sources ftp.csrl.aoyama.ac.jp:/lispsrc/ Common Lisp programs, including MIT's FRL.
SLaTeX is a R4RS-compliant Scheme program that allows you to write program code "as is" in your LaTeX or TeX source. It is particularly geared to the programming languages Scheme and Common Lisp, and has been tested in Chez Scheme, Common Lisp, MIT C Scheme, Elk, Scheme->C, SCM and UMB Scheme on Unix; and MIT C Scheme and SCM on MSDOS. The formatting of the code includes assigning appropriate fonts to the various tokens in the code (keywords, variables, constants, data), at the same time retaining the proper indentation when going to the non-monospace (non-typewriter) provided by TeX. SLaTeX comes with two databases that recognize the standard keywords/variables/constants of Scheme and Common Lisp respectively. These can be modified by the user using easy TeX commands. In addition, the user can inform SLaTeX to typeset arbitrary identifiers as specially suited TeX expressions (i.e., beyond just fonting them). The code-typesetting program SLaTeX is available by anonymous ftp from cs.rice.edu:/public/dorai/slatex23.tar.gz Send bug reports to dorai@cs.rice.edu.
SchemeWEB provides simple support for literate programming in Lisp. SchemeWEB version 2.0 is a Unix filter that allows you to generate both Lisp and LaTeX code from one source file. The generated LaTeX code formats Lisp programs in typewriter font obeying the spacing in the source file. Comments can include arbitrary LaTeX commands. SchemeWEB was originally developed for the Scheme dialect of Lisp, but it can easily be used with most other dialects. Version 2.0 is available in the Scheme Repository as cs.indiana.edu:/pub/scheme-repository/new/schemeweb.sh or in the Comprehensive TeX Archive Network (CTAN) in the directory ftp.shsu.edu:/tex-archive/web/schemeweb
LiSP2TeX is a system that allows easy insertions of Scheme, or Lisp, code towards TeX files. The originality of LiSP2TeX is that it extracts Scheme definitions from the files where they appear and wraps them appropriately within TeX macros for insertion into the documentation file. LiSP2TeX decorrelates writing documentation from programming: it is therefore possible to separately develop programs and documentations and to merge them at the end to produce up to date final documents. LiSP2TeX also has some pretty-printing capabilities to produce denotations full of greek letters. It is available by anonymous ftp from ftp.inria.fr:/INRIA/Projects/icsla/.
See also ftp.cs.cmu.edu:/user/ai/lang/lisp/code/tools/user_man/.
The Literate Programming FAQ lists a number of alternatives, both language-independent and Lisp-specific. The Literate Programming FAQ is posted once a quarter to the comp.literate.programming newsgroup and is available by anonymous ftp from rtfm.mit.edu. A copy may also be requested by sending an email message to fileserv@shsu.edu sendme litprog.faq in the body of the message.
Implementations of Prolog in Lisp:
The Frolic package from the University of Utah is written in Common Lisp and available by anonymous ftp from cs.utah.edu:/pub/frolic.tar.Z
LM-PROLOG by Ken Kahn and Mats Carlsson is written in ZetaLisp and not easily portable to Common Lisp. It is available by anonymous ftp from sics.se:/archive/lm-prolog.tar.Z.
Peter Norvig's book "Paradigms of AI Programming" includes Common Lisp implementations of a prolog interpreter and compiler. The software is available by anonymous ftp from unix.sri.com:/pub/norvig/ and on disk in Macintosh or DOS format from the publisher, Morgan Kaufmann. For more information, contact: Morgan Kaufmann, Dept. P1, 2929 Campus Drive, Suite 260, San Mateo CA 94403, (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).
eLP (Ergo Lambda Prolog) is an interpreter written by Conal Elliott, Frank Pfenning and Dale Miller in Common Lisp and implements the core of lambda Prolog (higher-order hereditary Harrop formulas). It is embedded in a larger development environment called ESS (the Ergo Support System). eLP implements all core language feature and offers a module system, I/O, some facilities for tracing, error handling, arithmetic, recursive top-levels, on-line documentation and a number of extended examples, including many programs from Amy Felty's and John Hannan's thesis. It should run in Allegro Common Lisp, Lucid Common Lisp, Kyoto Common Lisp, CMU Common Lisp and Ibuki Common Lisp. The eLP implementation of lambda Prolog is no longer developed or maintained, but it is still available via anonymous ftp from ftp.cs.cmu.edu:/afs/cs.cmu.edu/project/ergo/export/ess/. The file ergolisp.tar.Z contains the Ergo project's extensions to Common Lisp, including some facilities for attributes and dealing with abstract syntax trees. The file sb.tar.Z contains the Ergo Parser/Unparser/Formatter generator and ab.tar.Z contains the Ergo Attribute Grammar facility. The file elp.tar.Z contains the Ergo implementation of lambda Prolog. To customize grammars you need the sb.tar.Z file. When you retrieve the system, please print, fill out, and send in a copy of the non-restrictive license you will find in the file LICENSE. To subscribe to the elp@cs.cmu.edu mailing list, send mail to elp-request@cs.cmu.edu. Bugs should be sent to elp-bugs@cs.cmu.edu.
The book "On Lisp" by Paul Graham includes an implementation of Prolog in Common Lisp. The code is available by anonymous ftp from endor.harvard.edu:/pub/onlisp and also in the CMU AI Repository as ftp.cs.cmu.edu:/user/ai/lang/lisp/bookcode/graham/
See the Scheme FAQ for information on implementations of Prolog in Scheme.
The World Wide Web (WWW) is a hypermedia document that spans the Internet. It uses the http (HyperText Transfer Protocol) for the light-weight exchange of files over the Internet. NCSA Mosaic is a World Wide Web browser developed at the National Center for Supercomputing Applications (NCSA).
Mosaic's popularity derives, in part, from its ability to communicate using more traditional Internet protocols like FTP, Gopher, WAIS, and NNTP, in addition to http. Mosaic can display text, hypertext links, and inlined graphics directly. When Mosaic encounters a file type it can't handle internally, such as Postscript documents, mpeg movies, sound files, and JPEG images, it uses an external viewer (or player) like Ghostscript to handle the file. Mosaic also includes facilities for exploring the Internet. In other words, Mosaic is an multimedia interface to the Internet.
The hypertext documents viewed with Mosaic are written in HTML (HyperText Markup Language), which is a subset of SGML (Standard Generalized Markup Language). All that is needed is just a few more improvements, such as the ability to format tables and mathematics, and a WYSIWYG editor, for HTML to greatly facilitate electronic journals and other publications.
NCSA Mosaic for the X Window System is available by anonymous ftp from ftp.ncsa.uiuc.edu:/Mosaic/ as source code and binaries for Sun, SGI, IBM RS/6000, DEC Alpha OSF/1, DEC Ultrix, and HP-UX. Questions about NCSA Mosaic should be directed to mosaic-x@ncsa.uiuc.edu (X-Windows version), mosaic-mac@ncsa.uiuc.edu (Macintosh), and mosaic-win@ncsa.uiuc.edu (Microsoft Windows).
A simple HTML version of the Lisp FAQ (this FAQ) is available as http://www.cs.cmu.edu/Web/Groups/AI/html/faqs/lang/lisp/top.html
Association of Lisp Users: http://www.cs.rochester.edu/u/miller/alu.html [Contains links to a lot of Lisp resources, including a history of Lisp, bibliographies of Lisp books, the Lisp Repository at CMU, and even some Lisp humor. Very nicely done.] Contact: Brad Miller <miller@cs.rochester.edu>
There are several GUI's and Lisp interfaces to the X Window System. Mailing lists for these systems are listed in the answer to question [4-7]. Various vendors also offer their own interface-building packages.
CLX provides basic Common Lisp/X functionality. It is a de facto standard low-level interface to X, providing equivalent functionality to XLib, but in Lisp. It is also a good source for comparing the foreign function calls in various Lisps. Does *not* depend on CLOS. Available free as part of the X release in the contrib directory. Also available by anonymous ftp from ftp.x.org:/R5contrib/ as the files CLX.Manual.tar.Z and CLX.R5.02.tar.Z. [Note: The new version of CLX for X11R6 can be found (untarred) in ftp.x.org:/pub/R6.1/contrib/lib/CLX/ with documentation in ftp.x.org:/pub/R6.1/contrib/doc/CLX/ and includes some slight modifications for CLtL2 compatability. You can get it in tarred form from the CMU AI Repository, Lisp section.] Primary Interface Author: Robert W. Scheifler <rws@zermatt.lcs.mit.edu> Send bug reports to bug-clx@expo.lcs.mit.edu. The 232 page manual is available in /pub/R5untarred/mit/hardcopy/CLX (PostScript format) and /pub/R5untarred/mit/doc/CLX (Interleaf source).
CLIM (Common Lisp Interface Manager) is a portable, graphical user interface toolkit originally developed by International Lisp Associates, Symbolics, and Xerox PARC, and now under joint development by several Lisp vendors, including Symbolics, Franz, Lucid, Illudium, and Harlequin. It is intended to be a portable successor of Symbolics UIMS (Dynamic Windows, Presentations Types). CLIM 2.0 also supports more traditional toolkit-style programming. It runs on Symbolics Lisp Machines; Allegro, Lucid, and Harlequin on several Unix platforms; Symbolics CLOE on 386/486 IBM PCs running Windows; and MCL on Apple Macintoshes. It is *not* free, and with the exception of Macintoshes, if it is available it can be purchased from the vendor of the Lisp system you are using. For the Macintosh version write to Illudium: Contact: Dennis Doughty - Doughty@ileaf.com or contact: Bill York - york@parc.xerox.com Illidium has signed a distribution agreement for MCL CLIM with Lucid. [Contact Harlequin for information about Lucid.] CLIM includes a general purpose grapher. The CLIM 2.0 SPECIFICATION is available by anonymous ftp from ftp.franz.com:/pub/clim/clim.ps.Z. To be added to the mailing list send mail to clim-request@bbn.com.
CLUE (Common Lisp User-Interface Environment) is from TI, and extends CLX to provide a simple, object-oriented toolkit (like Xt) library that uses CLOS. Provides basic window classes, some stream I/O facilities, and a few other utilities. Still pretty low level (it's a toolkit, not widget library). Available free by anonymous ftp from csc.ti.com:/pub/clue.tar.Z Written by Kerry Kimbrough. Send bug reports to 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. [Intellicorp's KEE4.0 comes with Common Windows also. They've implemented the CW spec to run on Lucid 4.0 on Sparcs, HP300/400s, HP700/800s, and IBM RS6000s. Contact tait@intellicorp.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, CMU CL, Lucid CL, and Symbolics Genera. GINA uses CLOS. Available free in the X contrib directory or by anonymous ftp from either ftp.x.org:/contrib (formerly export.lcs.mit.edu) or ftp.gmd.de:/gmd/gina [129.26.8.84] as the files CLM+GINA.README, CLM2.2.tar.Z and GINA2.2.tar.Z. CLM was written by Andreas Baecker <baecker@gmd.de>, GINA by Mike Spenke <spenke@gmd.de>, and IB by Thomas Berlage <berlage@gmd.de>. Contact Mike Spenke for more info. To be added to the mailing list, send a message to gina-users-request@gmd.de.
EW (Express Windows) is intended to mimic Symbolics' Dynamic Windows user and programmer interfaces. It is available free in the Common Lisp Repository as ftp.cs.cmu.edu:/user/ai/lang/lisp/gui/ew/ It is no longer under active development. Runs on Sun/Lucid, Franz Allegro, and Symbolics. Should port easily to other Lisps with CLX. Written by Andrew L. Ressler <aressler@oiscola.columbia.ncr.com>.
Garnet is a large and flexible GUI. Lots of high-level features. Does *not* depend on CLOS, but does depend on CLX. Garnet (version 2.0 and after) is now in the public domain, and has no licensing restrictions, so it is available to all foreign sites and for commercial uses. Detailed instructions for obtaining it by anonymous ftp are available by anonymous ftp as a.gp.cs.cmu.edu:/usr/garnet/garnet/README [128.2.242.7] Garnet includes the Lapidiary interactive design tool, C32 constraint editor, spreadsheet object, Gilt Interface Builder, automatic display management, two widget sets (Motif look-and-feel and Garnet look-and-feel), support for gesture recognition, and automatic constraint maintenance, application data layout and PostScript generation. Runs in virtually any Common Lisp environment, including Allegro, Lucid, CMU, and Harlequin Common Lisps on Sun, DEC, HP, Apollo, IBM 6000, and many other machines. Garnet helps implement highly-interactive, graphical, direct manipulation programs for X/11 in Common Lisp. Typical applications include: drawing programs similar to Macintosh MacDraw, user interfaces for expert systems and other AI applications, box and arrow diagram editors, graphical programming languages, game user interfaces, simulation and process monitoring programs, user interface construction tools, CAD/CAM programs, etc. Contact Brad Myers (bam@a.gp.cs.cmu.edu) for more information. Bug reports should be sent to garnet-bugs@cs.cmu.edu. Administrative questions should be sent to garnet@cs.cmu.edu or garnet-request@cs.cmu.edu. Garnet is discussed on the newsgroup comp.windows.garnet (which is gatewayed to garnet-users@cs.cmu.edu for those without access to netnews).
LISP2WISH is a very simple demonstration of how to connect and communicate SYNCHRONOUSLY between a lisp process and a C process running a Tcl/Tk executable. The demo uses the vanilla 'wish' executable that is included with the Tcl/Tk distribution. Tcl/Tk is a very flexible system for building Graphical User Interfaces (GUIs), with the look-and-feel of Motif. One writes scripts in a high-level, C-like language, and an interpreter evaluates the commands and passes execution either to a built-in function (and there are many), or to your own C routines. Tcl/Tk is becoming increasingly popular because of its ease of use, and because it is freely distributable (even commercially, I believe). For more information on Tcl/Tk, look on the USENET newsgroup comp.lang.tcl, or get the distribution from the archive (listed below) or ftp.cs.berkeley.edu. The Tcl/Tk archive also has many user-contributed extensions which make Tcl/Tk even more desirable. Tcl/Tk was originally written by Dr. John Ousterhout, at Berkeley. LISP2WISH lets you make a window/menu/drawing interface for your lisp routines, where you can take advantage of all the stuff written for Tcl/Tk (and build your own!). LISP2WISH has only been tested under X-Windows and Lucid Common Lisp 4.0 and 4.1, but should work on other platforms that support Lucid (or Allegro) and Tcl/Tk. LISP2WISH is available at the Tcl/Tk archive harbor.ecn.purdue.edu:/pub/tcl/lisp2wish6.tar.gz, from the author through the WWW at the URL http://www.cis.upenn.edu/~kaye/home.html by anonymous ftp from ftp.cis.upenn.edu:/pub/kaye/lisp2wish6.tar.Z or in the GUI section of the Lisp Repository as ftp.cs.cmu.edu:/user/ai/lang/lisp/gui/lsp2wish/lsp2wish.tgz For more information, contact Jonathan Kaye <kaye@linc.cis.upenn.edu>.
LispView is a GUI written at Sun that does not use CLX. Instead it converts Xlib.h directly into Lucid foreign function calls. It is intended to be fast and tight. Uses CLOS. Available for anonymous ftp from ftp.x.org:/contrib/lispview1.1 (formerly export.lcs.mit.edu) and xview.ucdavis.edu:/pub/XView/LispView1.1 Includes a general-purpose 2D grapher library. Written by Hans Muller (hmuller@sun.com). Runs in Sun CL and Lucid CL. Direct questions about the source provision to lispview@Eng.Sun.Com.
WINTERP (Widget INTERPreter) is an application development environment developed at HP. It enables the rapid prototyping of graphical user-interfaces through direct manipulation of user interface objects and their attached actions. WINTERP provides an interface to the X11 toolkit (Xt) and the OSF/Motif widget set and a built-in RPC mechanism for inter-application communication. It includes an object-oriented 2.5D graphics and animation widget based on the Xtango path transition animation system, the XmGraph graph browser (with graph nodes as arbitrary WINTERP widgets), and GIF image support. The interpreter is based on David Betz's XLISP interpreter, which implements a small subset of Common Lisp and runs on PCs, IBM RS/6000, Decstation 3100s, HP9000s, Sun3, Sparcs, SGI, and NeXT. XLISP provides a simple Smalltalk-like object system, with OSF/Motif widgets as real XLISP objects — they can be specialized via subclassing, methods added or altered, etc. WINTERP includes an interface to GNU-Emacs which allows code to be developed and tested without leaving the editor. WINTERP is a free-standing Lisp-based tool for setting up window applications. WINTERP is available free in X contrib directory, or by anonymous ftp from ftp.x.org:/contrib/devel_tools/ as winterp-???.tar.gz (formerly export.lcs.mit.edu) where ??? is the version number. The current version is 2.03 (X11r6 support). If you do not have Internet access you may request the source code to be mailed to you by sending a message to winterp-source@netcom.com. The WWW home page for WINTERP is accessible via the URL http://www.eit.com/software/winterp/winterp.html or mirrored on file://ftp.x.org/contrib/devel_tools/winterp.html Contact Niels Mayer <mayer@netcom.com> for more information. To be added to the mailing list, send mail to winterp-request@netcom.com.
Xgcl provides an interface to X Windows for GCL (GNU Common Lisp), formerly Austin Kyoto Common Lisp (AKCL). It includes a low-level interface to the Xlib routines, and an interface that provides graphics, menus, and mouse interaction via functions that are called from Lisp. Xgcl is built on top of GCL, and it is somewhat larger (e.g. 6.7 MB for Xgcl vs. 4.9 MB for GCL) because it incorporates Xlib. To make Xgcl, you must first obtain and make GCL. The code was written by Gordon Novak, Hiep Nguyen, and William Schelter. Xgcl is available by anonymous FTP from math.utexas.edu:/pub/gcl/ ftp.cli.com:/pub/gcl/ ftp.cs.utexas.edu:/pub/novak/xgcl/ and on the Web from http://www.cs.utexas.edu/users/novak as the file xgcl-2.tgz. To use, put the xgcl-2.tgz file in the same directory as gcl-1.1.tgz and uncompress it with gzip -dc xgcl-2.tgz | tar xvf - Then see the README in the directory xgcl-2. For more information, write to Gordon Shaw Novak, Jr. <novak@cs.utexas.edu>.
YYonX is a port of the YY system to X windows. Runs in Lucid CL, Allegro CL, and Symbolics Genera. Supports kanjii. Developed at Aoyama Gakuin University. Available free by anonymous ftp from ftp.csrl.aoyama.ac.jp:/YY/ Written by Masayuki Ida <ida@cc.aoyama.ac.jp>
Picasso is a CLOS based GUI, and is available from postgres.berkeley.edu:/pub/Picasso-2.0 toe.cs.berkeley.edu:/pub/picasso/ It runs on DecStation 3100s, Sun3 (SunOs), Sun4 (Sparc), and Sequent Symmetry in Allegro CL. The file pub/xcl.tar.Z contains X-Common Lisp interface routines. Send mail to picasso@postgres.berkeley.edu for more information. [Picasso is no longer an actively supported system.]
XIT (X User Interface Toolkit) is an object-oriented user interface development environment for the X Window System based on Common Lisp, CLOS, CLX, and CLUE. It has been developed by the Research Group DRUID at the Department of Computer Science of the University of Stuttgart (druid@informatik.uni-stuttgart.de) as a framework for Common Lisp/CLOS applications with graphical user interfaces for the X Window System. XIT contains user interface toolkits, including general building blocks and mechanisms for building arbitrary user interface elements and a set of predefined common elements (widgets), as well as high-level interactive tools for constructing, inspecting, and modifying user interfaces by means of direct manipulation. Although the system kernel is quite stable, XIT is still under active development. XIT can be obtained free by anonymous ftp from ftp.informatik.uni-stuttgart.de:/pub/xit/ [129.69.211.2]
Most of the graphics toolkits listed above include graphers. In particular, CLIM, LispWorks, Garnet, and Lispview all include graphers. The ISI grapher used to be in fairly widely used, but the CLIM grapher seems to be overtaking it in popularity.
A simple grapher like the one described in "Lisp Lore" by Bromeley and Lamson is available by anonymous ftp from ftp.csrl.aoyama.ac.jp:/graphers/ as the file graphers.tar.Z.uu. It includes versions for CLX, Express Windows, NCW, CLUE, CLM/GINA, Common Windows, LispView, Winterp, CLIM and YY. Several implementations have a mouse sensitivity feature and others have implementation-specific features. A copy has been made available from the Lisp Utilities Repository. For further information, contact Masayuki Ida <ida@csrl.aoyama.ac.jp>.
Grasper-CL is a system for viewing and manipulating graph-structured information. Grasper-CL includes procedures for graph construction, modification, and queries as well as a menu-driven, interactive, layout and drawing package (implemented using CLIM) that allows graphs to be constructed, modified, and viewed through direct pictorial manipulation. Grasper-CL nodes include simple geometric figures, such as circles, rectangles, and diamonds, as well as user-defined icons. Grasper-CL links include piecewise linear and arbitrarily curved arrows between nodes. User-definable actions can be associated with every graphical object. The Grasper-CL system consists of several different components: a core procedure library for programmatically manipulating the graph abstract datatype, a graph-display module for producing drawings of graphs, a graph editor that allows users to interactively draw and edit arbitrary graphs, and a suite of automatic graph-layout algorithms. Grasper-CL is available under license from SRI; contact lowrance@ai.sri.com for licensing information. For additional technical information see P. D. Karp, J. D. Lowrance, T. M. Strat, and D. E. Wilkins, "The Grasper-CL Graph Management System", LISP and Symbolic Computation: An International Journal, Kluwer Academic Publishers, 7:251-290, 1994. and the Grasper-CL home page, http://www.ai.sri.com/~grasper/
Copyright (c) 1992-94 by Mark Kantrowitz and Barry Margolin. All rights reserved.
This FAQ may be freely redistributed in its entirety without modification provided that this copyright notice is not removed. It may not be sold for profit or incorporated in commercial documents (e.g., published for sale on CD-ROM, floppy disks, books, magazines, or other print form) without the prior written permission of the copyright holder. Permission is expressly granted for this document to be made available for file transfer from installations offering unrestricted anonymous file transfer on the Internet.
If this FAQ is reproduced in offline media (e.g., CD-ROM, print form, etc.), a complimentary copy should be sent to Mark Kantrowitz, School of Computer Science, Carnegie Mellon University, 5000 Forbes Avenue, Pittsburgh, PA 15213-3891 USA.
This article is provided AS IS without any express or implied warranty.