>>21
Somewhat true. Almost all the code I write is ANSI CL compatible. When I have to write code that goes beyond the ANSI standard, I have a few options:
1) If it's some common functionality that is widely available, like FFI, networking, gray streams, the MOP and so on, I use a lightweight library which acts as a compatibility layer. All the library does is unify various implementation's internals under a consistent well-documented API. This way, you can retain compatibility even if you switch implementations. Some of these libraries tend to be de-facto standards.
2) If no such comptibility layer exists, you can write your own. This is done by first deciding on a public API, then you implement each function using each of the implemntation's internals. It could look like:
#+sbcl
(defun some-fun (...) ...)
#+ccl
(defun some-fun (...) ...)
#+clisp
(defun some-fun (...) ...)
#+excl
(defun some-fun (...) ...)
...
#-(or sbcl ccl clisp excl ...)
(defun some-fun (&rest args)
(declare (ignore args))
(error "SOME-FUN isn't supported in your implementation"))
I've done such a thing to extend certain functionality beyond ANSI CL(for example, it can be used to do environment access, or implementing a MOP,...), and it's usually not too hard to do it if you have access to the implementations' source code and you use SLIME, which is very helpful when digging in internals.
3)The final option is to write unportable code, but this is usually not the best idea. It can make some sense when the functionality you want is not obtainable anywhere else, and is usually very implementation dependent and low-level. A good example would be SB-HEAPDUMP, which is a SBCL port which allows dumping in-memory objects to disk for persistance (keep in mind that there are many portable persitance libs), and can be used to implement continuations in a more low-level way(continuations can also be done in a portable way using a lib which can perform CPS transforms - there are a few). Other similar examples could be implementation-tuned crypto libs which depend on how an implementation performs optimizations, which tend to be different across lisps.
tl;dr: Most of the Lisp code in the wild is portable ANSI CL, or de-facto portable accross implementations. If you have certain needs for higher than usual performance, you can write unique implementation dependent code which could not be ported to other implementations since it depends on compiler internals way too much.