In the article Technical Issues of Separation in Function Cells and Value Cells, Kent Pitman and Richard Gabriel explains the decision of making Common Lisp a Lisp-2:
There are two ways to look at the arguments regarding macros and namespaces. The first is that a single namespace is of fundamental importance, and therefore macros are problematic. The second is that macros are fundamental, and therefore a single namespace is problematic.
According to that, when programming macros, a single namespace in macro programming is inherently problematic.
But Clojure's approach is a little bit different: the backquote does namespace resolution.
In chapter 9 of the book On Lisp, Paul Graham talks about avoiding variable capture by separating code in packages:
However, packages do not provide a very general solution to the problem of
capture. In the first place, macros are an integral part of some programs, and it
would be inconvenient to have to separate them in their own package. Second,
this approach offers no protection against capture by other code in the macros
package.
As far as I can see, Clojure's solution to variable capture looks like the packaged option showed by Paul Graham.
One of the major drawbacks pointed by Paul Graham is that it would be inconvenient to separate macros in different packages, but Clojure's backquote does it automatically, by prepending the namespace of the symbol, right?
So, is it a complete solution to variable capture? Or Kent Pitman's words still apply? If there is any problem that Common Lisp's separeted namespaces can handle that Clojure cannot, could you write down an example?
I have never encountered a limitation with Clojure's macro system. It's a fully general macro system, and to my knowledge it is exactly comparable with Common Lisp in terms of fundamental capabilities.
There are obviously many syntactical differences, but I think they are mostly superficial and don't affect the expressive power that you can achieve with macros.
My view is that Clojure gets a lot of design aspects right here:
Lisp-1 is simpler and conceptually clearer than Lisp-2, particularly in a functional language where you actually need to treat functions as first class values.
Symbol capture generally isn't a problem - the Clojure syntax quote and namespace system do a good job of making macros both usable and readable.
As a final comment, the summary of the linked article is quite illuminating:
The bulk of arguments that focus on clean semantics and notational
simplicity tend to favor uniting the function and value namespaces..... We feel that the time for
such radical changes to Common Lisp passed, and it would be the job of
future Lisp designers to take lessons from Common Lisp and Scheme to
produce an improved Lisp.
In my humble view - Clojure is a good example of an "improved Lisp".
I've just started learning a dialect of lisp (Racket) and I'd like to know if some one has a link or can point me to the theoretical foundations of the family of lisp languages, by resources I mean papers, articles or books anything that you could think of.
Preferably indicating which mathematical concepts it uses how it constructs it operators, how it resolves them,unifies identities etcetera. I'v read the SEXP in wikipedia but I find it a bit shallow.
I'm interested in the foundations because I like to be able to explain how things work to others .
Thanks in advance.
You could start at the beginning: http://www-formal.stanford.edu/jmc/recursive.html
http://library.readscheme.org
http://en.wikipedia.org/wiki/Lisp_in_Small_Pieces
I would also add Landin's "The Next 700 Programming Languages" to this list; where McCarthy reveals the notion of programs interpreting other programs, Landin shows how the same theoretical framework can be seen to underly nearly all programming languages.
In fact, I think it's not unreasonable to suggest that the theory of LISP-like languages is simply... the theory of programming languages.
Paul Graham has some nice mini-articles on the history of Lisp: http://www.paulgraham.com/lisp.html
Don't miss the original lambda papers by Guy Steele and Gerald Sussman.
"Lambda: The Ultimate Imperative"
"Lambda: The Ultimate Declarative"
"Lambda: The Ultimate GOTO"
Here are a couple links:
Lisp Primer by Allen and Dhagat
Lisp Tutorial
I've learned enough Common Lisp to be able to muddle my way through writing an application. I've read Seibel's Practical Common Lisp
What libraries or programs should I be reading to understand the idioms, the Tao, of Common Lisp?
CL-PPCRE is often cited as a good example, for good reason. Actually, probably any of Edi Weitz's libraries will make good reading, but CL-PPCRE is particularly clever and it's a useful and impressive library. Beyond that a lot of CL implementations are written mostly in CL. It can be pretty productive to pick some part of CL that's usually implemented in CL and compare how different implementations handle it. In particular, some of the best examples of large useful macro systems are implementations of things in the standard. Loop is an interesting read, or if you're really ambitious you could compare a few implementations of CLOS.
If there's some area of computing you are particularly interested in it might be worth mentioning that, so people can tailor recommendations to that.
It's another book, so it may not be precisely what you're looking for, but Peter Norvig's Paradigms in Artificial Intelligence Programming contains a lot of well-written, smallish Common Lisp programs. It's not perfectly natural code, especially in the the first few chapters, because, like code in Practical Common Lisp, it focuses on teaching you how to program in CL, but it's still very much worth a read. It also contains some excellent examples of ways you can build other languages on top of Common Lisp, and it has some valuable advice on how to improve the performance of CL programs.
The other recommendations (PAIP and CL-PPCRE) are excellent. I would also suggest becoming acquainted with Alexandria's code and also taking a look at GBBopen.
The Art of the Metaobject Protocol - is a book with the most beautiful code ever written.
LISP (Lisp In Small Pieces) is a neat book; shows clossette (small obect system) and
some compiler stuff. Without doubt, Norvig's book is awesome.
I really like "Building Problem Solvers" as well but the code is a bit rough. I'm not
used to binding dynamic-scoped variables in the parameter list. But it made for much fun
improvements trying to "pre-compile" the discrimination net. This book gives another
approaches to some of Norvig's code; I still think that Norvig's code
is much "neater and cleaner" code (easier to read and understand, and still creative).
"Building Problem Solvers" should come with a warning label like "you're gonna need some
aspiren (sp). It felt like a bolt of lightning struck me in the head when I finally
"understood" rms and Sussmans' dependency directed backtracking. Compiling the pdis
was also brilliant. Excellent stuff. I just wish I could remember it all ...
I like the SBCL code.
The only thing I would offer is to program. That is what I did.
I did two things. One I tackled a problem that i was familiar with, a unit testing framework and expanded it to include test suites. To get an understanding of macro writing.
The second thing I did was play around with basic objects in CL. Macros, closures, and style.
Also don't forget about getting feedback from Lispers about your code.
(defun ugly-lisp-code? () ())
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I picked up a LISP book at a garage sale the other day and was just wondering if it was worth spending some time on.
Yes. I'll stick to Common Lisp, here, though Scheme is also a superb language that has a lot to recommend it.
In Common Lisp, you have a largish multi-paradigm language that provides some things that either don't exist widely outside the Lisp family of languages, or are limited to CL and even more obscure/niche languages.
The first feature, which you can get in one way or another from CL, Scheme and quite a few other dialects, is a real macro system.
I say "real" because the system is much more complete, flexible and reliable than, say, C preprocessor macros. It's extremely difficult to get CPP macros to do even simple things (like swapping the values of two variables, or making a foreach construct) in a reliable fashion, but these are trivial with Lisp macros. This turns out to be a very powerful tool for introducing new abstractions and dispensing with "boilerplate" code.
The second feature, which is effectively limited to Common Lisp, is CLOS, the Common Lisp Object System. Despite the name, it's not a conventional OO system like that of Java with methods being part of a class's definition. Instead, it provides polymorphism through "generic functions" which are what methods are attached to, and by default allow you to do multiple dispatch.
I vastly prefer CLOS to the more usual approach to object orientation, as it makes a number of "patterns" (like the Visitor pattern) completely unneccessary and because extension of existing generic functions is so easy; others loathe it because it takes an extremely cavalier approach to encapsulation and because extension of generic functions becomes arguably too easy. Either way, CLOS is different enough that I think it's worth learning just for the different perspective it provides.
The third feature, which is available outside of Lisp but still fantastic if you've never experienced it before is dynamic, interactive programming. CL debuggers tend to be extremely powerful tools, and CL provides for dynamic definition and redefinition of functions, classes and methods, all of which dramatically improves one's ability to explore a problem, test solutions of that problem and its subproblems, and finally put together a program that works correctly and efficiently.
Lastly, for a lot of classes of problems, Lisp is a great practical language. It provides good performance (usually not as fast as C, but dramatically faster than most "scripting languages"), safety, automatic memory management, a decent "standard library" of functions and tremendous opportnities for easy extension.
It is worth learning for "mind-expansion" purposes but not so popular for building apps these days.
However, it is powerful, and mature, and there are fast and free compilers out there. So there is no reason not to choose it for a program if you like.
The way in which Lisp treats data structures and program structures the same offers amazing power which is worth understanding.
Its history is fascinating and it has shaped the world of computer science.
Be sure to check out Ableson and Sussman's Structure and Interpretation of Computer Programs at MIT OpenCourseware
Clojure: a Lisp on .NET and Java VMs
GNU CLISP.
CMU Common Lisp
Depends on the book. Which book?
Common Lisp is worth learning today because it's one of the few languages that pretty much "does everything". If there's some mainstream or obscure programming idiom or technique, odds are Common Lisp has it already in some form. About the only thing CL lacks is continuations (many argue it doesn't need them, but that's not helpful if you want to explore them).
Anyone spending any serious time writing in Common Lisp will come out Changed in some way, typically for the better, IMHO.
Even if you can't carry all of the Lispy concepts you learn and use in to other environments, knowing about them and how they work is still useful.
Good programmers expose themselves to as many different programming paradigms as they can - not as many programming languages as they can.
The LISP family (there are several variants) is very worth while getting to know. Your objective should be getting your head wraped around functional programming and the lambda calculus - the paradigm that LISP is based on. Focus less on becomming an "ace" LISP programmer (that could take years).
If you find functional programming "flips your switch", try having a look at PROLOG too - here the paradigm is based on evaluation of Horn Clauses (predicate logic).
I may have spent the last 20 years earning a living as a COBOL programmer (OMG - they still have those!), but I think I am a better programmer because of the time spent learning what LISP, and a number of other programming languages were really all about.
Have a blast...
Here's a Google Tech talk worth watching about a company currently producing large, complex software for the airline industry in Common Lisp:
Lisp for High-Performance Transaction Processing (The video is now unavailable. Here's some note by Zach Beane.)
Other topics are mentioned in that video, including Clojure, a new variant of Lisp for the JVM (some work is now being done to develop Clojure for the CLR too, but that is not as far along), which is worth checking out for the way it addresses concurrency issues. See the Clojure site at:
http://clojure.org/
and, in particular at first, check out the link in the upper right on that page to some excellent Screencasts with overviews of the concurrency issues and Clojure features.
If you get interested in Lisp, and the book you found is not that great (I have an old one myself that didn't do much for me), Paul Graham's book On Lisp is available free at http://www.paulgraham.com/onlisp.html and is very good. The general Lisp idea is the same for Common Lisp or Scheme or Emacs Lisp or Clojure, but the specifics will be different - so keep that in mind if reading Graham's book, which focuses mostly on Common Lisp (with some mentions of Scheme specifics.) On Lisp is probably not the best beginner book, but it's worth going through it and just skimming over specifics you're not ready to follow in detail yet to see what is there, particularly with regard to macros, which On Lisp really explores.
One benefit of Lisp is that you develop an appreciation for prefix and wonder why everyone else in the world doesn't us it too (like with Latex or vim)
+ 1 2 3 4 5 6 7 8 9
is much easier to code/edit/paste than
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9
See this question, and especially the third answer, the one that explains that Lisp is good for solving complicated problems, those problems that are hard to decompose into more manageable modules if you were to try to solve them in another language. In other words, if you are keen on exploring ways to solve convoluted problems, that involve, let's say Natural Language Processing, or Knowledge Aggregation... then, yes, Lisp might just be useful to you.
Learn lisp to learn about macros, and that code is data, and to learn that you can reach enlightenment w/o the self-flagellation of C++.
Learn Common Lisp to learn about reader macros and compiler macros. I don't know any other language that has them.
Learn scheme for continuations.
Learn Clojure because it's going to make Java obsolete :-)
It (Common Lisp) is still heavily used by academics working in Artificial Intelligence. Scheme is a Lisp-like language used by many (most?) CS departments as well. Personally I think learning Lisp is worthwhile whether or not you end up using it. It's a classic language that we've learned a great deal from over time.
Learning LISP is a good way to learn functional programming effectively, and is often used as an introductory language for undergraduate students. Many people feel that Structure and Interpretation of Computer Programs, which uses the Scheme dialect of Lisp, is a book that should be on every programmers shelf.
Paul Graham has been a big proponent of Lisp, and in his book, Hackers and Painters, he describes how he used the power of Lisp to dominate the competition in creating ViaWeb for Yahoo Stores.
Elsewhere, I've seen Lisp dialects used prominently in the aerospace industry, as scripting tools for integration frameworks like Comet, and AML. Lisp will always be tied to the early AI experiments in the 1950's.
As other have alluded to, Lisp isn't that popular anymore for general programming, and it definitely (IMO) has some major problems for writing real systems in, but of course others disagree (for instance much of ITA's software is written in Lisp, and they make crazy bank).
Even if you never write a 'real' program in Lisp, it is absolutely worth learning. There are many programming techniques originally pioneered in Lisp that, knowing them, will help you write better code in Python, Perl, Ruby, ML, Haskell, and even C++. For instance, check out Higher Order Perl, which shows how to do all kinds of amazing tricks in Perl; to quote the introduction "Instead of telling you how wonderful Lisp is, I will tell you how wonderful Perl is, and in the end you will not have to know any Lisp, but you will know a lot more about Perl. [...] Then you can stop writing C programs in Perl. I think you will find it to be a nice change. Perl is much better at being Perl than it is at being a slow version of C."
And there are some great books out there that use Lisp, and it will be easier to understand them if you know the language - SICP, Norvig's Paradigms of Artificial Intelligence Programming, and The Reasoned Schemer all come to mind as must-reads.
Some people here are recommending Clojure. While I would say that Lisp in general is good, I would caution against Clojure, at least for beginners. This is not out of any difficulty using Clojure, just in the fact that Clojure is gratuitously inconsistent with Common Lisp and Scheme. If you want JVM integration, use Armed Bear Common Lisp: https://common-lisp.net/project/armedbear/ , though for general use, I would recommend Steel Bank Common Lisp: http://www.sbcl.org/
This is like questioning if "it's worth to learn C these days of web programming?". Only you can decide if it's worth. What you have to ask yourself is: what am I trying to achieve reading the book?
Learning new languages sometimes aren't useful in the practical sense of things (maybe you're aren't going to use LISP ever in your life), but in the long term it's going to be useful because of the knowledge acquired by different paradigms you aren't too familiar with - and you could use some of you learned in what you already use today.
It's been awhile since university, but after I took a 3rd year CS course that required learning Lisp and writing Lisp programs, writing and thinking recursively was a snap. Not that I had problems with recursion before the course, but afterwards, it was 2nd nature. I also used CLOS in the course (University of Toronto), but it was so long ago, I barely remember what I did.