Nikodemus' Common Lisp FAQ

Nikodemus' Common Lisp FAQ

---

Last update: 2012-04-13

This is a very informal FAQ for Common Lisp language, reflecting the subjective opinion Nikodemus Siivola. This text is partly based on other FAQ encountered on the Internet and comp.lang.lisp.
If you think I took your text, I will be glad to admit it, so write on nikodemus@random-state.net.
The current version of this FAQ available at the following addresses:
http://random-state.net/files/nikodemus-cl-faq.txt
http://random-state.net/files/nikodemus-cl-faq.html
FAQ also periodically published in comp.lang.lisp.

The beginning

Common Lisp? CL? Clisp? Lisp?

"Common Lisp" is the name of the language standardized by ANSI.
"CL" is the preferred abbreviation of the previous name.
"Clisp" is not a correct reduction because it is the name of one of the implementations of Common Lisp.
"Lisp" is a category of languages, which include CL.
"LISP" is not writing for 20 years, Common Lisp, often abbreviated to Lisp if
it is clear from the context what exactly it is.

what?

About the language itself you can read here:
http://random-state.net/features-of-common-lisp.html

How to learn Common Lisp?

the
1. to Read a good book about Common Lisp.
the
2. to Start to use it.

A lot of people not just trying to pass along the first path, but forget about the second.
Well the truth is, you can not learn programming in the language before starting to use it. And then, without working on a fairly large program with many things impossible to understand properly.

What are the pitfalls to get around?

Any good book will tell you about the features and tricks of the language, but there are a couple of psychological and social aspects, on which many stumble:

a Study of Lisp macros is crazy.
Lisp macros are a great thing, but the power they give, beginners are often confusing.
Often a symptom of the problem — attempt to do something without a clear understanding of why this is done. Remember, everything can be done using macros, you can do without them. Of course, it may turn out not so practical, but the memory of it down to earth.
Before you learn to run, learn to walk. It's worth it, especially because then you can fly.

Lisp is not perfect, and this is not news.
Some come to Lisp from with high expectations and get disappointed. Other people compare Lisp with a language X and find that the first something is lost.
And those and others can talk properly and have valid claims, but the problems start when these people nachinajuschih their claims, for example on #lisp.
If the reasoning is correct, most likely the question has already been discussed a hundred times and no one has neither the strength nor the desire to discuss again.
If the reasoning is incorrect or they are more theoretical than practical, despite the fact that from year to year unhappy with newcomers constantly raise these questions, no one will not have neither the strength nor the desire to discuss again.
This does not mean that talking on the Internet about bad Lisp forbidden, but... If you are a beginner — come and say that everything is bad, don't expect that you people will go with open arms. Even if you are a hundred times right.
Complaints from the old people, also did a lot for the community, have much more weight.

Experienced public listary see a lot of trolls.
A LOT OF TROLLS! Confused newbie sometimes looks like a Troll, largely because most trolls often masquerade as newcomers to Lisp.
So people can think you are a Troll and respond accordingly.
The best way to avoid this is to be polite. If someone tells you that you are wrong or mistaken, for a moment suppose that he or right, or it seems that you are wrong or mistaken.


what book to start?


Start with "Practical Common Lisp" (also known as PCL) by Peter Seibel (Peter Seibel). It is a good starting point if you already know some programming language. The book is available in electronic and printed form:

http://www.gigamonkeys.com/book/

Another good book is "Common Lisp: A Gentle Introduction to Symbolic Computation" by David Turkish (David Touretzky). For beginners in programming or those who PCL seemed too complicated, should read this book. If you start with it, then read PCL. Although if you've already read PCL and understood, this can be safely skipped. The book is available in electronic and printed form:

http://www.cs.cmu.edu/~dst/LispBook/index.html

There are still a lot of good books, but the two best for beginners. "Land of Lisp" is quite good, but in my humble experience it can form the wrong idea. If you start with it, still read the PCL.

Be sure to check "Hyperspec" CLHS or electronic version of the standard language. It's just a valuable reference:

http://www.lispworks.com/documentation/HyperSpec/index.html

