This is a staging area for questions and answers that may or may not be added to the Common Lisp FAQ. The FAQ Editor (peter@gigamonkeys.com) welcomes feedback on the material in this document but warns that the questions and answers appearing here have not necessarily been vetted for clarity, good sense, or much of anything. For more information on the project that is producing this FAQ see http://wiki.alu.org/Common_Lisp_FAQ. (Last updated: 2007-03-07T16:14:49+8:00)
From Frank Adrian <fadrian@uxcomm.com>
It depends. Do you want to learn Lisp or LEARN LISP?
Lisp has a lot in common with a lot of other programming languages— loops, arrays, objects, functions ... in short, everything you'd want in a modern programming language. On the other hand, Lisp has a lot of powerful features that most languages don't have — an excellent condition system that allows restarting after an exception is caught, an object system that has multiple inheritance and dispatch on all method inputs, a meta-object protocol that was the basis for aspect-oriented programming, computational macros, multiple return values, specialized data structures (bit arrays, hash tables), and a syntax that takes a bit of getting used to.
So, if you want to learn Lisp, you can do the typical classroom-like thing of grabbing a textbook and downloading a free implementation, reading a tutorial, working through the exercises, and so forth (or you could probably sign up for a class at a local college). Doing that, learning it to the level that was first mentioned above, using loops, arrays, objects, functions, etc., you'll find it to be a very serviceable modern programming language (once you get used to the syntax that takes a bit of getting used to). However, by doing this you are fairly unlikely to understand it to the depth needed to see its real advantages and will wander away thinking, "What's the big deal?"
But remember that Alan J. Perlis said, "A language that doesn't affect the way you think about programming, is not worth knowing". And Eric S. Raymond says, "Lisp is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot." If you simply learn Lisp, as described above, you won't be changing the way you think. It might not be worth knowing for you. To make it really worth knowing, you will have to LEARN LISP.
LEARNing LISP is a bit more difficult than learning Lisp. You can start with the process mentioned above, but in the end, LEARNing LISP is about finding new and more powerful ways to think about problems. What you'll need to learn are such things as there being no difference between code and data (and its corollary, self-modifying code is not evil), errors are not the end but the beginning, dynamic typing is not the tool of the devil, objects are not the important thing (but the confluence of objects and functions are), why designing a language to talk about your problem is the first step to solving your problem, and other bits of Lisp knowledge that are absolutely essential to understanding the power of the language. And when you do this, you'll also understand things like why it has a syntax that takes a bit of getting used to. You might even go out and buy yourself a used Lisp Machine (mine's a Symbolics XL12000).
But like all worthwhile things, LEARNing LISP takes a bit of time. You'll probably be up to workmanlike level after one or two reasonable-sized programs and at a level of real understanding in about two years. But the best way to get started is to get started. Here are some first steps (in no particular order):
Find a friend
It's much easier to learn any language if you have someone to bounce code against for critique. It's even better if this person has used Lisp for a while. If you can't convince anyone else that learning and discussing Lisp is a worthwhile leisure-time activity (though I have noticed that you can do it while drinking beer), then find some friends on comp.lang.lisp. These folks are occasionally prickly but, if you approach them with an open mind and code-related questions (as opposed to whines about, "but why doesn't Lisp do this"), they will provide good advice. Most major metropolitan areas in the US have a Lisp Users' Group (LUG — not to be confused with Linux Users' Group (LUG)). Find one and have a beer while you absorb Lisp lore.
Find a good book
Old chestnuts like Siklossy's, "Let's Talk Lisp" or (God forbid) McCarthy's "The Lisp 1.5 Programmer's Manual" will teach you Lisp, but it will likely be an outdated Lisp that won't correspond to modern implementations. More sadly, most of these books are written as if recursion is a hot new thing (rather than just a tool) and make you believe that the only way to store data in Lisp is by using lists. Do not immediate dive into Pitman's "Common Lisp Hyperspec" — it's a reference, not a pedagogic work and the casual browser will quickly become confused (same with Steele's "Common Lisp the Language"). Get a more modern introduction, like Seibel's, "Practical Common Lisp", Graham's "ANSI Common Lisp", or Touretzky's "Common Lisp: A Gentle Introduction to Symbolic Computation". See the list below for other good books.
Find an implementation
CLISP is available on almost any OS you want to run on. You can get CMUCL on almost any UNIX-based system. Corman Common Lisp is a very-Windows'ish implementation. You can also download versions of commercial Lisp systems like LispWorks and Franz Allegro for both Windows and various UNIX systems. See below for a (probably) exhaustive list of implementations.
Learn Emacs
Seriously. Even though I am a vi man, I consider my bad upbringing to have been detrimental to my understanding and use of Lisp. Emacs is the best environment and editing system for interacting with Lisp (outside of the vaunted Machine), and you will be well served to learn it. It even has its own Lisp environment built in — you can't beat that!
Write programs
Ultimately, there is no substitute for doing. Find some interesting programming tasks and try to figure out how to solve them in Lisp. Then see if you can find some way to make the program more efficient or smaller, or extend it, or .... A really good book to step you through some of this is Norvig's "Paradigms of Artificial Intelligence Programming" or (again) Seibel's "Practical Common Lisp". This where you'll need Pitman's "The Common Lisp Hyperspec" — as a place to find out exactly what that keyword argument in reverse is or how the nsubst function really works.
Keep learning
Once you've mastered basic Lisp programming, you can move onto more advanced topics. Graham's "On Lisp" is a great book on computational macros and other advanced techniques. Keene's "Object Oriented Programming in Common Lisp" tells you everything you need to know about OOP in Lisp (except for a deeper dive into the metaobject protocol, which is covered in "The Art of the Metaobject Protocol" by Kiczales, et. al.). It is said that no one really knows Lisp, until he understands the Lisp implementation in the original Lisp — learn about this in Queinnec's "Lisp in Small Pieces". Brush up on your Lisp style with Miller and Benson's "Lisp Style and Design". And now's the time to actually read Steele's "Common Lisp: the Language" or Pitman's "The Common Lisp Hyperspec" from top to bottom — a good carpenter knows his tools and reading these books will let you understand the standard language inside and out. Learn Lisp's history — as a language that's been around for almost fifty years, Lisp has a bit of it! The articles in the two History of Programming Languages proceedings (by McCarthy, and Gabriel and Steele, respectively) are a great reads (and, yes, now is when you might want to dig into McCarthy's "The Lisp 1.5 Programmer's Manual"). Learn another Lisp variant by learning Scheme or Interlisp (also a historical quest). Lisp has always been a language about languages and, as such, has had many fruitful (and not so fruitful) branches. Even though some of these are not used anymore, they can be mined for a multitude of ideas about Lisp and how it might have been.
Buy a Lisp machine
Again, I'm serious. The pinnacle of Lisp development was (and still is) the Lisp Machine. From the built-in object-oriented database to the bucky-bitted keyboard to CLIM, you'll be immersed in an environment that is Lisp down to the hardware. Plus, if you get the right model, you'll have hours of fun trying to get the CHAOSNET software hooked to your local network!
That's about all I can think of... other than finding a job where someone will actually pay you to write Lisp, that is. It does teach you to think differently (better) about programming and it is well worth the effort. Welcome aboard and good luck!
Compiling Common Lisp software from source is similar to what is usually done with batch compilation languages such as C:
Download the source code distribution archive, or check out a local copy from the CVS tree or other repository
Unpack the distribution archive in a directory of your choice
Start compilation with a make-like system definition and dependency tool. In the case of Common Lisp, such tools are generically known as DEFSYSTEM and are invoked from the Lisp REPL rather than an operating system shell.
The most popular DEFSYSTEM tools are
ASDF and
The above steps can be automatically performed by another tool called ASDF-INSTALL.
Once compiled, Lisp programs do not usually need an explicit installation step for copying the required files to a specific file system location. DEFSYSTEM is also often invoked from the Lisp REPL for loading a program, and then running it.
If you want to deliver an application to users who do not have a Lisp system installed, you have to use implementation specific facilities.
It takes some time to appreciate the special status of lists in Lisp.
For programmers coming from other languages, the emphasis on lists may be blinding, and hide the numerous data types that Lisp provides.
Lists are the skeleton upon which the entire Lisp language/engine is built. Whenever you DEFUN or DEFMACRO you're just creating some kind of list.
Your source code is a long suite of lists.
For all their merit, lists are not appropriate for every single kind of use. Other data structures exist that are most always a better map to the problem at hand, be it hash-tables, arrays, strings, structure or even classes...
Lists are a good match for recursion, and thus for "functional programming" because lists can contain other lists. But so do arrays, which can contain other arrays, hash-tables, which can contain other hash-tables or even instances of classes that can go to any arbitrary level of nesting.
So, being a good match for recursive algorithms is not an attribute unique to lists, though the splitting of lists along the lines of "first-item-of" and "rest-of" CAR and CDR certainly makes the coding far easier than doing the same for arrays, hash-table, etc...
One could construct nested (recursive) data structures with arrays as well:
(defun car-array (array)
(aref array 0))
(defun cdr-array (array)
(let ((len (1- (array-dimension array 0))))
(when (> len 0)
(make-array len
:element-type (array-element-type array)
:displaced-to array
:displaced-index-offset 1))))
> #1a(1 3 5 7 9)
#(1 3 5 7 9)
> (car-array *)
1
> (cdr-array **)
#(3 5 7 9)
But except under very special circumstances, plain Lisp lists are just simpler to use and more efficient. One would be hard-pressed to define and use:
(defun proper-list-as-array-p (object)
(or (null object)
(arrayp object)
(proper-list-as-array-p (cdr-array object))))
(proper-list-as-array-p #1a())
T
(proper-list-as-array-p #1a(1))
T
(proper-list-as-array-p #1a(1 2))
T
when
(defun proper-list-p (list)
(or (null list)
(consp list)
(proper-list-p (cdr list))))
works just as well with standard Lisp lists!
A3: The long answer: <detail about The Lisp Way of generating or distributing an executable, links to various implementations' documentation, and why you might not actually need what you think you want (for example, Perl survives pretty well without executables (though Perl, like Lisp, has ways around that, too; we shouldn't provide mis-information about other languages while we try to combat mis-information about Lisp.))>
(said LGPL is focused on C-like linking and stuff, and it is not clear yet what does that mean in Lisp)
(cffi, verrazano stuff)
<short summary; link to Ron Garret's document
No, not exactly. <more detail>
Well, you can!
In some other language that shall stay nameless, you can initially write:
int foo (int bar) {
return bar + 42 ;
}
and later come back revisiting it because now you need an extra boolean argument.
int foo (int bar, boolean specialCase) {
return specialCase ? 0 : bar + 42 ;
}
but since you want to preserve the original call so that existing callers don't have to be modified, you end-up writing:
int foo (int bar) {
return foo(bar, false) ;
}
int foo (int bar, boolean specialCase) {
return specialCase ? 0 : bar + 42 ;
}
That way, you get the best of both world: old code still works the way it used to, new code can take advantage of the "overloaded" version.
But what about Lisp, then?
Let's say you started with:
(defun foo (bar)
(+ bar 42))
(foo 3)
45
But you now wish to add a special case. Simple:
(defun foo (bar &optional (special-case nil))
(if special-case
0
(+ bar 42)))
(foo 3)
45
(foo 3 t)
0
Rather than having to write two functions, with the oldest one delegating to the new one, you simply amend the existing one with optional arguments, all of which you give a default value that you can now account for in the new version.
Obviously, if the new behavior requires that an argument type be changed between the two (or more uses) your code has to dispatch on type inside the amended functions, possibly delegating to internal helpers.
(defun foo (bar &optional (special-case nil))
(cond
((listp bar) (reduce #'+ bar))
((numberp bar) (if special-case
0
(+ bar 42)))
(t (format t "Don't know what to do with ~a" bar))))
(foo 3)
45
(foo 3 t)
0
(foo '(1 2 3))
6
(foo "Hello")
Don't know what to do with Hello
nil
But the main point remains that from the caller perspective, everything behaves as if a single function had multiple and different argument lists.
Which is what "function overloading" is about.
Defining
(defmethod foo ((bar t)) ...)
doesn't automatically get rid of
(defmethod foo ((bar integer)) ...)
so if you call
(foo 10)
the FOO for INTEGER runs, not the (more general)
FOO for T.
This may seem obvious (if you already know CLOS :), but it's easy to forget that if you start with only the second one in your editor, and edit it into the first one and evaluate it, your Lisp environment still has both, even though your editor only has the new version.
See REMOVE-METHOD in the HyperSpec.
You might think that you could just DEFGENERIC FOO and *all* of
FOO's methods would go away, but it doesn't work like that.
DEFGENERIC doesn't remove methods defined by DEFMETHOD,
only methods defined by previous DEFGENERICs.
You could also, of course, just restart your Lisp and reload your files. That works too. :)
99.999% of video games are written in C++, often with a small amount of lower level assembler and graphics processor code as well. So could console games and modern high performance video games be written in lisp?
The simple answer is yes they could, in fact they have. Two of the biggest selling games ever; Nintendo's Mario 64 and Naughty Dog's Jak and Daxter both used lisp very heavily in their development.
One of Naughty Dog's MIT co-founders, Andy Gavin, wrote a language for writing video games called GOAL. GOAL's compiler was an Allegro CL program which took GOAL source and output executable code running on the Playstation 2. By doing this and having 'cons-less' code that had explicit memory management rather than a garbage collector they were able to utilize the benefits of lisp whilst avoiding two of the potential performance bottlenecks.
http://www.gamasutra.com/features/20020710/white_01.htm @ http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml @ http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003789.html
Mario 64 was created using N-World from middleware pioneers Nichemen. This tool set was created using Allegro CL.
These two case studies show that it is possible to create high performance games with lisps help, but is it feasible in a modern game studio?
There are problems holding it back:
Firstly game developers rely on large sets of libraries from game console manufacturers and operating system developers. These libraries come with documentation and sample code which is almost entirely C or C++. In other words, by not using C/C++ you lose a lot of shared code, legacy code and code from other non-lisp studios.
Secondly there are not a lot of programmers that no lisp, or that are wildly enthusiastic about learning.
Thirdly, managing garbage collection and cons'ing to keep performance and memory budgets requires great knowledge of lisp. Whilst it does take some time for a C++ programmer to come up to speed, the language is a lot more raw and low level, it less often a mystery what is going on under the hood.
None of these issues should prevent a lisp friendly studio from adopting lisp however, as some of the advantages of lisp are particularly advantageous to game development:
Interactive and rapid development - Since the fun aspect of a game is very subjective Game Development has to be very fluid. Systems are written with future change in mind. With lisp it's possible to connect to a running game and change not just the data but also the code.
Functional paradigm - Since lisp can be used as a purely functional language it has the potential to be used as a concurrent programming language with highly parallel processes running. Modern consoles have several CPU and GPU's and ways to use multiple CPU's are only just beginning to be explored.
Competitive advantage - Potentially by using the positive aspects of lisp and avoiding a lot of low level issues a competitive advantage can be obtained both in terms of product quality and on-time delivery.
If you're a lisp enthusiast and game developer consider joining the cl-gardeners project, of which this FAQ is a part.
http://www.lispniks.com/cl-gardeners/
This varies between implementations, so you should check your documentation. In SBCL
foo@host] sbcl --disable-debugger --noprint --eval (do-this-function 'on 'these 'args)
and
foo@host] sbcl --disable-debugger --noprint --load filename.lisp
ought to get you started.
Lisp uses the value of the variable *print-case* whenever a symbol has to be converted to a string:
CL-USER 1 > *print-case*
:UPCASE
CL-USER 2 > 'some-symbol
SOME-SYMBOL
CL-USER 3 > (setf *print-case* :downcase)
:downcase
CL-USER 4 > 'some-symbol
some-symbol
CL-USER 5 >
The solution is thus to include
(setf *print-case* :downcase)
in your initialization file.
Beware, though, that all subsequent printing will be affected, and if some of your libraries are expecting random symbols to print in upper-case, they might be in for a shock:
(send-http-request (verb stream)
(format stream "~a" verb)
(...))
(send-http-request :get *my-stream*)
will output: "get" even though HTTP 1.x requires: "GET"
;; Warning: Incorrect code!
(if (test)
; then-part
(statement1)
(statement2)
; else-part
(statement3)
(statement4))
In general, wherever you can put a single expression, you can put a PROGN with multiple expressions. So to solve this particular question,
(if (test)
(progn
(statement1)
(statement2))
(progn
(statement3)
(statement4)))
You could also use COND, which has implicit PROGN's for each set of result statements:
(cond
((test)
(statement1)
(statement2))
(t
(statement3)
(statement4)))
Of course, COND also works with multiple tests.
See the Hyperspec for PROGN and COND.
If you're looking for something like
(if test [then] a b c d e)
or
(if (not test) [then] a b c d e)
in other words, ifs without elses, then WHEN and UNLESS are your friend.
According to the HyperSpec:
If the backquote syntax is nested, the innermost backquoted form should be expanded first. This means that if several commas occur in a row, the leftmost one belongs to the innermost backquote.
Or to look at it another—and perhaps more helpful way—the when several commas (or comma-at-sign combos) occur in a row, the rightmost one belongs to the outermost backquote. (MORE TK)
You probably mean an interactive command processor that accepts Lisp expressions, evaluates them and prints their results. If so, you should simply look for a Common Lisp implementation or development environment, without regard to how expressions are processed.
Although native machine code Lisp compilers have been available since the early 1960s, many outsiders still tend to refer to Lisp environments as "interpreters", with an implied assumption of poor performance. This may be because interpreted systems were more common on widespread machines with limited resources such as personal or home computers, or because interpreters provided more features for interactive development.
Most current Common Lisp implementations come with an interpreter and a compiler, both accessible from the same interactive expression processor.
May want to talk about embeddable Lisps such as ECL since that what some folks may be looking for when they ask for an interpreter.
Once a year since about 1975, if you listen to people on Usenet. Interest in lisp did drop considerably in the mid to late 1980s, when the "Big AI" bubble burst, and the end of the Cold War brought budget cuts to many of the AI and simulation projects sponsored by the DoD.
It's not clear-cut, though. Some of the very best books on lisp programming were written as or shortly after mainstream interest in Lisp started to wane (see or list above).
It might. The AI bust happened 20 years ago, and conditions in the semiconductor and IT industries are very different now. Most importantly, the continued action of Moore's Law has caused developer time to replace computing power as the limiting resource in both hardware and software design. In addition, mass-marketing of hardware and software products and the rise of server-based applications have all made rapid development a top priority in both hardware and software.
Taken together, these trends have fostered the development of an increasingly powerful series of scripting languages: first Perl, then Python, then Ruby. Observers in the lisp community have <a href="http://www.paulgraham.com">noticed</a> that these languages are becoming progressively more like Lisp.
So the prognosis for Lisp may not be so bad. On the other hand, Lisp's resurrection as a mainstream language hasn't happened yet.
Give us some time. We're working on it.
Answer 1: No.
Answer 2: Some free Common Lisp implementations have native-code compilers that are about half as fast as C. This translates to 2-4 times the speed of Java and 50-80 times the speed of Perl, Python, or Ruby. Refer to http://www.norvig.com/Lisp-retro.html for details.
A: Well, there are plenty of reasons.
A: Lisp is old - almost 50. These days, lots of people mistake age for obsolescence.
A: Some people associate Lisp with the old hardware it used to run on (the PDP-10 was a popular platform, I hear)
A: Lisp is interactive, which a lot of people take to mean that Lisp is (always) interpreted. Early lisps (and others, like CLisp) are interpreted, although most modern lisps are compiled.
A: Emacs Lisp, owing to the incredibly wide array of platforms to which it was eventually ported, used to be very slow for many users
A: Lisp was used extensively for AI and simulation, fields full of hard computational problems.
A: Lisp will a few bits of type information to values that it stores, so values don't always fit neatly with machine words (this is the only legitimate reason in the list).
A: For the previous two reasons, a lot of effort in the AI and Lisp communities went into producing custom hardware — Lisp Machines, or Lispms — in the mid 1980s. Some people got the idea that you needed custom hardware to run Lisp at all.
A: Lisp supports arbitrary-precision arithmetic, which can be very slow for numbers thousands of bits long. Of course, other languages will just overflow on you...
A: Linked Lists, which are Lisp's "default" data structure, have slower access times than arrays. Some people think "default" still means "only".
A: Early in its life, Lisp was a language for academics, hence (in the minds of some) not "practical", hence not efficient, and therefore slow.
A: In Lisp, optimizing code is something only experts are really good at. In other languages, anyone can write fast code, but you need expertise to make sure it doesn't break.
A: Probably the biggest reason people think Lisp slow, though, is that Lisp had a garbage collector from the very beginning, way back when everyone programmed in machine code for performance reasons. Countless holy wars were waged over garbage collection, both for its own sake and as a proxy for a larger debate: was it right for the machine to "do things for you" that you found too complex or repetitive to do all the time, even if you could do better than the computer when you tried? After twenty years or so, Lisp became an icon of the argument that "slower is OK if it's easier to use," which was predictably condensed into "Lisp is slow."
Common Lisp's original designers designed the language for people using editors with a name-completion feature, like tab-completion in Unix shells. You can get this functionality yourself by using SLIME with Emacs (or Vim).
You could also use macros to define abbreviations for the offending names. This is from the "Macro-defining Macros" Chapter of Paul Graham's On Lisp:
(defmacro abbrev (short long)
`(defmacro ,short (&rest args)
`(,',long ,@args)))
(abbrev dbind destructuring-bind)
(abbrev mvbind multiple-value-bind)
There are a few things to be aware of when using macros — see any book on Lisp for details.
A good rule of thumb is that you touch every line of code a hundred times: once to write it, nine times to debug it, and ninety times to read it in order to figure out what it does. The exact numbers are irrelevant; what matters is that it doesn't matter a jot how long it takes you to type a word; what matters is whether you can read it when you come back to figure out why it's crashing. If the length of operators bugs you, you need to (a) get a better editor (*coughEmacscough*), (b) type faster or (c) increase your screen resolution to fit more on the page.
(It may also be worth mentioning Larry "Perl" Wall's idea of Huffman coding - that concepts you use a lot in a language should be shorter than ones you don't use very often. That's why "the" and "of" and "it" are short words in English and any other spoken language that has them, whereas words like "dichotomous" and "apatosaurus" are quite long: you use the short words more often, and the long ones less often. This makes it easier to use the common words, but it ALSO (importantly) allows the rarer ones to contain more "hooks" to hold your memory and help your understanding.)