[4] Several implementations of the Common Lisp standard are available, including free and open-source software and proprietary products.

It also supports optional type annotation and casting, which can be added as necessary at the later profiling and optimization stages, to permit the compiler to generate more efficient code.

Similarly, the compiler can be told on a per-module or per-function basis which type of safety level is wanted, using optimize declarations.

Common Lisp includes CLOS, an object system that supports multimethods and method combinations.

A second edition (known as CLtL2), published in 1990, incorporated many changes to the language, made during the ANSI Common Lisp standardization process: extended LOOP syntax, the Common Lisp Object System, the Condition System for error handling, an interface to the pretty printer and much more.

Various extensions and improvements to Common Lisp (examples are Unicode, Concurrency, CLOS-based IO) have been provided by implementations and libraries.

For Common Lisp, operators that define names in the function namespace include defun, flet, labels, defmethod and defgeneric.

These names were coined in a 1988 paper by Richard P. Gabriel and Kent Pitman, which extensively compares the two approaches.

This means that callers may remain entirely unaware of the secondary values being there if they have no need for them, and it makes it convenient to use the mechanism for communicating information that is sometimes useful, but not always necessary.

Bindings established in this environment have dynamic extent, which means that a binding is established at the start of the execution of some construct, such as a let block, and disappears when that construct finishes executing: its lifetime is tied to the dynamic activation and deactivation of a block.

Global variables are frowned upon in computer science as potential sources of error, because they can give rise to ad-hoc, covert channels of communication among modules that lead to unwanted, surprising interactions.

In Common Lisp implementations which support multithreading, dynamic scopes are specific to each thread of execution.

And that variable must be made thread-local (or else a big mutex must be used) so the scheme doesn't break under threads: dynamic scope implementations can take care of this also.

If that block of code is re-entered by the invocation of a lexical closure, it is invalid for the body of that closure to try to transfer control to a tag via GO: When the TAGBODY is executed, it first evaluates the setf form which stores a function in the special variable *stashed*.

Firstly, references to variables and functions can be compiled to efficient machine code, because the run-time environment structure is relatively simple.

In many cases it can be optimized to stack storage, so opening and closing lexical scopes has minimal overhead.

Doug Hoyte's book Let Over Lambda extends the discussion on macros, claiming "Macros are the single greatest advantage that lisp has as a programming language and the single greatest advantage of any programming language."

Macros can be considered functions that accept and return S-expressions – similar to abstract syntax trees, but not limited to those.

However, packages don't solve the type 1 capture of references to standard Common Lisp functions and operators.

Whereas the Common Lisp library symbols are external, and frequently imported into or made visible in user-defined packages.

Common Lisp solves the problem of the shadowing of standard operators and functions by forbidding their redefinition.

Because it redefines the standard operator do, the preceding is actually a fragment of non-conforming Common Lisp, which allows implementations to diagnose and reject it.

Peter Norvig explains how many Design Patterns are simpler to implement in a dynamic language with the features of CLOS (Multiple Inheritance, Mixins, Multimethods, Metaclasses, Method combinations, etc.).

As a dynamic object system, CLOS allows changes at runtime to generic functions and classes.

Common Lisp allows type declarations and provides ways to influence the compiler code generation policy.

The progv special operator allows to create lexical bindings programmatically, while packages are also manipulable.

Common Lisp is sometimes termed a Lisp-2 and Scheme a Lisp-1, referring to CL's use of separate namespaces for functions and variables.

In addition, implementations tend to come with extensions, which provide functionality not covered in the standard: Free and open-source software libraries have been created to support extensions to Common Lisp in a portable way, and are most notably found in the repositories of the Common-Lisp.net[20] and CLOCC (Common Lisp Open Code Collection)[21] projects.

Standard declarations to optimize compilation (such as function inlining or type specialization) are proposed in the language specification.

Some Unix-based implementations (CLISP, SBCL) can be used as a scripting language; that is, invoked by the system transparently in the way that a Perl or Unix shell interpreter is.