You can start looking for (free) imeplementations here: http://www.cliki.net/Common%20Lisp%20implementation or for commercial and free: http://alu.cliki.net/implementation
Some Lisp systems include interpreters, but it's also very common for them to be compilers. SBCL, for example, doesn't have an interpreter stage, everything you type is compiled to native code before execution.
Also, "functional programming" is usually taken to mean writing functions that only return values, rather than causing side effects in the global environment or mutating their arguments. Lisp supports functional programming (and Paul Graham seems to religiously endorse it), but it also supports many other styles of programming; the flexibility to mix and match styles where appropriate is a very appealing aspect of Common Lisp.
You're right, of course, about functional programming being only a single facit of Lisp's repertoire.
I've read (not sure where; things are starting to blur together) that CLOS (Common List Object System?) can be, in large part, implemented as Common Lisp macros. In fact, in one of the chapters of Graham's book, he simulates parts of CLOS.
It's this maleable nature of Lisp that has me so intrigued.
Want to process data in a stack-based, post-fix way, like Forth? No problem, write some macros. Like the Object Way better than the Functional Way? Easy. More macros.
The idea of growing a language toward the problem space, building up layers of abstraction until Lisp (or a bunch of macros, anyway) reflects your problem space, and its solutions, is, well, Way Cool.
I've haven't gotten very far into it, as I now need to find a Lisp interpreter. So, I'll start that search later today.
Lisp's syntax will take a little getting used to. In common languages like Python, C/C++, Java, etc., function calls look like this:
doSomething(arg1, arg2)
In Lisp, function calls look like this:
(doSomething arg1 arg2)
The parentheses surround everything and there's no punctuation, save spaces between tokens.
But I'm keenly interested. Functions are first-class objects, which means that you can pass them around like other language constructs/tokens. Everything is a list, essentially, so the basic syntax is easy to learn: everything is a nested list of nested lists. I think I'm finally starting to get a handle on this functional programming idea. More on all of this later.
Anyway, I'll write more when I have more to say... It's too soon yet.
5 Comments
Close this window Jump to comment formYou can start looking for (free) imeplementations here: http://www.cliki.net/Common%20Lisp%20implementation
or for commercial and free: http://alu.cliki.net/implementation
Good luck!
03:12
Thank you for the links.
I list of Lisp links (say that 10x really fast) may in on the horizon.
My little project seems to have a benefactor, or sorts.
Thanks again.
05:17
For what it's worth...
Some Lisp systems include interpreters, but it's also very common for them to be compilers. SBCL, for example, doesn't have an interpreter stage, everything you type is compiled to native code before execution.
Also, "functional programming" is usually taken to mean writing functions that only return values, rather than causing side effects in the global environment or mutating their arguments. Lisp supports functional programming (and Paul Graham seems to religiously endorse it), but it also supports many other styles of programming; the flexibility to mix and match styles where appropriate is a very appealing aspect of Common Lisp.
07:34
Hi, Zach,
Thanks for the comment.
You're right, of course, about functional programming being only a single facit of Lisp's repertoire.
I've read (not sure where; things are starting to blur together) that CLOS (Common List Object System?) can be, in large part, implemented as Common Lisp macros. In fact, in one of the chapters of Graham's book, he simulates parts of CLOS.
It's this maleable nature of Lisp that has me so intrigued.
Want to process data in a stack-based, post-fix way, like Forth? No problem, write some macros. Like the Object Way better than the Functional Way? Easy. More macros.
The idea of growing a language toward the problem space, building up layers of abstraction until Lisp (or a bunch of macros, anyway) reflects your problem space, and its solutions, is, well, Way Cool.
I just can't wait to get there.
13:33
One final comment about funtional programming:
It's bantied about in Python Land (another language I use regularly) quite a bit, but I've not come across a decent explanation.
After seeing a number of Lisp examples of FP, I get it now. Where before, though I was aware of it, I didn't really get it.
See? Lisp is already helping me sort out some concepts.
Niiice.
13:36