I write portable code and use libraries which abstract away implementation specific stuff so it will be easy to run on any other conforming implementation should the need arise.
The community is quite responsible when it comes to portability and utility libraries which help with it, but on top of that Quicklisp maintainer tests library compilation on most major implementations and reports bugs.
It baffles me that this notion of Lisp as an interpreted language still persists. Common Lisp is a compiled language for all non toy implementations, and in general Lisps have had compilers for decades.
Though, to be fair, a 'real' Lisp interpreter often provides more interactive features. The Lisp interpreter sees the code as Lisp data and interprets that. This enables a few things.
You don't need an interpreter for that. SBCL (as does other compilers) always compiles an expression prior to executing it, even when it's code as data passed to EVAL.
> You don't need an interpreter for that. SBCL (as does other compilers) always compiles an expression prior to executing it, even when it's code as data passed to EVAL.
True, but that's not what a Lisp interpreter does and provides.
I was talking about the difference between an interpreter and a (possibly interactive) compiler. The interpreter works over source code as Lisp data. The compiler does not - it does not matter that the compiler compiles individual forms. At runtime the code is machine code. With an interpreter the code is Lisp data.
Think about it: What difference could that make, if the code gets actually executed by a real Lisp interpreter?
There are half a dozen CL implementations, for various purposes:
sbcl, ccl and open source implementations with built in compilers.
ecl is similar, but designed to be easily embeddable in C applications
clasp is a newer one that's built on top of llvm (still unstable, as far as I can tell, but actively developed)
abcl targets the jvm platform and, consequently, can gives you access to all the libraries in the Java ecosystem.
And then there are commercial implementations like LispWorks and Allegro that have their own benefits: Lispworks has, I here, a very nice cross-platform GUI library and, although I don't know much about it, I suspect Allegro has it's own perks.
And, because of the community's emphasis on avoiding implementation-specific behaviors, which implementation you choose isn't that big a deal: I regularly develop a project under multiple implementations, and seldom have major issues doing so.
I write portable code and use libraries which abstract away implementation specific stuff so it will be easy to run on any other conforming implementation should the need arise.
The community is quite responsible when it comes to portability and utility libraries which help with it, but on top of that Quicklisp maintainer tests library compilation on most major implementations and reports bugs.