Pity about the name though. It would've been more appropriate to name it on one of the "victorious" tyrants of our age. Perhaps one of "Columbus", "Churchill", "Reagan", or for that touch of infamy "Nixon". Pfft.
SBCL doesn't currently have whole-program optimization. Its focus has been on standard Common Lisp, which is quite dynamic and can't make the kind of closed-world assumption used by whole-program optimization (i.e. we know the entire program at compile-time). It has quite a lot of optimizations, but they operate function-at-a-time.
Its predecessor, CMUCL, did have a mode called "block compilation" that has some similarities: http://common-lisp.net/project/cmucl/doc/cmu-user/compiler-h.... It isn't currently present in SBCL; it was axed as part of the CMUCL->SBCL cleanup. I've occasionally heard suggestions of adding similar functionality to SBCL, but I'm not sure there's any active work on it.
'whole program optimization' is also kind of unpractical, since these compilers are typically very slow.
Lucid CL had two compilers, a fast incremental one and a slow one, capable of block compilation. KCL (the early Lisp to C compiler) used block compilation. LispWorks should also support it in some form.
Usually 'block compilation' in Lisp means compiling a set of functions together, instead of compiling each function individually. This block compilation for example then can reduce function call overhead.
In its more primitive for a single file of source is seen as a block. But compilers also support block compilation of several files together.
Block compilation in Common Lisp was and is used mostly for application delivery, where the program is static and dynamic features can be removed. Thus a delivered program is more static, but also 'faster'.
> Block compilation in Common Lisp was and is used mostly for application delivery
The main place I've personally encountered people who care about block compilation in CL isn't so much delivery (as in, to an external client) as getting it ready to run "for real", mostly numerical stuff that is being prepared to run in batch mode on a giant dataset. I guess that's a kind of deployment though, even if the operator and developer is the same research group.
I could be imagining things, but one downside I think I see in not having block compilation in SBCL is that people writing numerical code targeting it have a tendency to pack as much as possible into flet and labels, using one big function as the poor man's compilation block (since within a single function most of CL's dynamic features aren't in play).
I tend not to like code like that when hacking on it. Besides often reading less clearly and sometimes leading to duplicate or near-duplicate code, separate functions are more flexible: they can be dynamically redefined while tinkering with things, they can be called on their own, etc. Of course, that's precisely why the compiler can't perform certain optimizations on full calls. But I think people would be more free with the defun if they knew the compiler would take care of optimizing everything when deployed.
That's often called 'delivery' in Lisp. It means creating an executable application or library. It does not mean the actual act of shipping something to external clients.
If you compile your code to create an application which then is used in 'production' (internal or external), this is the process of 'delivery'.
Pity about the name though. It would've been more appropriate to name it on one of the "victorious" tyrants of our age. Perhaps one of "Columbus", "Churchill", "Reagan", or for that touch of infamy "Nixon". Pfft.