Do not just rush to read the book. Just know where it is, here are the official answers to all possible questions about CL. This is the perfect place to find out what makes a particular operator. In addition, it is worth a look to see whether implemented the desired functionality in the language.

Do not neglect also the documentation supplied with your implementation. In the case of SBCL, the manual is at:

http://www.sbcl.org/manual



How can I get the implementation?


Depends on what you need, although if you just started, then it doesn't matter. However, if you are waiting for help from a group of people take that this group enjoys.

As you training, you'll be able to make an informed choice. The transition between implementations is not very difficult, so it is not a reason for a painful doubt.

I am very partial to SBCL:

http://www.sbcl.org/

SBCL is good because it is open source, runs on many platforms (including Windows), includes the compiler, is very serious about compatibility with the ANSI standard and generally brings joy and peace in the world... and here I should mention that I'm one of the developers of SBCL and my company Steel Bank Studio Ltd provides commercial support for it.

If SBCL for some reason does not suit you, we can offer go through the following lists:

Open:
the
the
• Clozure CL
the
• CMUCL
the
• Clisp

ABCL the

• ECL


Commercial:
the
the
• Lispworks
the
• Allegro CL
the
• Scieneer




Where is the library? There is an analogue of CPAN or RubyGems?


RubyGems is very similar to "QuickLisp":

http://www.quicklisp.org/

It offers a lot of libraries and manages dependencies between them. It's a very very necessary tool.

The closest to CPAN are "Cliki" and "common-lisp.net":

http://www.cliki.net/
http://www.common-lisp.net/

but ... nothing, really.



What IDE to use?


If you are working with SBCL, Emacs and Slime use:

http://www.common-lisp.net/project/slime/

Even if you have never used Emacs, make an effort and use Slime — the learning curve is not very steep and all of the commands available through the menu.

You can configure Slime with Quicklisp, see the section below "How to configure the environment?". To begin learning, you can M-x slime-cheat-sheet, however, this is only a small part of possibilities of Slime.

If you are using a different implementation, use the IDE that the developer recommends (though Slime works with almost all implementations).

For practical work with the Lisp editor should at least:

the
the
• correctly set occupy code in Lisp;
the
• to be able to execute commands Edit Definition, Compile Defun, Eval Expression, Symbol Describe, Disassemble Function, Trace Function, Inspect, expression and other commands to interact with your Lisp ohms
the
• to communicate with the debugger;
the
• to interact with the inspector.


Slime can all of the above and much more.

If you like Vi(m), note Slimv, Vim which connects with a portion of Slime written on Common Lisp:

http://www.vim.org/scripts/script.php?script_id=2531
https://bitbucket.org/kovisoft/slimv/
http://kovisoft.bitbucket.org/tutorial.html

... but I can't vouch for it, because it does not use Vim/Slimv.



How do I configure the environment?



A good guide (at the time of writing) on receipt of SBCL, Slime and Quicklisp setup is located here:

http://mohiji.nfshost.com/2011/01/modern-common-lisp-on-linux/
http://mohiji.nfshost.com/2011/01/modern-common-lisp-on-osx/

Instructions for setting up Clisp on Windows. However, it is impossible to grasp the immensity:

http://mohiji.nfshost.com/2011/01/modern-common-lisp-on-windows/



A GUI is?


Yes and no. One GUI that would be all, no.

Commercial Lisp s mostly come with GUI libraries, and it seems that the supporters of these implementations like the bundled library. However, the code for these libraries is not transferred between Lisp AMI. If you use a commercial implementation, and code portability is not interesting to you, then choose the tools offered by the developer. Depending on that library code is transferred to different operating systems, maybe this is what you need.

The camp is open code also has several solutions.

CommonQt is a Common Lisp binding to the smoke library for Qt:

http://common-lisp.net/project/commonqt/

LTK built on top of Tk:

http://www.peter-herth.de/ltk/

CL-GTK2 and CLG is a binding to GTK+, but I can't say anything about the current status of these developments. It is also worth to look at GTK Server.

http://common-lisp.net/project/cl-gtk2/
http://sourceforge.net/projects/clg/ http://www.gtk-server.org/

