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 use Emacs everyday as it is the standard editor for Erlang.
I decided as my New Years Resolution to learn to programme eLisp. I decided that writing a book about eLisp was the best way to learn.
I have make pretty good progress:
Learn eLisp For Emacs
The strategic structure of the book is
getting started/basics
more advanced eLisp
writing a minor mode
writing a major mode
I have got through the basics (ie the first of these 4 points), covering:
evaluating expressions
debugging
adding menu items/toolbars
loading your own emacs files
etc, etc
If you are writing a book about a programming language you usually start by knowing the language well - well I don't - so my major problem now is a completeness problem:
How do I know that I have covered all the features that an Emacs programmer should have mastered?
How do I ensure that there aren't gaps in the content?
So I thought I would address these by asking the community here. My question is What Is Missing From My Table Of Contents? (in particular what should the more advanced eLisp Section contain).
Now that's an interesting way to learn a language...
I think you've probably skipped a bunch of the fundamentals in the getting started/basics section. If you've not already read it, I recommend reading "An Introduction To Programming In Emacs Lisp" (at gnu.org), which covers what I'd expect to see in the "basics" portion. I won't bother cut/paste the table of contents.
As far as knowing when you've written a complete book... Well, once you've re-written the Emacs Lisp manual in "how to" form, you know you're done. Alternatively, if you've written a book that can be used to answer/interpret all of the elisp and emacs questions, then you've probably got decent coverage.
What advanced features could you write about? There's advice, process communication, non-ASCII text, syntax tables, abbrevs, text properties, byte compilation, display tables, images, and a bunch more in the manual.
Note: The proper capitalization of elisp is either all lowercase, or possibly an uppercase E. The GNU documentation doesn't use "elisp" very much at all (mostly as a directory name, all lowercase), it prefers "Emacs Lisp."
Note: In the current version of your book, you treat global variables negatively. It's probably worth reading the RMS paper to gain some insight into the design decisions made, specifically on global variables as well as dynamic binding (the latter which you've yet to cover, which is a key (basic) concept which you've already gotten wrong in your book).
Instead of asking the community here, why not use what the community already offers? Review all the questions tagged "elisp" and see where they fit it your book. A survey of what people actually want to understand could be some of the best information you will get.
"I have read both the GNU manuals - but they are not so much use if you don't know Lisp/elisp."
Tip: Emacs is not much use if you don't know Lisp.
Not really true, of course, but you get the idea. This one is really true:
Tip: Emacs is much, much, much, much more useful if you know Lisp. Not to mention more fun.
Wrt what to learn:
symbols (they are simple objects, with properties -- not just identifiers)
lists -- cons cells, list structure (including modification/sharing)
evaluation
function application
regexps
text/overlay/string properties (values can be any Lisp entities)
buffers and windows
I'd suggest you'll take a look what the two Info manuals included with Emacs Emacs Lisp Intro "An Introduction to Programming in Emacs Lisp" and Elisp "The Emacs Lisp Reference Manual" already have to offer and then decide what you would like to add to or do differently than those.
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.
I've read JRM's Syntax-rules Primer for the Merely Eccentric and it has helped me understand syntax-rules and how it's different from common-lisp's define-macro. syntax-rules is only one way of implementing a syntax transformer within define-syntax.
I'm looking for two things, the first is more examples and explanations of syntax-rules and the second is good sources for learning the other ways of using define-syntax. What resources do you recommend?
To answer your second question: syntax-case is the other form that goes inside define-syntax. Kent Dybvig is the primary proponent of syntax-case, and he has a tutorial on using it [PDF].
I also read the PLT Scheme documentation on syntax-case for a few more examples, and to learn about the variation in implementation.
The JRM Syntax-rules primer is quite good, but Chapter 36 of Programming Languages: Application and Interpretation, by Shriram Krishnamurti http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/) also has good coverage of writing Scheme macros. That material has been used and improved over several short articles, tech reports, etc, over the past 10 years, so it's not a 'this was true about the X implementation of Scheme in 1983 that is no longer accessible' paper.
The list of resources at The Scheme Cookbook is a great place to start.
If you prefer papers, then don't hessitate to visit readscheme.org.
Fear of Macros is a practical guide for using macros in Racket. It shows many ways of using define-syntax. The material may not be completely applicable to Scheme, but you might find some of the examples useful for knowing what can be done.