Most Common Lisp is actually compiled, not interpreted.
If one compiles code or loads compiled code to something like SBCL and dumps an image, you can both run it directly from that image AND have still have the development tools included.
Some Common Lisp implementations also have delivery tools which create applications without development tools. Some applications though include the development tools, because they are thought to be extended by the user. For example a CL-based CAD system might exposed Common Lisp as the scripting language for CAD extensions.
Of course many implementations do compile to machine code but there are also a few that don't (clisp, ecl, abcl). It is really complicated to talk about languages that have multiple implementations. That is why I went with "interpreter". That was pretty lazy of me :).
But you didn't say anything about the original question. Have you seen Common Lisp code deployed as an executable or as source code?
Interpreted in Lisp usually means 'executing s-expressions by a Lisp interpreter'.
ECL and CLISP also use compilers. ECL usually compiles to C, which then is compiled to native code via a C compiler. CLISP has its own virtual machine, which is the target of its compiler. Don't know what ABCL does, would have to look it up - but in the end it usually would execute JVM code, which gets compiled by its JIT compiler.
Question of code deployment. I have seen deployment as an executable, deployment as an executable with also loads compiled code (for patches) and deployment as source code. Especially commercial applications and/or end-user applications tend to deploy as executable. For example ScoreCloud is a LispWorks application as an executable and can be bought on Apple's Mac app store.
My Lisp Machine at home boots into a Lisp image which contains a whole operating system as compiled Lisp code. That's exotic, but many other Lisp development environments already come as compiled Lisp executable. For example on the Mac and on ARM64/Linux I use LispWorks. On the Mac it is the usual Mac application bundle, where the executable already contains much of the IDE and then loads some code on demand from compile code files.
The word "compiler" is so overloaded that every time someone mentions one it turns into an argument. This is the whole transpiler vs compiler vs interpreter vs JIT argument. The trouble is that sometimes some programmers implement all of them (myself included).
> CLISP has its own virtual machine, which is the target of its compiler
Yes, generally any source to byte-code translator is a compiler. The byte-code then can either be interpreted or compiled, too. Since the default CPython implementation interpreted the byte code, it was said it's an interpreter - but strictly speaking it is not.
Originally interpreters were implementations which execute source code - which in Lisp is widely available. For example SBCL for a long time only had a native code AOT compiler, but now also includes s-expressions.
Famous is also the Lisp interpreter in Lisp from McCarthy, where he defined the core language in itself. See the paper from Paul Graham about that: http://languagelog.ldc.upenn.edu/myl/llog/jmc.pdf
That's a very primitive Lisp interpreter - many real ones are implemented in C, Assembler...
Just be aware, that in the Lisp world 'Interpreter' means something very specific: an interpreter of the source language.
Fair enough. My assumption was that you would consider a source to bytecode compiler an interpreter (to be fair most people do). The next time I say something about Common Lisp I will list all the implementations instead of saying something as simplistic as "compiler" or "interpreter".
It's also complicated because some implementations support several modes. ECL for example has a Lisp interpreter, a byte-code compiler&interpreter and a native compilation via C. All code variants can work together and call each other.
To be clear, ABCL (if I understand correctly) compiles to JVM bytecode, which is analogous to "machine code" in the context of its target platform (and hell, is sometimes even literally machine code if you lack any semblance of sanity: https://en.wikipedia.org/wiki/Java_processor).
And ECL does ultimately compile down to machine code if you include "compile the resulting C output" in the compilation process, though this is optional.
If one compiles code or loads compiled code to something like SBCL and dumps an image, you can both run it directly from that image AND have still have the development tools included.
Some Common Lisp implementations also have delivery tools which create applications without development tools. Some applications though include the development tools, because they are thought to be extended by the user. For example a CL-based CAD system might exposed Common Lisp as the scripting language for CAD extensions.