CLIM (Common Lisp Interface Manager) is almost a standardized API specification for the GUI is quite different from the GUI listed above. Don't expect everyone to be familiar with and understand.

http://random-state.net/files/how-is-clim-different.html

Many people swear that it's the best thing for building a GUI, others argue that it is not so. Anyway, most of the commercial Lisp s CLIM implement and still have a portable an open source library called McCLIM, quite comfortable, although lately not really developed.

http://common-lisp.net/project/mcclim/

CLX is portable low level Lisp interface to the X11 that provides a level of abstraction comparable to Xlib.

http://www.cliki.net/CLX
https://github.com/sharplispers/clx

If you are not strictly limited to GUI issues, I'm wrong, if you do not mention CL-OPENGL, a portable binding to the OpenGL API, GLU and GLUT:

http://common-lisp.net/project/cl-opengl/



What are the forums?


Not a forum of course, but has Lisp Planet — an aggregator of blogs for Common Lisp. A lot of interesting information without overloading.

http://planet.lisp.org/

LispForum — just good forum:

http://www.lispforum.com/

but I can not answer because rarely use it.

There is another group comp.lang.lisp on Usenet/Google Groups, but they are densely populated by trolls. There the authors writing is quite competent, with speculation of the profane — an ordinary phenomenon. To read these groups can be hard, but to use Lisp om to read them is not necessary.

http://groups.google.com/group/comp.lang.lisp

Specialized mailing lists have a much better ratio signal/noise. All implementations are trying to make your own custom and reference lists, most libraries also create their own mailing lists. For SBCL, for example, this:
https://lists.sourceforge.net/lists/listinfo/sbcl-help

Among open-source developers and users of the popular channel #lisp on freenode.org. Have, however, given that #lisp is fairly strict adherence to the topic, and this topic is Common Lisp, not "Lisp in General". This is the channel #lispcafe with much more lenient rules.

Fairly active community of game developers, but I'm not really familiar with it. The Google to help you.

Professionals communicate Common Lisp in the list of "pro". Discussion of other dialects of Lisp is offtopica, newbie questions will NOT be accepted.

http://lists.common-lisp.net/mailman/listinfo/pro



language




How to compile the file?


Short answer: start Lisp and type:

the

(compile-file "/path/to/myfile.lisp")



Then, most likely, you will need to download the (load ...) the compiled file.

Detailed answer: most compiled languages, noninteractive — you compile a file from command line or IDE, then run the compiled file. In Lisp it is not so.

Despite the fact that in the General case, you can turn your project into an executable file, a typical working session is not similar to the cycle of edit-compile-execute, as you would expect.

Usually interact with a running Lisp process that contains a working session in which you interactively add the code.

For example:


the
1. open Emacs with M-x slime run Slime and Lisp;
the
2. with, for example, ASDF loaded the existing code;
the
3. open the desired file, fix the function and press C-c c-c, which will cause it to recompile;
the
4. go to the Slime REPL and test the changes;
the
5. repeat step 3.


The above mentioned abbreviation ASDF stands for "Another System Definition Facility". This system allows you to specify the way of collecting several files into a single system for loading or compiling a team. Something like Make.



How to make executable file?


The answer depends on your implementation. Look in the documentation. If we talk about SBCL:

the

