The standard way for the user to interact with a Common Lisp implementation is
via a read-eval-print loop: the system repeatedly
reads a form from some input source (such as a keyboard or a disk file),
evaluates it, and then prints the value(s) to some output sink (such as a
display screen or another disk file). Any form (evaluable
data object) is acceptable; however, certain special forms are specifically
designed to be convenient for use as top-level forms,
rather than as forms embedded within other forms in the way
that (+ 3 4)
is embedded within (if p (+ 3 4) 6).
These top-level special forms may be used to define globally named
functions, to define macros, to make declarations,
and to define global values for special variables.

It is not illegal to use these forms at other than top level,
but whether it is meaningful to do so depends on context.
Compilers, for example, may not recognize these forms properly
in other than top-level contexts. (As a special case, however,
if a progn form appears at top level, then all forms
within that progn are considered by the compiler to be top-level
forms.)

X3J13 voted in March 1989 (DEFINING-MACROS-NON-TOP-LEVEL)
to clarify that, while defining forms normally appear at top level,
it is meaningful to place them in non-top-level contexts.
All defining forms that create functional objects from code appearing
as argument forms must ensure that
such argument forms refer to the enclosing lexical environment.
Compilers must handle defining forms properly in all situations,
not just top-level contexts. However, certain
compile-time side effects of these defining forms are performed only
when the defining forms occur at top level (see section 25.1).

Compatibility note: In MacLisp, a top-level progn is considered to
contain top-level forms only if the first form is (quote compile).
This odd marker is unnecessary in Common Lisp.

Macros are usually defined by using the special form defmacro.
This facility is fairly complicated; it is described in chapter 8.