;; Load the application into SBCL, then do a save-lisp-and-die.
;; Entry point to the app - MY-FUNCTION.
(save-lisp-and-die "my.exe" :executable t :toplevel 'my-function)





FUNCALL and APPLY — what is the difference, what to use?


Short answer: anywhere you use FUNCALL, otherwise use APPLY.

Detailed answer: if you call FUNCALL, you must know the number of arguments. APPLY (and MULTIPLE-VALUE-CALL) does not require information about the number of arguments.

the

(defun map-list-with-1 (function list arg)
(mapcar (lambda (elt)
(funcall function elt arg))
list))

(defun map-list-with-n (function list &rest args)
(mapcar (lambda (elt)
(apply function elt args))
list))



There is no need to write MAP-LIST-WITH-1 with APPLY, call FUNCALL will almost certainly be more effective.

In contrast to the MAP-LIST-WITH-N cannot be written using FUNCALL, since the number of arguments the caller is unknown. You should use APPLY.



SET, SETQ and SETF — what is the difference, what to use?


Short answer: always use SETF.

Detailed answer: long Ago, when there was no Common Lisp, was not lexical variables were only dynamic. There was then not a SETQ or SETF, only SET.

The fact that today is written as

the

(setf (symbol-value '*foo*) 42)



recorded so

the

(set (quote *foo*) 42)



that eventually dropped to SETQ (SET Quoted)

the

(setq *foo* 42)



Then there were lexical variables and SETQ was used for their assignment, so that SETQ is no longer just a wrapper around a SET.

Later, someone invented the SETF (SET Field) as a generalized way of assigning values to data structures, mirroring the L-values in other languages:
the

x.car := 42;



is written as

the

(setf (car x) 42)



For symmetry and generality, the SETF also includes the functionality of SETQ. We can say that SETQ was low-level primitive, and SETF — a top-level operation.

Then came the symbolic macros. Because symbol macros are transparent, it was done so that SETQ behaves like SETF in the case, when assign a "variable" is in fact symbolic macro:

the

(defvar *hidden* (cons 42 42))
(define-symbol-macro foo (car *hidden*))

foo => 42

(setq foo 13)

foo => 13

*hidden* => (13 . 42)



And here we find ourselves in today: SET and SETQ is essentially an atavism left from the old dialects, and would probably be thrown out of what will be the next Common Lisp om.

Always use SETF.



'(1 2 3) or (list 1 2 3)?


Short answer: email

the

(list 1 2 3)



until you understand the difference. If you write

the

'(1 2 3)



do not modify this destructive (i.e. with SORT or NREVERSE).

Detailed answer: first, the single quote is a macro that converts

the

'anything



in

the

(quote anything)



during the reading, so

the

'(1 2 3) === (quote (1 2 3))



Second, QUOTE is a special operator that returns its arguments uncalculated. So

the

'(1 2 3)



returns the literal (literal) list. As in most languages, a modification of the literal (literal) data leads to uncertain consequences. For example, the compiler may combine constants, literals containing:

the

(let ((a '(1 2 3))
(b '(1 2 3)))
(eq a b)) ; => T or NIL



The consequence is the fact that changing A, may also change and B. Then what do QUOTE? For example, if you have large immutable lists which the compiler is able to connect, then mark them as literal (literal) gives the compiler the right to do so.



What kind of *EARS*?


Whatever you used to declare variables, DEFVAR or DEFPARAMETER, always do *IS*. And do not do so for local variables.

the

(defvar *very well* ...)
(defvar is-very-bad ...)



Why? If you still don't know what the special variables, you can continue reading the book that I read and come back when you've finished, for now, use the lugs.

Protect ears from two simple mistakes that are very easy to do.



Error 1: random binding of a special variable.


the

(defparameter foo "foo!")

(defun say-it ()
(write-line foo))

(defun say-more (foo)
(say-it)
(format t "now say ~A~%" foo))



Now

the

(say-more "bar!")



will print

the

say bar!
now say bar!



instead of the expected

the

say foo!
now say bar!



... oops!



Error 2: typo reads from a special instead of a local variable warning not issued.


Usually you will get a warning compile-time and run-time error in case

the

(defun foo (bar)
bat)



but if to write

the

(defparameter bat "baseball")



then there will be no error and you will spend a lot of time debugging, trying to figure out what's wrong.

If you write code for yourself anyway, you put lugs or not, but when you post code, no *ears* is wasting time of other people. Don't do that, please!

The absence of lugs creates a sense of the error: when I see

the

(defparameter no-ears ...)



I understand that you need to read the code especially carefully, because there is no guarantee that the code from the first vzlyad is completely innocuous, will have non-local side-effects or dependencies.

Always put the *ears*. Say, from all rules there are exceptions, but in this case it is very difficult to find a real exception to this rule.
Good code
— Nikodemus

Article based on information from habrahabr.ru