clos.tex

%Part{CLOS, Root = "CLM.MSS"}
%%% Chapter of Common Lisp Manual.  Copyright 1984, 1987, 1988, 1989 Guy L. Steele Jr.

\clearpage\def\pagestatus{FINAL PROOF}


%\begingroup

\ifx \rulang\Undef
  \def\CLOS{Common Lisp Object System}
  \def\OS{Object System}
\else %RUSSIAN
  \def\CLOS{Объектная система Common Lisp'а}
  \def\OS{Объектная система}
\fi

\def\sub{_}

\mathchardef\mhyphen="2D

\ifx \rulang\Undef

\chapter{Common Lisp Object System}
\label{CLOS}

Authors: Daniel G.~Bobrow, Linda G.~DeMichiel,
Richard P.~Gabriel, Sonya E.~Keene, Gregor Kiczales,
and David A.~Moon

% \begin{new}
% X3J13 voted in June 1988
% \issue{CLOS}
% to adopt the first two chapters (of three) of the
% Common Lisp Object System specification
% as a part of the forthcoming draft Common Lisp standard.
% \end{new}

This chapter presents the bulk of the first two chapters of the
Common Lisp Object System specification; it is substantially
identical to these two specification chapters as previously published elsewhere
\cite{SIGPLAN-CLOS,LASC-CLOS-PART-1,LASC-CLOS-PART-2}.
I have edited the material only very lightly
to conform to the overall style of this book and to save a substantial
number of pages by using a typographically condensed presentation.
I have inserted a small
number of bracketed remarks, identified by the initials GLS.
The chapter divisions of the original specification have become
section divisions in this chapter; references to the three chapters
of the original specification now refer to the three ``parts'' of the
specification.
(See the Acknowledgments to this second edition for
acknowledgments to others who contributed to the Common Lisp Object System specification.)
This is not the last word on CLOS;
X3J13 may well refine this material further.
Keene has written a good tutorial introduction to CLOS~\cite{KEENE}.

\noindent\hbox to \textwidth{\hss---Guy L. Steele Jr.}
\vskip 8pt plus 3pt minus 2pt

\section{Programmer Interface Concepts}

The \CLOS\ (CLOS) is an object-oriented extension to Common Lisp. It is based on
generic functions, multiple inheritance, declarative method
combination, and a meta-object protocol.

The first two parts of this specification describe
the standard Programmer Interface for the \CLOS.  The first part,
Programmer Interface Concepts,
contains a description of the concepts of the \CLOS, and the second part,
Functions in the Programmer Interface,
contains a description of the functions and macros in the \CLOS\
Programmer Interface.  The third part, The \CLOS\ Meta-Object
Protocol, explains how the \CLOS\ can be customized.

The fundamental objects of the \CLOS\ are classes, instances,
generic functions, and methods. 

A \emph{class} object determines the structure and behavior of a set
of other objects, which are called its \emph{instances}. 
Every Common Lisp object is an \emph{instance} of a class.  The class of an
object determines the set of operations that can be performed on the object. 

A \emph{generic function} is a function whose behavior depends on the
classes or identities of the arguments supplied to it.  A generic
function object contains a set of methods, a lambda-list, a
method combination type, and other information.  The \emph{methods} define
the class-specific behavior and operations of the generic function; a
method is said to \emph{specialize} a generic function.  When invoked,
a generic function executes a subset of its methods based on the
classes of its arguments.

A generic function can be used in 
the same ways as an ordinary function in Common Lisp; in
particular, a generic function can be used as an argument to 
\cdf{funcall} and \cdf{apply} and can be given a global name.%or a local name.

A \emph{method} is an object that contains a method function, a sequence of
\emph{parameter specializers} that specify when the given method is
applicable, and a sequence of \emph{qualifiers} that is used by the
\emph{method combination} facility to distinguish among methods.  Each
required formal parameter of each method has an associated parameter
specializer, and the method will be invoked only on arguments that
satisfy its parameter specializers.

The method combination facility controls the selection of methods, the
order in which they are run, and the values that are returned by the
generic function.  The \CLOS\ offers a default method combination type
and provides a facility for declaring new types of method combination.

\subsection{Error Terminology}
\label{Error-Terminology-SECTION}

%The terminology used in this chapter to describe erroneous
%situations differs from the terminology used in the first edition.
%The new terminology involves \emph{situations};
A situation is the evaluation of an expression in some
specific context. For example, a situation might be the invocation of
a function on arguments that fail to satisfy some specified
constraints.

In the specification of the \CLOS, the behavior of programs in all situations
is described, and the options available to the implementor are defined. No
implementation is allowed to extend the syntax or semantics of the \OS\ except
as explicitly defined in the \OS\ specification. In particular, no
implementation is allowed to extend the syntax of the \OS\ in such a way that
ambiguity between the specified syntax of the \OS\ and those extensions is
possible.

\begin{flushdesc}
\item[``When situation \emph{S} occurs, an error is signaled.'']

This terminology has the following meaning:

\begin{itemize}

\item  If this situation occurs, an error will be signaled in
the interpreter and in code compiled under all compiler safety
optimization levels.

\item  Valid programs may rely on the fact that an error will be
signaled in the interpreter and in code compiled under all compiler
safety optimization levels.

\item  Every implementation is required to detect such an error
in the interpreter and in code compiled under all compiler safety
optimization levels.

\end{itemize}

\item[``When situation \emph{S} occurs, an error should be signaled.'']

This terminology has the following meaning:

\begin{itemize}

\item  If this situation occurs, an error will be signaled at
least in the interpreter and in code compiled under the safest
compiler safety optimization level.

\item  Valid programs may not rely on the fact that an error will be
signaled.

\item  Every implementation is required to detect such an error
at least in the interpreter and in code compiled under the safest
compiler safety optimization level.

\item  When an error is not signaled, the results are undefined (see
below).

\end{itemize}
  
\item[``When situation \emph{S} occurs, the results are undefined.'']
  
  This terminology has the following meaning:

  \begin{itemize}
    
  \item  If this situation occurs, the results are unpredictable.  The
    results may range from harmless to fatal.
    
  \item  Implementations are allowed to detect this situation and
    signal an error, but no implementation is required to detect the
    situation.
    
  \item  No valid program may depend on the effects of this
    situation, and all valid programs are required to treat the effects 
    of this situation as unpredictable.
    
  \end{itemize}
 
\item[``When situation \emph{S} occurs, the results are unspecified.'']
  
  This terminology has the following meaning:
  
  \begin{itemize}
    
  \item  The effects of this situation are not specified in
    the \OS, but the effects are harmless.
    
  \item  Implementations are allowed to specify the effects of
    this situation.
    
  \item  No portable program can depend on the effects of this
    situation, and all portable programs are required to treat the situation
    as unpredictable but harmless.
    
  \end{itemize}
  
\item[``The \CLOS\ may be extended to cover situation \emph{S}.'']

The meaning of this terminology is that an implementation is free to treat
situation \emph{S} in one of three ways:

\begin{itemize}

\item  When situation \emph{S} occurs, an error is signaled at least
in the interpreter and in code compiled under the safest compiler
safety optimization level.

\item  When situation \emph{S} occurs, the results are undefined.

\item  When situation \emph{S} occurs, the results are defined and
specified.

\end{itemize}


\noindent
In addition, this terminology has the following meaning:

\begin{itemize}

\item  No portable program can depend on the effects of this
situation, and all portable programs are required to treat the situation
as undefined.

\end{itemize}


\item[``Implementations are free to extend the syntax \emph{S}.'']

This terminology has the following meaning:

\begin{itemize}

\item  Implementations are allowed to define unambiguous extensions
to syntax \emph{S}.

\item  No portable program can depend on this extension, and
all portable programs are required to treat the syntax
as meaningless.

\end{itemize}
\end{flushdesc}

The \CLOS\ specification may disallow certain extensions while allowing others.

\subsection{Classes}
\label{Classes-SECTION}

A \emph{class} is an object that determines the structure and behavior 
of a set of other objects, which are called its \emph{instances}.

A class can inherit structure and behavior from other classes.  
A class whose definition refers to other classes for the purpose of
inheriting from them is said to be a \emph{subclass} of each of
those classes.  The classes that are designated for purposes of
inheritance are said to be \emph{superclasses}
of the inheriting class.

A class can have a \emph{name}. The function \cdf{class-name} takes a
class object and returns its name. The name of an anonymous class is
\cdf{nil}.  A symbol can \emph{name} a class.  The function 
\cdf{find-class} takes a symbol and returns the class that the symbol
names. A class has a \emph{proper name} if the name is a symbol
and if the name of the class
names that class.  That is, a class~\emph{C} has the \emph{proper
name}~\emph{S} if \emph{S}~= \cd{(class-name \emph{C})} and \emph{C}~= \cd{(find-class
\emph{S})}.  Notice that it is possible for \cd{(find-class $S_1$)}
= \cd{(find-class $S_2$)} and $S_1\neq S_2$.
If \emph{C}~= \cd{(find-class \emph{S})}, we say that \emph{C} is the \emph{class named}
\emph{S}.

A class $C_{1}$ is a \emph{direct superclass} of a class
$C_{2}$ if $C_{2}$ explicitly designates $C_{1}$ as a
superclass in its definition.  In this case, $C_{2}$ is a \emph{direct
  subclass} of $C_{1}$.  A class $C_{n}$ is a \emph{superclass} of a
class $C_{1}$ if there exists a series of 
classes $C_{2},\ldots,C_{n-1}$
such that $C_{i+1}$ is a
direct superclass of $C_{i}$ for $1 \leq \emph{i} < \emph{n}$.  In this case, 
$C_{1}$ is a \emph{subclass} of $C_{n}$.  A class is
considered neither a superclass nor a subclass of itself.  That is, if
$C_{1}$ is a superclass of $C_{2}$, then $C_{1} \neq
C_{2}$.  The set of classes consisting of some given
class \emph{C} along with all of its superclasses is called ``\emph{C} and its
superclasses.''

Each class has a \emph{class precedence list}, which is a total ordering
on the set of the given class and its superclasses.  The total ordering
is expressed as a list ordered from most specific to least specific.
The class precedence list is used in several ways.  In general, more
specific classes can \emph{shadow}, or override, features that would
otherwise be inherited from less specific classes.  The method selection
and combination process uses the class precedence list to order methods
from most specific to least specific. 
 
When a class is defined, the order in which its direct superclasses
are mentioned in the defining form is important.  Each class has a
\emph{local precedence order}, which is a list consisting of the
class followed by its direct superclasses in the order mentioned
in the defining form.

A class precedence list is always consistent with the local precedence
order of each class in the list.  The classes in each local precedence
order appear within the class precedence list in the same order.  If
the local precedence orders are inconsistent with each other, no class
precedence list can be constructed, and an error is signaled.
The class precedence list and its computation is discussed
in section \ref{Determining-the-Class-Precedence-List-SECTION}.

Classes are organized into a \emph{directed acyclic graph}.  There are
two distinguished classes, named \cdf{t} and \cdf{standard-object}.
The class named \cdf{t} has no superclasses.  It is a superclass of
every class except itself.  The class named \cdf{standard-object} is
an instance of the class \cdf{standard-class} and is a superclass of
every class that is an instance of \cdf{standard-class} except itself.

There is a mapping from the Common Lisp Object System class space into
the Common Lisp type space.  Many of the standard Common Lisp types
have a corresponding
class that has the same name as the type.  Some Common Lisp types do
not have a corresponding class.  The integration of the type and class
systems is discussed in section~\ref{Integrating-Types-and-Classes-SECTION}.

Classes are represented by objects that are themselves
instances of classes.  The class of the class of an object is termed
the \emph{metaclass} of that object.  When no misinterpretation is
possible, the term \emph{metaclass} will be used to refer to a class
that has instances that are themselves classes.  The metaclass
determines the form of inheritance used by the classes that are its
instances and the representation of the instances of those classes.
The \CLOS\ provides a default metaclass, \cdf{standard-class}, that is
appropriate for most programs.  The meta-object protocol provides
mechanisms for defining and using new metaclasses.

Except where otherwise specified, all classes mentioned in this
chapter are instances of the class \cdf{standard-class}, all generic
functions are instances of the class \cdf{standard-generic-function},
and all methods are instances of the class \cdf{standard-method}.

\subsubsection{Defining Classes}

The macro \cdf{defclass} is used to define a new named class.
The definition of a class includes the following:

\begin{itemize}

\item  The name of the new class. For newly defined classes
this is a proper name.

\item  The list of the direct superclasses of the new class. 

\item  A set of \emph{slot specifiers}.  Each slot specifier
includes the name of the slot and zero or more \emph{slot options}.  A
slot option pertains only to a single slot. If a class definition
contains two slot specifiers with the same name, an error is signaled.

\item  A set of \emph{class options}.  Each class option pertains 
to the class as a whole.
\end{itemize}

The slot options and class options of the \cdf{defclass} form provide
mechanisms for the following:

\begin{itemize}
\item  Supplying a default initial value form for a given slot.  

\item  Requesting that methods for generic functions
be automatically generated for reading or writing slots. 

\item  Controlling whether a given slot is shared by instances
of the class or whether each instance of the class has its own slot.

\item  Supplying a set of initialization arguments and initialization
argument defaults to be used in instance creation.

%\item  Requesting that a constructor function be automatically
%generated for making instances of the new class.

\item  Indicating that the metaclass is to be other than the default.

\item  Indicating the expected type for the value stored in the slot.

\item  Indicating the documentation string for the slot.
\end{itemize} 

\subsubsection{Creating Instances of Classes}

The generic function \cdf{make-instance} creates and returns a new
instance of a class.  The \OS\ provides several mechanisms for
specifying how a new instance is to be initialized.  For example, it
is possible to specify the initial values for slots in newly created
instances either by giving arguments to \cdf{make-instance} or by
providing default initial values.

Further initialization activities
can be performed by methods written for generic functions that are
part of the initialization protocol.  The complete initialization
protocol is described in
section~\ref{Object-Creation-and-Initialization-SECTION}.

\subsubsection{Slots}

An object that has \cdf{standard-class} as its metaclass has zero or
more named slots.  The slots of an object are determined by the class
of the object.  Each slot can hold one value.  The name of a slot is a
symbol that is syntactically valid for use as a variable
name.

When a slot does not have a value, the slot is said to be \emph{unbound}.  When
an unbound slot is read, the generic function \cdf{slot-unbound} is invoked. The
system-supplied primary method for \cdf{slot-unbound} signals an error. 

The default initial value form for a slot is defined by the \cd{:initform} slot
option. When the \cd{:initform} form is used to 
supply a value, it is evaluated in the lexical environment in which
the \cdf{defclass} form was evaluated. The \cd{:initform} along with
the lexical environment in which the \cdf{defclass} form was evaluated
is called a \emph{captured} \cd{:initform}.
See section~\ref{Object-Creation-and-Initialization-SECTION}.

A \emph{local slot} is defined to be a slot that is visible to exactly
one instance, namely the one in which the slot is allocated.  A \emph{shared
  slot} is defined to be a slot that is visible to more than one instance of a
given class and its subclasses.

A class is said to \emph{define} a slot with a given name when
the \cdf{defclass} form for that class contains a slot specifier with
that name.  Defining a local slot does not immediately create a slot;
it causes a slot to be created each time an instance of the class is
created.  Defining a shared slot immediately creates a slot.

The \cd{:allocation} slot option to \cdf{defclass} controls the kind
of slot that is defined.  If the value of the \cd{:allocation} slot
option is \cd{:instance}, a local slot is created.  If the value of
\cd{:allocation} is \cd{:class}, a shared slot is created.

A slot is said to be \emph{accessible} in an instance of a class if
the slot is defined by the class of the instance or is inherited from
a superclass of that class.  At most one slot of a given name can be
accessible in an instance.  A shared slot defined by a class is
accessible in all instances of that class.  A detailed explanation of
the inheritance of slots is given in
section~\ref{Inheritance-of-Slots-and-Slot-Options-SECTION}.

\subsubsection{Accessing Slots}

Slots can be accessed in two ways: by use of the primitive function
\cdf{slot-value} and by use of generic functions generated by the 
\cdf{defclass} form.

The function \cdf{slot-value} can be used with any slot name
specified in the \cdf{defclass} form to access a specific slot
accessible in an instance of the given class.

The macro \cdf{defclass} provides syntax for generating methods to
read and write slots.  If a \emph{reader} is requested, a method is
automatically generated for reading the value of the slot, but no
method for storing a value into it is generated.  If a \emph{writer}
is requested, a method is automatically generated for storing a value
into the slot, but no method for reading its value is generated.  If
an \emph{accessor} is requested, a method for reading the value of
the slot and a method for storing a value into the slot are
automatically generated.  Reader and writer methods are implemented
using \cdf{slot-value}.

When a reader or writer is specified for a slot, the name of the
generic function to which the generated method belongs is directly
specified.  If the name specified for the writer option is the symbol
\emph{name}, the name of the generic function for writing the slot
is the symbol \emph{name}, and the generic function takes two
arguments: the new value and the instance, in that order.  If the name
specified for the accessor option is the symbol \emph{name}, the
name of the generic function for reading the slot is the symbol \emph{name}, and
the name of the generic function for writing the slot is 
the list \cd{(setf \emph{name})}.

A generic function created or modified by supplying reader, writer, or
accessor slot options can be treated exactly as an ordinary generic
function.

Note that \cdf{slot-value} can be used to read or write the value of a
slot whether or not reader or writer methods exist for that slot.
When \cdf{slot-value} is used, no reader or writer methods are
invoked.

The macro \cdf{with-slots} can be used to establish a lexical
environment in which specified slots are lexically available as if they
were variables.  The macro \cdf{with-slots} invokes the function 
\cdf{slot-value} to access the specified slots.

The macro \cdf{with-accessors} can be used to establish a lexical
environment in which specified slots are lexically available through
their accessors as if they were variables.  The macro 
\cdf{with-accessors} invokes the appropriate accessors to access the
specified slots. Any accessors specified by \cdf{with-accessors} must
already have been defined before they are used.

\subsection{Inheritance}
\label{Inheritance-SECTION}

A class can inherit methods, slots, and some \cdf{defclass} options
from its superclasses.  The following sections describe the inheritance of
methods, the inheritance of slots and slot options, and the inheritance of
class options.
 
\subsubsection{Inheritance of Methods}
\label{Inheritance-of-Methods-SECTION}

A subclass inherits methods in the sense that any method applicable to
all instances of a class is also applicable to all instances of any
subclass of that class.

The inheritance of methods acts the same way regardless of whether the
method was created by using one of the method-defining forms or by
using one of the \cdf{defclass} options that causes methods to be
generated automatically.

The inheritance of methods is described in detail in
section~\ref{Method-Selection-and-Combination-SECTION}.

\subsubsection{Inheritance of Slots and Slot Options}
\label{Inheritance-of-Slots-and-Slot-Options-SECTION}

The set of names of all slots accessible in an instance of a class
\emph{C} is the union of the sets of names of slots defined by \emph{C} and its
superclasses. The \emph{structure} of an instance is the set of names
of local slots in that instance.

In the simplest case, only one class among \emph{C} and its superclasses
defines a slot with a given slot name.  If a slot is defined by a
superclass of \emph{C}, the slot is said to be \emph{inherited}.  The
characteristics of the slot are determined by the 
slot specifier of the defining class.  Consider the defining class for
a slot \emph{S}.  If the value of the \cd{:allocation} slot
option is \cd{:instance}, then \emph{S} is a local slot and each instance
of \emph{C} has its own slot named \emph{S} that stores its own value.  If the
value of the \cd{:allocation} slot option is \cd{:class}, then \emph{S}
is a shared slot, the class that defined \emph{S} stores the value, and all
instances of \emph{C} can access that single slot.  If the 
\cd{:allocation} slot option is omitted, \cd{:instance} is used.

In general, more than one class among \emph{C} and its superclasses can
define a slot with a given name.  In such cases, only one slot with
the given name is accessible in an instance of \emph{C}, and
the characteristics of that slot are a combination of the several slot
specifiers, computed as follows:

\begin{itemize}

\item All the slot specifiers for a given slot name are ordered
from most specific to least specific, according to the order in \emph{C}'s
class precedence list of the classes that define them. All references
to the specificity of slot specifiers immediately following refer to this
ordering.

\item The allocation of a slot is controlled by the most specific
slot specifier.  If the most specific slot specifier does not contain an
\cd{:allocation} slot option, \cd{:instance} is used.  Less specific
slot specifiers do not affect the allocation.

\item The default initial value form for a
slot is the value of the \cd{:initform} slot option in the most
specific slot specifier that contains one.  If no slot specifier
contains an \cd{:initform} slot option, the slot has no default
initial value form.

\item The contents of a slot will always be of type 
\cd{(and $T_1$ $\ldots$ $T_{n}$)}
where $T_1, \ldots, T_{n}$ are
the values of the \cd{:type} slot options contained in all of the slot
specifiers.  If no slot specifier contains the \cd{:type} slot option, the
contents of the slot will always be of type \cdf{t}. The result
of attempting to store in a slot
a value that does not satisfy the type of the slot is undefined.

\item The set of initialization arguments that initialize a given
slot is the union of the initialization arguments declared in the 
\cd{:initarg} slot options in all the slot specifiers.

\item The documentation string for a slot is the value of the
\cd{:documentation} slot option in the most specific slot specifier
that contains one.  If no slot specifier contains a 
\cd{:documentation} slot option, the slot has no documentation string.
\end{itemize}

A consequence of the allocation rule is that a shared slot can be
shadowed.  For example, if a class $C_1$ defines a slot named \emph{S}
whose value for the \cd{:allocation} slot option is \cd{:class},
that slot is accessible in instances of $C_1$ and all of its
subclasses.  However, if $C_2$ is a subclass of $C_1$ and also
defines a slot named \emph{S}, $C_1$'s slot is not shared
by instances of $C_2$ and its subclasses. When a class
$C_1$ defines a shared slot, any subclass $C_2$ of $C_1$ will share this single
slot unless the \cdf{defclass} form for 
$C_2$ specifies a slot of the same name or there is a superclass
of $C_2$ that precedes $C_1$ in the class precedence list of
$C_2$ that defines a slot of the same name.

A consequence of the type rule is that the value of a slot satisfies
the type constraint of each slot specifier that contributes to that
slot. Because the result of attempting to store in a slot a value
that does not satisfy the type constraint for the slot is undefined,
the value in a slot might fail to satisfy its type constraint.

The \cd{:reader}, \cd{:writer}, and \cd{:accessor} slot options
create methods rather than define the characteristics of a slot.
Reader and writer  methods are inherited in the sense described in
section~\ref{Inheritance-of-Methods-SECTION}. 

Methods that access slots use only the name of the slot and the type
of the slot's value.  Suppose a superclass provides a method that
expects to access a shared slot of a given name, and a subclass defines
a local slot with the same name.  If the method provided by the
superclass is used on an instance of the subclass, the method accesses
the local slot.

\subsubsection{Inheritance of Class Options}

The \cd{:default-initargs} class option is inherited.  The set of
defaulted initialization arguments for a class is the union of the
sets of initialization arguments specified in the 
\cd{:default-initargs} class options of the class and its superclasses.
When more than one default initial value form is supplied for a given
initialization argument, the default initial value form that is used
is the one supplied by the class that is most specific according to
the class precedence list.

If a given \cd{:default-initargs} class option specifies an
initialization argument of the same name more than once, an
error is signaled.

\subsubsection{Examples}

\begin{lisp}
(defclass C1 () \\*
~~((S1 :initform 5.4 :type number) \\*
~~~(S2 :allocation :class))) \\
\\
(defclass C2 (C1) \\*
~~((S1 :initform 5 :type integer)\\*
~~~(S2 :allocation :instance)\\*
~~~(S3 :accessor C2-S3)))
\end{lisp}

Instances of the class \cd{C1} have a local slot named \cd{S1}, whose default
initial value is 5.4 and whose value should always be a number.
The class \cd{C1} also has a shared slot named \cd{S2}.

There is a local slot named \cd{S1} in instances of \cd{C2}.  The
default initial value of \cd{S1} is 5.  The value of \cd{S1} will be
of type \cd{(and integer number)}.  There are also local slots named
\cd{S2} and \cd{S3} in instances of \cd{C2}.  The class \cd{C2}
has a method for \cd{C2-S3} for reading the value of slot \cd{S3};
there is also a method for \cd{(setf C2-S3)} that writes the
value of \cd{S3}.

\subsection{Integrating Types and Classes} 
\label{Integrating-Types-and-Classes-SECTION} 

The \CLOS\ maps the space of classes into the Common Lisp type space.
Every class that has a proper name has a corresponding type with the same 
name.

The proper name of every class is a valid type specifier.  In
addition, every class object is a valid type specifier.  Thus the
expression \cd{(typep \emph{object class})} evaluates to true if the
class of \emph{object} is \emph{class} itself or a subclass of \emph{class}.
The evaluation of the expression \cd{(subtypep \emph{class1 class2})} returns
the values \cdf{t}~and~\cdf{t} if \emph{class1} is a 
subclass of \emph{class2} or if they are the same class; otherwise it
returns the values \cdf{nil}~and~\cdf{t}.  If \emph{I} is an instance of some class
\emph{C} named \emph{S} and \emph{C} is an instance of \cdf{standard-class}, the
evaluation of the expression \cd{(type-of \emph{I})} will return \emph{S} if
\emph{S} is the proper name of \emph{C}; if \emph{S} is not the proper
name of \emph{C}, the expression \cd{(type-of \emph{I})} will
return \emph{C}.

Because the names of classes and class objects are type specifiers, they may
be used in the special operator \cdf{the} and in type declarations.

Many but not all of the predefined Common Lisp type specifiers have a
corresponding class with the same proper name as the type.  These type
specifiers are listed in table~\ref{CLOS-PRECEDENCE-TABLE}.  For example, the
type \cdf{array} has a corresponding class named \cdf{array}.  No type specifier
that is a list, such as \cd{(vector double-float 100)}, has a corresponding
class. The form \cdf{deftype} does not create any classes.

Each class that corresponds to a predefined Common Lisp type specifier
can be implemented in one of three ways, at the discretion of each
implementation.  It can be a \emph{standard class} (of the kind
defined by \cdf{defclass}), a \emph{structure class} (defined
by \cdf{defstruct}), or a \emph{built-in class} (implemented in
a special, non-extensible way).

A built-in class is one whose instances have restricted capabilities or
special representations.  Attempting to use \cdf{defclass} to define 
subclasses of a built-in class signals an error.  Calling 
\cdf{make-instance} to create an instance of a built-in class signals an error.
Calling \cdf{slot-value} on an instance of a built-in class signals an
error.  Redefining a built-in class or using \cdf{change-class} to change
the class of an instance to or from a built-in class signals an error.
However, built-in classes can be used as parameter specializers in
methods.

It is possible to determine whether a class is a built-in class by
checking the metaclass.  A standard class is an instance of 
\cdf{standard-class}, a built-in class is an instance of 
\cdf{built-in-class}, and a structure class is an instance of 
\cdf{structure-class}.

Each structure type created by \cdf{defstruct} without using the 
\cd{:type} option has a corresponding class.  This class is an instance of
\cdf{structure-class}.

The \cd{:include} option of \cdf{defstruct} creates a direct
subclass of the class that corresponds to the included structure.

The purpose of specifying that many of the standard Common Lisp type
specifiers have a corresponding class is to enable users to write methods that
discriminate on these types.  
Method selection requires that a class precedence list can be
determined for each class.

The hierarchical relationships among the Common Lisp type specifiers
are mirrored by relationships among the classes corresponding to those
types.  The existing type hierarchy is used for determining the
class precedence list for each class that corresponds to a predefined
Common Lisp type.

%In some cases, the first edition
%did not specify a local precedence order for two supertypes of a
%given type specifier.  For example, \cdf{null} is a subtype of both
%\cdf{symbol} and \cdf{list}, but the first edition
%did not specify whether \cdf{symbol} is more specific or less
%specific than \cdf{list}.  The CLOS specification defines those
%relationships for all such classes.

Table~\ref{CLOS-PRECEDENCE-TABLE} lists the set of classes required by the \OS\
that correspond to predefined Common Lisp type specifiers.  The
superclasses of each such class are presented in order from most
specific to most general, thereby defining the class precedence list
for the class. The local precedence order for each class that
corresponds to a Common Lisp type specifier can be derived from this
table.

Individual implementations may be extended to define other type
specifiers to have a corresponding class.  Individual implementations
can be extended to add other subclass relationships and to add other
elements to the class precedence lists in the above table as long as
they do not violate the type relationships and disjointness
requirements specified in section~\ref{DATA-TYPE-RELATIONSHIPS}.
A standard class defined with no direct superclasses is guaranteed to
be disjoint from all of the classes in the table, except for the
class named \cdf{t}.

[At this point the original CLOS report specified that certain Common Lisp
types were to appear in table~\ref{CLOS-PRECEDENCE-TABLE} if and only if
X3J13 voted to make them disjoint from
\cdf{cons}, \cdf{symbol}, \cdf{array}, \cdf{number}, and \cdf{character}.
X3J13 voted to do so in June 1988
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}.  I have added these types
and their class precedence lists to the table; the new types are indicated
by asterisks.---GLS]

\begin{table}[t]
\caption{Class Precedence Lists for Predefined Types}
\label{CLOS-PRECEDENCE-TABLE}
\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\textrm{Predefined Common Lisp Type}&\textrm{Class Precedence List for Corresponding Class} \\
\hlinesp
array&(array t)\\
bit-vector&(bit-vector vector array sequence t)\\
character&(character t)\\
complex&(complex number t)\\
cons&(cons list sequence t)\\
float&(float number t)\\
function \textrm{*}&(function t) \\
hash-table \textrm{*}&(hash-table t) \\
integer&(integer rational number t)\\
list&(list sequence t)\\
null&(null symbol list sequence t)\\
number&(number t)\\
package \textrm{*}&(package t) \\
pathname \textrm{*}&(pathname t) \\
random-state \textrm{*}&(random-state t) \\
ratio&(ratio rational number t)\\
rational&(rational number t)\\
readtable \textrm{*}&(readtable t) \\
sequence&(sequence t)\\
stream \textrm{*}&(stream t) \\
string&(string vector array sequence t)\\
symbol&(symbol t)\\
t&(t)\\
vector&(vector array sequence t)
\end{tabular}
\end{flushleft}
[An asterisk indicates a type added to this table as a consequence
of a portion of the CLOS specification that was conditional on X3J13 voting
to make that type disjoint from certain other built-in types
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}.---GLS]
\end{table}

\subsection{Determining the Class Precedence List}
\label{Determining-the-Class-Precedence-List-SECTION}

The \cdf{defclass} form for a class provides a total ordering on that
class and its direct superclasses.  This ordering is called the \emph{local
  precedence order}.  It is an ordered list of the class and its 
direct superclasses. The \emph{class precedence list} for a
class \emph{C} is a total ordering on \emph{C} and its superclasses that is consistent
with the local precedence orders for \emph{C} and its superclasses.

A class precedes its direct superclasses, and a
direct superclass precedes all other direct superclasses specified to
its right in the superclasses list of the \cdf{defclass} form.  For
every class \emph{C}, define
$$R_C=\{(C,C_1),(C_1,C_2),\ldots,(C_{n-1},C_{n})\}$$
where $C_1,\ldots,C_{n}$ are
the direct superclasses of \emph{C} in the order in which
they are mentioned in the \cdf{defclass} form. These ordered pairs
generate the total ordering on the class \emph{C} and its direct
superclasses.

Let $S_C$ be the set of \emph{C} and its superclasses. Let \emph{R} be
$$R=\bigcup_{\textstyle c\in {S_{C}}} R_{c}$$

The set \emph{R} may or may not generate a partial ordering, depending on
whether the $R_{c}$, $c\in S_{C}$,
are consistent; it is assumed
that they are consistent and that \emph{R} generates a partial ordering.
When the $R_{c}$ are not consistent, it is said that \emph{R} is inconsistent.

To compute the class precedence list for~\emph{C},
topologically sort the elements of $S_{C}$ with respect to the
partial ordering generated by \emph{R}.  When the topological
sort must select a class from a set of two or more classes, none of
which are preceded by other classes with respect to~\emph{R},
the class selected is chosen deterministically, as described below.
If \emph{R} is inconsistent, an error is signaled.

\subsubsection{Topological Sorting}

\href{http://ru.wikipedia.org/wiki/Топологическая_сортировка}{Топологическая
  сортировка}

Topological sorting proceeds by finding a class \emph{C} in~$S_{C}$ such
that no other class precedes that element according to the elements
in~\emph{R}.  The class \emph{C} is placed first in the result.
Remove \emph{C} from $S_{C}$, and remove all pairs of the form
$(C,D)$,
$D\in S_{C}$, from \emph{R}. Repeat the process, adding
classes with no predecessors to the end of the result. Stop when no
element can be found that has no predecessor.

If $S_{C}$ is not empty and the process has stopped, the set \emph{R} is
inconsistent. If every class in the finite set of classes is preceded
by another, then \emph{R} contains a loop. That is, there is a chain of
classes $C_1,\ldots,C_{n}$
such that $C_{i}$ precedes
$C_{i+1}$, $1\leq i<n$,
and $C_{n}$ precedes $C_1$.

Sometimes there are several classes from $S_{C}$ with no
predecessors.  In this case select the one that has a direct
subclass rightmost in the class precedence list computed so far.
%%%%%%% RPG said to take out the following sentence 10/5/89.
%Because a direct superclass precedes all other direct superclasses to
%its right, there can be only one such candidate class.
If there is no
such candidate class, \emph{R} does not generate a partial ordering --- the
$R_{c}$, $c\in S_{C}$, are inconsistent.

In more precise terms, let $\{N_1,\ldots,N_{m}\}$,
$m\geq 2$, be
the classes from $S_{C}$ with no predecessors.  Let $(C_1\ldots C_{n})$, $n\geq
1$, be the class precedence list 
constructed so far.  $C_1$ is the most specific class, and $C_n$ is the least
specific.  Let $1\leq j\leq n$ be the largest number 
such that there exists an \emph{i} where $1\leq i\leq m$ and
$N_{i}$
is a direct superclass of $C_{j}$;
$N_{i}$ is placed next.

The effect of this rule for selecting from a set of classes with no
predecessors is that classes in a simple superclass chain are
adjacent in the class precedence list and that classes in each
relatively separated subgraph are adjacent in the class
precedence list. For example, let $T_1$ and $T_2$ be subgraphs
whose only element in common is the class \emph{J}. Suppose
that no superclass of \emph{J} appears in either $T_1$ or $T_2$.
Let $C_1$ be the bottom of $T_1$; and let $C_2$ be the
bottom of $T_2$.  Suppose \emph{C} is a class whose direct superclasses
are $C_1$ and $C_2$ in that order; then the class precedence
list for \emph{C} will start with \emph{C} and will be followed by all classes
in $T_1$ except \emph{J}. All the classes of $T_2$ will be next.
The class \emph{J} and its superclasses will appear last.

\subsubsection{Examples}

This example determines a class precedence list for the
class \cdf{pie}.  The following classes are defined:

\begin{lisp}
(defclass pie (apple cinnamon) ()) \\*
(defclass apple (fruit) ()) \\*
(defclass cinnamon (spice) ()) \\
(defclass fruit (food) ()) \\
(defclass spice (food) ()) \\*
(defclass food () ())
\end{lisp}

\begin{flushleft}

The set
S=\{\cdf{pie},
\cdf{apple},
\cdf{cinnamon},
\cdf{fruit},
\cdf{spice},
\cdf{food},
\cdf{standard-object},
\cdf{t}\}.
The set R=\{(\cdf{pie},
\cdf{apple}),
(\cdf{apple},
\cdf{cinnamon}),
(\cdf{cinnamon},
\cdf{standard-object}),
(\cdf{apple},
\cdf{fruit}),
(\cdf{fruit},
\cdf{standard-object}),
(\cdf{cinnamon},
\cdf{spice}),
(\cdf{spice},
\cdf{standard-object}),
(\cdf{fruit},
\cdf{food}),
(\cdf{food},
\cdf{standard-object}),
(\cdf{spice},
\cdf{food}),
(\cdf{standard-object},
\cdf{t})\}.

The class \cdf{pie} is not preceded by anything, so it comes first;
the result so far is \cd{(pie)}.  Remove \cdf{pie} from \emph{S} and pairs
mentioning \cdf{pie} from \emph{R} to get
S=\{\cdf{apple},
\cdf{cinnamon},
\cdf{fruit},
\cdf{spice},
\cdf{food},
\cdf{standard-object},
\cdf{t}\} and R=\{
(\cdf{apple},
\cdf{cinnamon}),
(\cdf{cinnamon},
\cdf{standard-object}),
(\cdf{apple},
\cdf{fruit}),
(\cdf{fruit},
\cdf{standard-object}),
(\cdf{cinnamon},
\cdf{spice}),
(\cdf{spice},
\cdf{standard-object}),
(\cdf{fruit},
\cdf{food}),
(\cdf{food},
\cdf{standard-object}),
(\cdf{spice},
\cdf{food}),
(\cdf{standard-object},
\cdf{t})\}.

The class \cdf{apple} is not preceded by anything, so it is next; the
result is \cd{(pie~apple)}. Removing \cdf{apple} and the relevant
pairs results in S=\{\cdf{cinnamon},
\cdf{fruit},
\cdf{spice},
\cdf{food},
\cdf{standard-object},
\cdf{t}\} and R=\{(\cdf{cinnamon},
\cdf{standard-object}),
(\cdf{fruit},
\cdf{standard-object}),
(\cdf{cinnamon},
\cdf{spice}),
(\cdf{spice},
\cdf{standard-object}),
(\cdf{fruit},
\cdf{food}),
(\cdf{food},
\cdf{standard-object}),
(\cdf{spice},
\cdf{food}),
(\cdf{standard-object},
\cdf{t})\}.

The classes \cdf{cinnamon} and \cdf{fruit} are not preceded by
anything, so the one with a direct subclass rightmost in the class
precedence list computed so far goes next.  The class \cdf{apple} is a
direct subclass of \cdf{fruit}, and the class \cdf{pie} is a direct
subclass of \cdf{cinnamon}.  Because \cdf{apple} appears to the right
of \cdf{pie} in the precedence list, \cdf{fruit} goes next, and the
result so far is \cd{(pie apple fruit)}.  S=\{\cdf{cinnamon},
\cdf{spice},
\cdf{food},
\cdf{standard-object},
\cdf{t}\}; R=\{(\cdf{cinnamon},
\cdf{standard-object}),
(\cdf{cinnamon},
\cdf{spice}),
(\cdf{spice},
\cdf{standard-object}),
(\cdf{food},
\cdf{standard-object}),
(\cdf{spice},
\cdf{food}),
(\cdf{standard-object},
\cdf{t})\}.

The class \cdf{cinnamon} is next, giving the result so far as 
\cd{(pie apple fruit cinnamon)}.  At this point S=\{\cdf{spice},
\cdf{food},
\cdf{standard-object},
\cdf{t}\}; R=\{(\cdf{spice},
\cdf{standard-object}),
(\cdf{food},
\cdf{standard-object}),
(\cdf{spice},
\cdf{food}),
(\cdf{standard-object},
\cdf{t})\}.
\end{flushleft}

The classes \cdf{spice}, \cdf{food}, \cdf{standard-object}, and 
\cdf{t} are then added in that order, and the final class precedence list for \cdf{pie} is
\begin{lisp}
(pie apple fruit cinnamon spice food standard-object t)
\end{lisp}

It is possible to write a set of class definitions that cannot be 
ordered. For example: 
\begin{lisp}
(defclass new-class (fruit apple) ()) \\
(defclass apple (fruit) ())
\end{lisp}

The class \cdf{fruit} must precede \cdf{apple} because the local
ordering of superclasses must be preserved.  The class \cdf{apple} must
precede \cdf{fruit} because a class always precedes its own
superclasses.  When this situation occurs, an error is signaled when
the system tries to compute the class precedence list.

The following might appear to be a conflicting set of definitions:
\begin{lisp}
(defclass pie (apple cinnamon) ()) \\
(defclass pastry (cinnamon apple) ()) \\
(defclass apple () ()) \\
(defclass cinnamon () ())
\end{lisp}

The class precedence list for \cdf{pie} is
\begin{lisp}
(pie apple cinnamon standard-object t)
\end{lisp}

The class precedence list for \cdf{pastry} is
\begin{lisp}
(pastry cinnamon apple standard-object t)
\end{lisp}

It is not a problem for \cdf{apple} to precede \cdf{cinnamon} in the
ordering of the superclasses of \cdf{pie} but not in the ordering for
\cdf{pastry}.  However, it is not possible to build a new class that
has both \cdf{pie} and \cdf{pastry} as superclasses.

\subsection{Generic Functions and Methods}

A \emph{generic function} is a function whose behavior depends on
the classes or identities of the arguments supplied to it.  The \emph{methods}
define the class-specific behavior and operations of the 
generic function. The following sections describe generic functions
and methods.

\subsubsection{Introduction to Generic Functions}

A generic function object contains a set of methods, a
lambda-list, a method combination type, and other information.

Like an ordinary Lisp function, a generic function takes arguments,
performs a series of operations, and perhaps returns useful values.
An ordinary function has a single body of code that is always executed
when the function is called.  A generic function has a set of bodies
of code of which a subset is selected for execution. The selected
bodies of code and the manner of their combination are determined by
the classes or identities of one or more of the arguments to the
generic function and by its method combination type.

Ordinary functions and generic functions are called with identical function-call
syntax.
 
Generic functions are true functions that can be passed as arguments, returned as values,
used as the first argument to \cdf{funcall} and \cdf{apply}, and otherwise used in all the ways
an ordinary function may be used.

% A name can be given to an ordinary function in one of
% two ways: a \emph{global} name can be given to a function using the
% \cdf{defun} construct; a \emph{local} name can be given using the
% \cdf{flet} or \cdf{labels} special operators.  A generic function can be
% given a global name using the \cdf{defmethod} or \cdf{defgeneric}
% construct.  A generic function can be given a local name using the
% \cdf{generic-flet}, \cdf{generic-labels}, or \cdf{with-added-methods}
% special operators.  The name of a generic function, like the name of an
% ordinary function, can be either a symbol or a two-element list whose
% first element is \cdf{setf} and whose second element is a symbol.
% This is true for both local and global names.

% The \cdf{generic-flet} special operator creates new local generic
% functions using the set of methods specified by the method definitions
% in the \cdf{generic-flet} form.  The scoping of generic function names
% within a \cdf{generic-flet} form is the same as for \cdf{flet}.

% The \cdf{generic-labels} special operator creates a set of new mutually
% recursive local generic functions using the set of methods specified
% by the method definitions in the \cdf{generic-labels} form.  The
% scoping of generic function names within a \cdf{generic-labels} form
% is the same as for \cdf{labels}.

% The \cdf{with-added-methods} special operator creates new local generic
% functions by adding the set of methods specified by the method
% definitions with a given name in the \cdf{with-added-methods} form to
% copies of the methods of the lexically visible generic function of the
% same name. If there is a lexically visible ordinary function of the
% same name as one of the specified generic functions, that function
% becomes the method function of the default method for the new generic
% function of that name.

The \cdf{generic-function} macro creates an anonymous generic
function with the set of methods specified by the method definitions that appear
in the \cd{generic-function} form.

When a \cdf{defgeneric} form is evaluated, one of three actions
is taken:

\begin{itemize}

\item  If a generic function of the given name already exists,
the existing generic function object is modified.  Methods specified
by the current \cdf{defgeneric} form are added, and any methods in the
existing generic function that were defined by a previous 
\cdf{defgeneric} form are removed.  Methods added by the current 
\cdf{defgeneric} form might replace methods defined by \cdf{defmethod} or
\cdf{defclass}.  No other methods in the generic function are affected
or replaced.

\item  If the given name names a non-generic function, a
macro, or a special operator, an error is signaled.

\item  Otherwise a generic function is created with the
methods specified by the method definitions in the \cdf{defgeneric}
form.
\end{itemize}

Some forms specify the options of a generic function,
such as the type of method combination it uses or its argument
precedence order.  They will be referred to as ``forms that
specify generic function options.'' These forms are \cdf{defgeneric},
\cdf{generic-function}. %, \cdf{generic-flet}, \cdf{generic-labels}, and
%\cdf{with-added-methods}.

Some forms define methods for a generic function.  They will be
referred to as ``method-defining forms.'' These forms are 
\cdf{defgeneric}, \cdf{defmethod}, \cdf{generic-function}, 
%\cdf{generic-flet}, \cdf{generic-labels}, \cdf{with-added-methods}, 
and \cdf{defclass}. Note that all the method-defining forms except 
\cdf{defclass} and \cdf{defmethod}
are also forms that specify generic function options.

\subsubsection{Introduction to Methods}
\label{Introduction-to-Methods-SECTION}

A method object contains a method function, a sequence of \emph{parameter
  specializers} that specify when the given method is 
applicable, a lambda-list, and a sequence of \emph{qualifiers} that
are used by the method combination facility to distinguish among
methods.

A method object is not a function and cannot be invoked as a function. 
Various mechanisms in the \OS\ take a method object and invoke its method
function, as is the case when a generic function is invoked.  When this
occurs it is said that the method is invoked or called.

A method-defining form contains the code that is to be run when the
arguments to the generic function cause the method that it defines to
be invoked.  When a method-defining form is evaluated, a method object
is created and one of four actions is taken:

\begin{itemize}

\item  If a generic function of the given name already exists
and if a method object already exists that agrees with the new one on
parameter specializers and qualifiers, the new method object replaces
the old one.  For a definition of one method agreeing with another on
parameter specializers and qualifiers, see
section~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}.

\item  If a generic function of the given name already exists
and if there is no method object that agrees with the new one on
parameter specializers and qualifiers, the existing generic function
object is modified to contain the new method object.

\item  If the given name names a non-generic function, a macro,
or a special operator, an error is signaled.

\item  Otherwise a generic function is created with the methods
specified by the method-defining form.

\end{itemize}

If the lambda-list of a new method is not congruent with the lambda-list
of the generic function, an error is signaled.  If a
method-defining form that cannot specify generic function options
creates a new generic function, a lambda-list for that generic
function is derived from the lambda-lists of the methods in the
method-defining form in such a way as to be congruent with them.  For
a discussion of \emph{congruence}, see
section~\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}.

Each method has a \emph{specialized lambda-list}, which determines
when that method can be applied.  A specialized lambda-list is like
an ordinary lambda-list except that a \emph{specialized parameter}
may occur instead of the name of a required parameter.  A specialized parameter
is a list \cd{(\emph{variable-name parameter-specializer-name})},
where \emph{parameter-specializer-name} is either
a name that names a class or a list \cd{(\cdf{eql} \emph{form})}.
A parameter specializer name denotes a parameter specializer as follows:
 
\begin{itemize}
\item  A name that names a class denotes that class.

\item  The list \cd{(\cdf{eql} \emph{form})} denotes the type specifier
\cd{(\cdf{eql} \emph{object})}, where \emph{object} is the result of
evaluating \emph{form}.  The form \emph{form} is evaluated in the
lexical environment in which the method-defining form is
evaluated.  Note that \emph{form} is evaluated only once, at the time
the method is defined, not each time the generic function is called.
\end{itemize}

Parameter specializer names are used in macros intended as the
user-level interface (\cdf{defmethod}), while parameter specializers
are used in the functional interface.

[It is very important to understand clearly the distinction made
in the preceding paragraph.  A parameter specializer name
has the form of a type specifier but is semantically quite different
from a type specifier: a parameter specializer name of the form
\cd{(\cdf{eql} \emph{form})} is not a type specifier, for it contains
a \emph{form} to be evaluated.   Type specifiers
never contain forms to be evaluated.  All parameter specializers
(as opposed to parameter specializer names) are valid type specifiers,
but not all type specifiers are valid parameter specializers.  Macros such as \cdf{defmethod}
take parameter specializer names and treat them as specifications for
constructing certain type specifiers (parameter specializers) that may then be used
with such functions as \cdf{find-method}.---GLS]

Only required parameters may be specialized, and there must be a
parameter specializer for each required parameter.  For notational
simplicity, if some required parameter in a specialized lambda-list in
a method-defining form is simply a variable name, its parameter
specializer defaults to the class named \cdf{t}.

Given a generic function and a set of arguments, an \emph{applicable
method} is a method for that generic function whose parameter
specializers are satisfied by their corresponding arguments.  The
following definition specifies what it means for a method to be
applicable and for an argument to satisfy a parameter specializer.

Let $\langle A_1, \ldots, A_{n}\rangle$ be the required
arguments to a generic function in order. Let $\langle P_1,
\ldots, P_{n}\rangle$ be the parameter specializers corresponding to
the required parameters of the method \emph{M} in order.  The method \emph{M} is
\emph{applicable} when each $A_{i}$
\emph{satisfies} $P_{i}$.
If $P_{i}$ is a class,
and if $A_{i}$ is an instance of a class
\emph{C}, then it is said that $A_{i}$ \emph{satisfies}
$P_{i}$ when $C=P_{i}$ or when \emph{C} is a subclass of $P_{i}$.  If
$P_{i}$ is of the form
\cd{(\cdf{eql} \emph{object})}, then it is said that
$A_{i}$ satisfies $P_{i}$
when the function \cdf{eql} applied to
$A_{i}$ and \emph{object} is true.

Because a parameter specializer is a type specifier, the function 
\cdf{typep} can be used during method selection to determine whether an
argument satisfies a parameter specializer.  In general a
parameter specializer cannot be a type specifier list, such as 
\cd{(\cd{vector single-float})}.  The only parameter specializer that can
be a list is \cd{(\cdf{eql} \emph{object})}.  This requires that
Common Lisp define the type specifier \cdf{eql}
as if the following were evaluated:

\begin{lisp}
(deftype eql (\emph{object}) {\Xbq}(member ,\emph{object}))
\end{lisp}
[See section~\ref{PREDICATING-TYPE-SPECIFIERS-SECTION}.---GLS]

A method all of whose parameter specializers are the class named 
\cdf{t} is called a \emph{default method}; it is always applicable but
may be shadowed by a more specific method.

Methods can have \emph{qualifiers}, which give the method combination
procedure a way to distinguish among methods.  A method that has one
or more qualifiers is called a \emph{qualified} method.
A method with no qualifiers is called an \emph{unqualified method}. 
A qualifier is any object other than a list, that is,
any non-\cdf{nil} atom.  The qualifiers defined by standard method combination
and by the built-in method combination types are symbols.

In this specification, the terms \emph{primary method} and \emph{auxiliary
  method} are used to partition methods within a method 
combination type according to their intended use.  In standard method
combination, primary methods are unqualified methods, and auxiliary
methods are methods with a single qualifier that is one of 
\cd{:around}, \cd{:before}, or \cd{:after}.  When a method combination
type is defined using the short form of 
\cdf{define-method-combination}, primary methods are methods qualified with
the name of the type of method combination, and auxiliary methods have
the qualifier \cd{:around}.  Thus the terms \emph{primary method}
and \emph{auxiliary method} have only a relative definition within a
given method combination type.

\subsubsection{Agreement on Parameter Specializers and Qualifiers}
\label{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}

Two methods are said to agree with each other on parameter specializers
and qualifiers if the following conditions hold:

\begin{itemize}

\item Both methods have the same number of required parameters.
Suppose the parameter specializers of the two methods are
$P\sub{1,1}\ldots P\sub{1,n}$
and $P\sub{2,1}\ldots P\sub{2,n}$.

\item For each $1\leq i\leq n$,
$P\sub{1,i}$ agrees with $P\sub{2,i}$.
The parameter specializer $P\sub{1,i}$
agrees with $P\sub{2,i}$ if
$P\sub{1,i}$ and $P\sub{2,i}$ are the same class or if 
$P\sub{1,i}=(\cdf{eql} object_1)$,
$P\sub{2,i}=(\cdf{eql} object_2)$, and
\cd{(\cdf{eql} $object_1$ $object_2$)}.
Otherwise $P\sub{1,i}$ and $P\sub{2,i}$ do not agree.

\item The lists of qualifiers of both methods contain the same 
non-\cdf{nil} atoms in the same order. That is, the lists are \cdf{equal}.
\end{itemize}

\subsubsection{Congruent Lambda-Lists for All Methods of a Generic Function}
\label{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}

These rules define the congruence of a set of lambda-lists, including the
lambda-list of each method for a given generic function and the
lambda-list specified for the generic function itself, if given.

\begin{itemize}

\item Each lambda-list must have the same number of required
parameters.

\item Each lambda-list must have the same number of optional
parameters.  Each method can supply its own default for an optional
parameter.

\item If any lambda-list mentions \cd{\&rest} or \cd{\&key}, each
lambda-list must mention one or both of them.

\item If the generic function lambda-list mentions \cd{\&key}, each
method must accept all of the keyword names mentioned after \cd{\&key},
either by accepting them explicitly, by specifying 
\cd{\&allow-other-keys}, or by specifying \cd{\&rest} but not \cd{\&key}.
Each method can accept additional keyword arguments of its own.  The
checking of the validity of keyword names is done in the generic
function, not in each method. A method is invoked as if the keyword
argument pair whose  keyword is \cd{:allow-other-keys} and whose value
is \cdf{t} were supplied, though no such argument pair will be passed.

\item The use of \cd{\&allow-other-keys} need not be consistent
across lambda-lists.  If \cd{\&allow-other-keys} is mentioned in 
the lambda-list of any applicable method or of the generic function,
any keyword arguments may be mentioned in the call to the
generic function.

\item The use of \cd{\&aux} need not be consistent across methods.
\end{itemize}

If a method-defining form that cannot specify generic function options
creates a generic function, and if the lambda-list for the method
mentions keyword arguments, the lambda-list of the generic function
will mention \cd{\&key} (but no keyword arguments).

\subsubsection{Keyword Arguments in Generic Functions and Methods}

When a generic function or any of its methods mentions \cd{\&key} in
a lambda-list, the specific set of keyword arguments accepted by the
generic function varies according to the applicable methods.  The set
of keyword arguments accepted by the generic function for a particular
call is the union of the keyword arguments accepted by all applicable
methods and the keyword arguments mentioned after \cd{\&key} in the
generic function definition, if any.  A method that has \cd{\&rest}
but not \cd{\&key} does not affect the set of acceptable keyword
arguments.  If the lambda-list of any applicable method or of the
generic function definition contains \cd{\&allow-other-keys}, all
keyword arguments are accepted by the generic function.

The lambda-list congruence rules require that each method
accept all of the keyword arguments mentioned after \cd{\&key} in the
generic function definition, by accepting them explicitly, by
specifying \cd{\&allow-other-keys}, or by specifying \cd{\&rest} but
not \cd{\&key}.  Each method can accept additional keyword arguments
of its own, in addition to the keyword arguments mentioned in the
generic function definition.

If a generic function is passed a keyword argument that no applicable
method accepts, an error is signaled.

For example, suppose there are two methods defined for \cdf{width}
as follows:

\begin{lisp}
(defmethod width ((c character-class) \&key font) ...)\\*
\\*
(defmethod width ((p picture-class) \&key pixel-size) ...)
\end{lisp}

Assume that there are no other methods and no generic
function definition for \cdf{width}. The evaluation of the
following form will signal an error because the keyword argument
\cd{:pixel-size} is not accepted by the applicable method.

\begin{lisp}
(width (make-instance 'character-class :char \#{\Xbackslash}Q) \\*
~~~~~~~:font 'baskerville :pixel-size 10)
\end{lisp}

The evaluation of the following form will signal an error.

\begin{lisp}
(width (make-instance 'picture-class :glyph (glyph \#{\Xbackslash}Q)) \\*
~~~~~~~:font 'baskerville :pixel-size 10)
\end{lisp}

The evaluation of the following form will not signal an error
if the class named \cdf{character-picture-class} is a subclass of
both \cdf{picture-class} and \cdf{character-class}.

\begin{lisp}
(width (make-instance 'character-picture-class :char \#{\Xbackslash}Q) \\*
~~~~~~~:font 'baskerville :pixel-size 10)
\end{lisp}


\subsection{Method Selection and Combination}
\label{Method-Selection-and-Combination-SECTION}

When a generic function is called with particular arguments, it must
determine the code to execute.  This code is called the \emph{effective
  method} for those arguments.  The effective method is a \emph{combination}
of the applicable methods in the generic function.  A 
combination of methods is a Lisp expression that contains calls to some or
all of the methods.  If a generic function is
called and no methods apply, the generic function 
\cdf{no-applicable-method} is invoked.

When the effective method has been determined, it is invoked with the same
arguments that were passed to the generic function.  Whatever values it
returns are returned as the values of the generic function.

\subsubsection{Determining the Effective Method}
\label{Determining-the-Effective-Method-SECTION}

The effective method for a set of
arguments is determined by the following three-step procedure:

\begin{enumerate}

\item Select the applicable methods.

\item Sort the applicable methods by precedence order, putting
the most specific method first.

\item Apply method combination to the sorted list of
applicable methods, producing the effective method.

\end{enumerate}

\textbf{Selecting the Applicable Methods.}
This step is described in section~\ref{Introduction-to-Methods-SECTION}.

\textbf{Sorting the Applicable Methods by Precedence Order.}
To compare the precedence of two methods, their parameter specializers
are examined in order.  The default examination order is from left to
right, but an alternative order may be specified by the 
\cd{:argument-precedence-order} option to \cdf{defgeneric} or to any of
the other forms that specify generic function options.

The corresponding parameter specializers from each method are
compared.  When a pair of parameter specializers are equal, the next
pair are compared for equality.  If all corresponding parameter
specializers are equal, the two methods must have different
qualifiers; in this case, either method can be selected to precede the
other.

If some corresponding parameter specializers are not equal, the first
pair of parameter specializers that are not equal determines the
precedence.  If both parameter specializers are classes, the more
specific of the two methods is the method whose parameter specializer
appears earlier in the class precedence list of the corresponding
argument.  Because of the way in which the set of applicable methods
is chosen, the parameter specializers are guaranteed to be present in
the class precedence list of the class of the argument.

If just one parameter specializer is \cd{(\cdf{eql} \emph{object})}, the
method with that parameter specializer precedes the 
other method.  If both parameter specializers are \cdf{eql}
forms, the
specializers must be the same (otherwise the two methods would
not both have been applicable to this argument).

The resulting list of applicable methods has the most specific
method first and the least specific method last.    

\textbf{Applying Method Combination to the Sorted List of Applicable Methods.}

In the simple case---if standard method combination is used and all
applicable methods are primary methods---the effective method is the
most specific method.  That method can call the next most specific
method by using the function \cdf{call-next-method}.  The method that
\cdf{call-next-method} will call is referred to as the \emph{next
method}.  The predicate \cdf{next-method-p} tests whether a next
method exists.  If \cdf{call-next-method} is called and there is no
next most specific method, the generic function \cdf{no-next-method}
is invoked.

In general, the effective method is some combination of the applicable
methods.  It is defined by a Lisp form that contains calls to some or all
of the applicable methods, returns the value or values that will be
returned as the value or values of the generic function, and optionally
makes some of the methods accessible by means of \cdf{call-next-method}.
This Lisp form is the body of the effective method; it is augmented with
an appropriate lambda-list to make it a function.

The role of each method in the effective method is determined by its
method qualifiers and the specificity of the method.  A qualifier
serves to mark a method, and the meaning of a qualifier is
determined by the way that these marks are used by this step
of the procedure.  If an applicable method has an unrecognized
qualifier, this step signals an error and does not include that method
in the effective method.

When standard method combination is used together with qualified methods, 
the effective method is produced as described in
section~\ref{Standard-Method-Combination-SECTION}.

Another type of method combination can be specified by using the 
\cd{:method-combination} option of \cdf{defgeneric} or of any of the other
forms that specify generic function options.  In this way this step of
the procedure can be customized.

New types of method combination can be defined by using the 
\cdf{define-method-combination} macro. 

The meta-object level also offers a mechanism for defining new types
of method combination.  The generic function 
\cdf{compute-effective-method} receives as arguments the generic function,
the method combination object, and the sorted list of applicable
methods.  It returns the Lisp form that defines the effective method.
A method for \cdf{compute-effective-method} can be defined directly by
using \cdf{defmethod} or indirectly by using 
\cdf{define-method-combination}.
A \emph{method combination object} is an
object that encapsulates the method combination type and options
specified by the \cd{:method-combination} option to forms that
specify generic function options.

\beforenoterule
\begin{implementation}
In the simplest implementation, the generic function would compute
the effective method each time it was called.  In practice, this will
be too inefficient for some implementations.  Instead, these
implementations might employ a variety of optimizations of the
three-step procedure. Some illustrative examples of such optimizations
are the following:

\begin{itemize}

\item  Use a hash table keyed by the class of the arguments to
store the effective method.

\item  Compile the effective method and save the resulting
compiled function in a table.

\item  Recognize the Lisp form as an instance of a pattern of
control structure and substitute a closure that implements
that structure.

\item Examine the parameter specializers of all methods for the
generic function and enumerate all possible effective methods.
Combine the effective methods, together with code to select from
among them, into a single function and compile that function.  Call
that function whenever the generic function is called.
\end{itemize}
\end{implementation}
\afternoterule

\subsubsection{Standard Method Combination}
\label{Standard-Method-Combination-SECTION}

Standard method combination is supported by the class 
\cdf{standard-generic-function}.
It is used if no other type of method
combination is specified or if the built-in method combination type
\cdf{standard} is specified. 

\emph{Primary methods} define the main action of the effective method,  
while \emph{auxiliary methods} modify that action in one of three ways.
A primary method has no method qualifiers.

An auxiliary method is a method whose method qualifier is 
\cd{:before}, \cd{:after}, or \cd{:around}.  Standard method combination
allows no more than one qualifier per method; if a method definition
specifies more than one qualifier per method, an error is signaled.

\begin{itemize}
\item 
A \cd{:before} method has the keyword \cd{:before} as its
only qualifier.  A \cd{:before} method specifies code that is to be
run before any primary method.

\item 
An \cd{:after} method has the keyword \cd{:after} as its only
qualifier.  An \cd{:after} method specifies code that is to be run
after primary methods.  

\item 
An \cd{:around} method has the keyword \cd{:around} as its only
qualifier. An \cd{:around} method specifies code that is to
be run instead of other applicable methods but that is
able to cause some of them to be run.
\end{itemize}

The semantics of standard method combination are as follows:

\begin{itemize}

\item  If there are any \cd{:around} methods, the most specific
\cd{:around} method is called.  It supplies the value or values of the
generic function.

\item  Inside the body of an \cd{:around} method, 
\cdf{call-next-method} can be used to call the next method.  When the next
method returns, the \cd{:around} method can execute more code,
perhaps based on the returned value or values.  The generic function
\cdf{no-next-method} is invoked if \cdf{call-next-method} is used and
there is no applicable method to call.  The function 
\cdf{next-method-p} may be used to determine whether a next method exists.

\item  
If an \cd{:around} method invokes \cdf{call-next-method}, the next
most specific \cd{:around} method is called, if one is applicable.
If there are no \cd{:around} methods or if 
\cdf{call-next-method} is called by the least specific \cd{:around}
method, the other methods are called as follows:

\begin{itemize}
\item  All the \cd{:before} methods are called, in
most-specific-first order.  Their values are ignored.
An error is signaled if \cdf{call-next-method} is used in a
\cd{:before} method.

\item  The most specific primary method is called.  Inside the
body of a primary method, \cdf{call-next-method} may be used to call
the next most specific primary method.  When that method returns, the
previous primary method can execute more code, perhaps based on the
returned value or values.  The generic function \cdf{no-next-method}
is invoked if \cdf{call-next-method} is used and there are no more
applicable primary methods.  The function \cdf{next-method-p} may be
used to determine whether a next method exists.  If 
\cdf{call-next-method} is not used, only the most specific primary method
is called.

\item  All the \cd{:after} methods are called in
most-specific-last order.  Their values are ignored.
An error is signaled if \cdf{call-next-method} is used in an
\cd{:after} method.
\end{itemize}

\item  If no \cd{:around} methods were invoked, the most
specific primary method supplies the value or values returned by the
generic function.  The value or values returned by the invocation of
\cdf{call-next-method} in the least specific \cd{:around} method are
those returned by the most specific primary method.
\end{itemize}

In standard method combination, if there is an applicable method
but no applicable primary method, an error is signaled.

The \cd{:before} methods are run in most-specific-first order and
the \cd{:after} methods are run in least-specific-first order.  The
design rationale for this difference can be illustrated with an
example.  Suppose class $C_1$ modifies the behavior of its
superclass, $C_2$, by adding \cd{:before} and \cd{:after}
methods. Whether the behavior of the class $C_2$ is defined
directly by methods on $C_2$ or is inherited from its superclasses
does not affect the relative order of invocation of methods on
instances of the class $C_1$.  Class $C_1$'s \cd{:before}
method runs before all of class $C_2$'s methods.  Class $C_1$'s \cd{:after}
method runs after all of class $C_2$'s methods. 

By contrast, all \cd{:around} methods run before any other methods
run.  Thus a less specific \cd{:around} method runs before a more
specific primary method.

If only primary methods are used and if \cdf{call-next-method} is not
used, only the most specific method is invoked; that is, more specific
methods shadow more general ones. 

\subsubsection{Declarative Method Combination}

The macro \cdf{define-method-combination} defines new forms of method
combination.  It provides a mechanism for customizing the production
of the effective method. The default procedure for producing an
effective method is described in
section~\ref{Determining-the-Effective-Method-SECTION}.
There are two forms of 
\cdf{define-method-combination}.  The short form is a simple facility;
the long form is more powerful and more verbose.  The long form
resembles \cdf{defmacro} in that the body is an expression that
computes a Lisp form; it provides mechanisms for implementing
arbitrary control structures within method combination and for
arbitrary processing of method qualifiers.  The syntax and use of both
forms of \cdf{define-method-combination} are explained in
section~\ref{Functions-in-the-Programmer-Interface-SECTION}.

\subsubsection{Built-in Method Combination Types}
\label{Built-in-Method-Combination-Types-SECTION}

The \CLOS\ provides a set of built-in method combination types.  To
specify that a generic function is to use one of these method
combination types, the name of the method combination type is given as
the argument to the \cd{:method-combination} option to 
\cdf{defgeneric} or to the \cd{:method-combination} option to any of the
other forms that specify generic function options.

The names of the built-in  method combination types are
\cdf{+}, \cdf{and}, \cdf{append}, \cdf{list}, \cdf{max}, \cdf{min}, 
\cdf{nconc}, \cdf{or}, \cdf{progn}, and \cdf{standard}.

The semantics of the \cdf{standard} built-in method combination type were
described in section~\ref{Standard-Method-Combination-SECTION}.  The other
built-in method combination types are called \emph{simple built-in method
combination types.}

The simple built-in method combination types act as though they were
defined by the short form of \cdf{define-method-combination}.  They
recognize two roles for methods:

\begin{itemize}

\item  An \cd{:around} method has the keyword symbol 
\cd{:around} as its sole qualifier.  The meaning of \cd{:around}
methods is the same as in standard method combination.  Use of the
functions \cdf{call-next-method} and \cdf{next-method-p} is supported
in \cd{:around} methods.

\item  A primary method has the name of the method combination
type as its sole qualifier.  For example, the built-in method
combination type \cd{and} recognizes methods whose sole qualifier is
\cd{and}; these are primary methods. Use of the functions 
\cdf{call-next-method} and \cdf{next-method-p} is not supported in primary
methods.

\end{itemize}

The semantics of the simple built-in method combination types are as
follows:

\begin{itemize}
\item 
If there are any \cd{:around} methods, the most specific \cd{:around}
method is called.   It supplies the value or values of the generic function. 

\item  Inside the body of an \cd{:around} method, the function
\cdf{call-next-method} can be used to call the next method.  The
generic function \cdf{no-next-method} is invoked if 
\cdf{call-next-method} is used and there is no applicable method to call.
The function \cdf{next-method-p} may be used to determine whether a
next method exists. When the next method returns, the \cd{:around}
method can execute more code, perhaps based on the returned value or
values.

\item  If an \cd{:around} method invokes 
\cdf{call-next-method}, the next most specific \cd{:around} method is
called, if one is applicable.  If there are no \cd{:around} methods
or if \cdf{call-next-method} is called by the least specific 
\cd{:around} method, a Lisp form derived from the name of the built-in
method combination type and from the list of applicable primary
methods is evaluated to produce the value of the generic function.
Suppose the name of the method combination type is \emph{operator}
and the call to the generic function is of the form
\begin{lisp}
(\emph{generic-function} $a_1$ ... $a_{n}$)
\end{lisp}
Let $M_1,\ldots,M_{k}$ be the applicable primary methods
in order; then the derived Lisp form is
\begin{lisp}
(\emph{operator} $\langle M_1\;a_1\ldots a_{n}\rangle$
... $\langle M_k\;a_1\ldots a_{n}\rangle$)
\end{lisp}
If the expression $\langle M_{i} \;a_1\ldots a\sub
{n}\rangle$ is
evaluated, the method $M_i$ will be applied to the arguments
$a_1\ldots a_{n}$.  
For example,
if \emph{operator} is \cdf{or},
the expression $\langle M\sub{i} \ a_1\ldots a_{n}\rangle$ is
evaluated only if $\langle M_{j} \ a_1\ldots a_{n}\rangle$,
$1\leq j<i$, returned \cdf{nil}.

The default order for the primary methods is 
\cd{:most-specific-first}.  However, the order can be reversed by supplying
\cd{:most-specific-last} as the second argument to the 
\cd{:method-combination} option.
\end{itemize}

The simple built-in method combination types require exactly one qualifier per
method.  An error is signaled if there are applicable methods with no
qualifiers or with qualifiers that are not supported by the method
combination type. An error is signaled if there are applicable \cd{:around}
methods and no applicable primary methods.

\subsection{Meta-objects}

The implementation of the \OS\ manipulates classes, methods, and generic
functions.  The meta-object protocol specifies a set of generic
functions defined by methods on classes; the behavior of those generic
functions defines the behavior of the \OS.  The instances of the classes
on which those methods are defined are called \emph{meta-objects}.  Programming
at the meta-object protocol level involves defining new classes of
meta-objects along with methods specialized on these classes.

\subsubsection{Metaclasses}

The \emph{metaclass} of an object is the class of its class.  The
metaclass determines the representation of instances of its instances and
the forms of inheritance used by its instances for slot descriptions and
method inheritance.  The metaclass mechanism can be used to provide
particular forms of optimization or to tailor the \CLOS\ for particular
uses.  The protocol for defining metaclasses is discussed in the third part
of the CLOS specification, The \CLOS\ Meta-Object
Protocol~\ref{METAOBJECT-PROTOCOL}.

\subsubsection{Standard Metaclasses}

The \CLOS\ provides a number of predefined metaclasses.  These include the
classes \cdf{standard-class}, \cdf{built-in-class}, and 
\cdf{structure-class}:

\begin{itemize}

\item 
The class \cdf{standard-class} is the default class of classes defined
by \cdf{defclass}.

\item  The class \cdf{built-in-class} is the class whose
instances are classes that have special implementations with
restricted capabilities.  Any class that corresponds to a standard
Common Lisp type
might be an instance of \cdf{built-in-class}.
The predefined Common Lisp type specifiers that are required to have
corresponding classes are listed in table~\ref{CLOS-PRECEDENCE-TABLE}.
It is implementation-dependent whether each of these classes is implemented as a
built-in class.

\item All classes defined by means of \cdf{defstruct} are instances of 
\cdf{structure-class}.
\end{itemize}

\subsubsection{Standard Meta-objects}

The \OS\ supplies a standard set of meta-objects, called \emph{standard
meta-objects}. These include the class \cdf{standard-object} and
instances of the classes \cdf{standard-method}, 
\cdf{standard-generic-function}, and \cdf{method-combination}.

\begin{itemize}

\item  
The class \cdf{standard-method} is the default class of
methods that are defined by the forms \cdf{defmethod}, 
\cdf{defgeneric}, \cdf{generic-function}.%, \cdf{generic-flet}, 
%\cdf{generic-labels}, and \cdf{with-added-methods}.

\item 
The class \cdf{standard-generic-function} is the default class of 
generic functions defined by the forms \cdf{defmethod},
\cdf{defgeneric}, \cdf{generic-function}, %\cdf{generic-flet},
%\cdf{generic-labels}, \cdf{with-added-methods}, 
and \cdf{defclass}.

\item  The class named \cdf{standard-object} is an instance of
the class \cdf{standard-class} and is a superclass of every class that
is an instance of \cdf{standard-class} except itself.

\item  Every method combination object is an instance of a
subclass of the class \cdf{method-combination}.
\end{itemize}

\subsection{Object Creation and Initialization}
\label{Object-Creation-and-Initialization-SECTION}

The generic function \cdf{make-instance} creates and returns a new
instance of a class.  The first argument is a class or the name of a
class, and the remaining arguments form an \emph{initialization argument}
list.  

The initialization of a new instance consists of several distinct
steps, including the following: combining the explicitly supplied
initialization arguments with default values for the unsupplied
initialization arguments, checking the validity of the initialization
arguments, allocating storage for the instance, filling slots with
values, and executing user-supplied methods that perform additional
initialization.  Each step of \cdf{make-instance} is implemented by a
generic function to provide a mechanism for customizing that step.  In
addition, \cdf{make-instance} is itself a generic function and thus
also can be customized.

The \OS\ specifies system-supplied primary methods for each step and
thus specifies a well-defined standard behavior for the entire
initialization process.  The standard behavior provides four simple
mechanisms for controlling initialization:

\begin{itemize}

\item  Declaring a symbol to be an initialization argument for a
slot.  An initialization argument is declared by using the 
\cd{:initarg} slot option to \cdf{defclass}.  This provides a mechanism
for supplying a value for a slot in a call to \cdf{make-instance}.

\item  Supplying a default value form for an initialization
argument.  Default value forms for initialization arguments are
defined by using the \cd{:default-initargs} class option to 
\cdf{defclass}.  If an initialization argument is not explicitly provided
as an argument to \cdf{make-instance}, the default value form is
evaluated in the lexical environment of the \cdf{defclass} form that
defined it, and the resulting value is used as the value of the
initialization argument.

\item  Supplying a default initial value form for a slot.  A
default initial value form for a slot is defined by using the 
\cd{:initform} slot option to \cdf{defclass}.  If no initialization
argument associated with that slot is given as an argument to 
\cdf{make-instance} or is defaulted by \cd{:default-initargs}, this
default initial value form is evaluated in the lexical environment of
the \cdf{defclass} form that defined it, and the resulting value is
stored in the slot.  The \cd{:initform} form for a local slot may be
used when creating an instance, when updating an instance to conform
to a redefined class, or when updating an instance to conform to the
definition of a different class. The \cd{:initform} form for a shared
slot may be used when defining or re-defining the class.

\item  Defining methods for \cdf{initialize-instance} and 
\cdf{shared-initialize}.  The slot-filling behavior described above is
implemented by a system-supplied primary method for 
\cdf{initialize-instance} which invokes \cdf{shared-initialize}. The
generic function \cdf{shared-initialize} implements the parts of
initialization shared by these four situations: when making an
instance, when re-initializing an instance, when updating an instance
to conform to a redefined class, and when updating an instance to
conform to the definition of a different class. The system-supplied
primary method for \cdf{shared-initialize} directly implements the
slot-filling behavior described above, and \cdf{initialize-instance}
simply invokes \cdf{shared-initialize}.

\end{itemize}

\subsubsection{Initialization Arguments}

An initialization argument controls object creation and
initialization.  It is often convenient to use keyword symbols to name
initialization arguments, but the name of an initialization argument
can be any symbol, including \cdf{nil}.  An initialization argument
can be used in two ways: to fill a slot with a value or to provide an
argument for an initialization method.  A single initialization
argument can be used for both purposes.

An \emph{initialization argument list} is a list of alternating
initialization argument names and values.  Its structure is identical
to a property list and also to the portion of an argument list
processed for \cd{\&key} parameters.  As in those lists, if an
initialization argument name appears more than once in an
initialization argument list, the leftmost occurrence supplies the
value and the remaining occurrences are ignored.  The arguments to
\cdf{make-instance} (after the first argument) form an initialization
argument list.  Error checking of initialization argument names is
disabled if the keyword argument pair whose keyword is 
\cd{:allow-other-keys} and whose value is non-\cdf{nil} appears in the
initialization argument list.

An initialization argument can be associated with a slot.  If the
initialization argument has a value in the initialization argument
list, the value is stored into the slot of the newly created object,
overriding any \cd{:initform} form associated with the slot.  A
single initialization argument can initialize more than one slot.  An
initialization argument that initializes a shared slot stores its
value into the shared slot, replacing any previous value.

An initialization argument can be associated with a method.  When an
object is created and a particular initialization argument is
supplied, the generic functions \cdf{initialize-instance}, 
\cdf{shared-initialize}, and \cdf{allocate-instance} are called with that
initialization argument's name and value as a keyword argument pair.
If a value for the initialization argument is not supplied in the
initialization argument list, the method's lambda-list supplies a
default value.

Initialization arguments are used in four situations: when making an
instance, when re-initializing an instance, when updating an instance to
conform to a redefined class, and when updating an instance to conform
to the definition of a different class.

Because initialization arguments are used to control the creation and
initialization of an instance of some particular class, we say that an
initialization argument is ``an initialization argument for'' that
class.

\subsubsection{Declaring the Validity of Initialization Arguments}
\label{Declaring-the-Validity-of-Initialization-Arguments-SECTION}

Initialization arguments are checked for validity in each of the four
situations that use them.  An initialization argument may be valid in
one situation and not another. For example, the system-supplied
primary method for \cdf{make-instance} defined for the class 
\cdf{standard-class} checks the validity of its initialization arguments
and signals an error if an initialization argument is supplied that is
not declared valid in that situation.

There are two means of declaring initialization arguments valid.

\begin{itemize}

\item  Initialization arguments that fill slots are declared
valid by the \cd{:initarg} slot option to \cdf{defclass}.  The 
\cd{:initarg} slot option is inherited from superclasses.  Thus the set of
valid initialization arguments that fill slots for a class is the
union of the initialization arguments that fill slots declared
valid by that class and its superclasses. Initialization arguments
that fill slots are valid in all four contexts.

\item  Initialization arguments that supply arguments to methods
are declared valid by defining those methods.  The keyword name of
each keyword parameter specified in the method's lambda-list becomes
an initialization argument for all classes for which the method is
applicable.  Thus method inheritance controls the set of valid
initialization arguments that supply arguments to methods.  The
generic functions for which method definitions serve to declare
initialization arguments valid are as follows:

\begin{itemize}
\item Making an instance of a class: \cdf{allocate-instance},
\cdf{initialize-instance}, and \cdf{shared-initialize}.
Initialization arguments declared valid by these methods are
valid when making an instance of a class.

\item  Re-initializing an instance: the functions \cdf{reinitialize-instance}
and \cdf{shared-initialize}.
Initialization arguments declared valid by these methods are
valid when re-initializing an instance.

\item   Updating an instance to conform to a redefined class:
\cdf{update-instance-for-redefined-class}
and \cdf{shared-initialize}.
Initialization arguments declared valid by these methods are
valid when updating an instance to conform to a redefined class.

\item  Updating an instance to conform to the definition of a
different class: \cdf{update-instance-for-different-class} and 
\cdf{shared-initialize}.
Initialization arguments declared valid by these methods are
valid when updating an instance to conform to the definition
of a different class.
\end{itemize}
\end{itemize}

The set of valid initialization arguments for a class is the set of
valid initialization arguments that either fill slots or supply
arguments to methods, along with the predefined initialization
argument \cd{:allow-other-keys}.  The default value for 
\cd{:allow-other-keys} is \cdf{nil}.  The meaning of 
\cd{:allow-other-keys} is the same here as when it is passed to an ordinary
function.

\subsubsection{Defaulting of Initialization Arguments}
\label{DEFAULTING-INITIALIZATION-ARGUMENTS}

A \emph{default value form} can be supplied for an initialization
argument by using the \cd{:default-initargs} class option.  If an
initialization argument is declared valid by some particular class,
its default  value form might be specified by a different class. 
In this case \cd{:default-initargs} is used to supply a default value
for an inherited initialization argument.

The \cd{:default-initargs} option is used only to provide default
values for initialization arguments; it does not declare a symbol as a
valid initialization argument name. Furthermore, the 
\cd{:default-initargs} option is used only to provide default values for
initialization arguments when making an instance.

The argument to the \cd{:default-initargs} class option is a list of
alternating initialization argument names and forms.  Each form is the
default  value form for the corresponding initialization
argument.  The default  value form of an initialization
argument is used and evaluated only if that initialization argument
does not appear in the arguments to \cdf{make-instance} and is not
defaulted by a more specific class.  The default  value form is
evaluated in the lexical environment of the \cdf{defclass} form that
supplied it; the result is used as the initialization
argument's value.

The initialization arguments supplied to \cdf{make-instance} are combined
with defaulted initialization arguments to produce a \emph{defaulted
  initialization argument list}. A defaulted initialization argument list is a
list of alternating initialization argument names and values in which unsupplied
initialization arguments are defaulted and in 
which the explicitly supplied initialization arguments appear earlier in
the list than the defaulted initialization arguments.  Defaulted
initialization arguments are ordered according to the order in the class
precedence list of the classes that supplied the default values.

There is a distinction between the purposes of the 
\cd{:default-initargs} and the \cd{:initform} options with respect to the
initialization of slots.  The \cd{:default-initargs} class option
provides a mechanism for the user to give a default  value form
for an initialization argument without knowing whether the
initialization argument initializes a slot or is passed to a method.
If that initialization argument is not explicitly supplied in a call
to \cdf{make-instance}, the default  value form is used, just
as if it had been supplied in the call.  In contrast, the 
\cd{:initform} slot option provides a mechanism for the user to give a
default initial value form for a slot.  An \cd{:initform} form is
used to initialize a slot only if no initialization argument
associated with that slot is given as an argument to 
\cdf{make-instance} or is defaulted by \cd{:default-initargs}.

The order of evaluation of default value forms for initialization
arguments and the order of evaluation of \cd{:initform} forms are
undefined.  If the order of evaluation matters, use
\cdf{initialize-instance} or \cdf{shared-initialize} methods.

\subsubsection{Rules for Initialization Arguments}
\label{Rules-for-Initialization-Arguments-SECTION}

The \cd{:initarg} slot option may be specified more than
once for a given slot.
The following rules specify when initialization arguments may be
multiply defined:

\begin{itemize}
\item  A given initialization argument can be used to
initialize more than one slot if the same initialization argument name
appears in more than one \cd{:initarg} slot option.

\item  A given initialization argument name can appear 
in the lambda-list of more than one initialization method.

\item  A given initialization argument name can
appear both in an \cd{:initarg} slot option and in the lambda-list
of an initialization method.
\end{itemize}

If two or more initialization arguments that initialize
the same slot are given in the arguments to \cdf{make-instance}, the
leftmost of these initialization arguments in the initialization
argument list supplies the value, even if the initialization arguments
have different names.

If two or more different initialization arguments that
initialize the same slot have default values and none is given
explicitly in the arguments to \cdf{make-instance}, the initialization
argument that appears in a \cd{:default-initargs} class option in the
most specific of the classes supplies the value. If a single 
\cd{:default-initargs} class option specifies two or more initialization
arguments that initialize the same slot and none is given explicitly
in the arguments to \cdf{make-instance}, the leftmost argument in the 
\cd{:default-initargs} class option supplies the value, and the values of
the remaining default value forms are ignored.

Initialization arguments given explicitly in the
arguments to \cdf{make-instance} appear to the left of defaulted
initialization arguments. Suppose that the classes $C_1$ and
$C_2$ supply the values of defaulted initialization arguments for
different slots, and suppose that $C_1$ is more specific than
$C_2$; then the defaulted initialization argument whose value is
supplied by $C_1$ is to the left of the defaulted initialization
argument whose value is supplied by $C_2$ in the defaulted
initialization argument list.  If a single \cd{:default-initargs}
class option supplies the values of initialization arguments for two
different slots, the initialization argument whose value is specified
farther to the left in the \cdf{default-initargs} class option appears
farther to the left in the defaulted initialization argument list.

If a slot has both an \cd{:initform} form and an 
\cd{:initarg} slot option, and the initialization argument is defaulted
using \cd{:default-initargs} or is supplied to \cdf{make-instance},
the captured \cd{:initform} form is neither used nor evaluated.

The following is an example of the preceding rules:

\begin{lisp}
(defclass q () ((x :initarg a))) \\*
\\*
(defclass r (q) ((x :initarg b)) \\*
~~(:default-initargs a 1 b 2))
\end{lisp}

\begin{flushleft}
\begin{tabular*}{\textwidth}{@{}l@{\extracolsep{\fill}}ll@{}}
&\textrm{Defaulted Initialization}&\textrm{Contents} \\
\textrm{Form}&\textrm{Argument List}&\textrm{of Slot} \\
\hlinesp
\cd{(make-instance 'r)}&\cd{(a 1 b 2)}&\cd{1}\\
\cd{(make-instance 'r 'a 3)}&\cd{(a 3 b 2)}&\cd{3}\\
\cd{(make-instance 'r 'b 4)}&\cd{(b 4 a 1)}&\cd{4}\\
\cd{(make-instance 'r 'a 1 'a 2)}&\cd{(a 1 a 2 b 2)}&\cd{1} \\
\hline
\end{tabular*}
\end{flushleft}

\subsubsection{Shared-Initialize}
\label{Shared-Initialize-SECTION}

The generic function \cdf{shared-initialize} is used to fill the slots
of an instance using initialization arguments and \cd{:initform}
forms when an instance is created, when an instance is re-initialized,
when an instance is updated to conform to a redefined class, and when
an instance is updated to conform to a different class. It uses
standard method combination. It takes the following arguments: the
instance to be initialized, a specification of a set of names of slots
accessible in that instance, and any number of initialization
arguments.  The arguments after the first two must form an initialization
argument list.

The second argument to \cdf{shared-initialize} may be one of the following:

\begin{itemize}

\item  It can be a list of slot names, which specifies
the set of those slot names. 

\item  It can be \cdf{nil}, which specifies the empty set of
slot names.

\item  It can be the symbol \cdf{t}, which specifies the set of
all of the slots.

\end{itemize}

There is a system-supplied primary method for 
\cdf{shared-initialize} whose first parameter specializer is the class 
\cdf{standard-object}.  This method behaves as follows on each slot,
whether shared or local:

\begin{itemize}
\item  If an initialization argument in the initialization
argument list specifies a value for that slot, that value is stored
into the slot, even if a value has already been stored in the slot
before the method is run.  The affected slots are independent of which
slots are indicated by the second argument to \cdf{shared-initialize}.

\item  Any slots indicated by the second argument that are still
unbound at this point are initialized according to their 
\cd{:initform} forms.  For any such slot that has an \cd{:initform} form,
that form is evaluated in the lexical environment of its defining 
\cdf{defclass} form and the result is stored into the slot.  For example,
if a \cd{:before} method stores a value in the slot, the 
\cd{:initform} form will not be used to supply a value for the slot.  If
the second argument specifies a name that does not correspond to any
slots accessible in the instance, the results are unspecified.

\item  The rules mentioned in section~\ref{Rules-for-Initialization-Arguments-SECTION} are obeyed.

\end{itemize}

The generic function \cdf{shared-initialize} is called by the
system-supplied primary methods for the generic functions
\cdf{initialize-instance},
\cdf{reinitialize-instance}, 
\cdf{update-instance-for-different-class}, and
\cdf{update-instance-for-redefined-class}.
Thus methods can be written for 
\cdf{shared-initialize} to specify actions that should be taken in all of
these contexts.

\subsubsection{Initialize-Instance}

The generic function \cdf{initialize-instance} is called by 
\cdf{make-instance} to initialize a newly created instance.  It uses
standard method combination.  Methods for 
\cdf{initialize-instance} can be defined in order to perform any
initialization that cannot be achieved with the simple slot-filling
mechanisms.

During initialization, \cdf{initialize-instance} is invoked
after the following actions have been taken:

\begin{itemize} 

\item The defaulted initialization argument list has been computed by
combining the supplied initialization argument list with any default
initialization arguments for the class.

\item The validity of the defaulted initialization argument
list has been checked.  If any of the initialization arguments has not
been declared valid, an error is signaled.

\item A new instance whose slots are unbound has been created.

\end{itemize}

The generic function \cdf{initialize-instance} is called with the
new instance and the defaulted initialization arguments.  There is
a system-supplied primary method for \cdf{initialize-instance}
whose parameter specializer is the class \cdf{standard-object}.  This
method calls the generic function \cdf{shared-initialize} to fill in
the slots according to the initialization arguments and the 
\cd{:initform} forms for the slots; the generic function 
\cdf{shared-initialize} is called with the following arguments: the instance,
\cdf{t}, and the defaulted initialization arguments.

Note that \cdf{initialize-instance} provides the defaulted
initialization argument list in its call to \cdf{shared-initialize},
so the first step performed by the system-supplied primary method for
\cdf{shared-initialize} takes into account both the initialization
arguments provided in the call to \cdf{make-instance} and the
defaulted initialization argument list.

Methods for \cdf{initialize-instance} can be defined to specify
actions to be taken when an instance is initialized.  If only \cd{:after}
methods for \cdf{initialize-instance} are defined, they will be
run after the system-supplied primary method for initialization and
therefore they will not interfere with the default behavior of 
\cdf{initialize-instance}.

The \OS\ provides two functions that are useful in the bodies of 
\cdf{initialize-instance} methods.  The function \cdf{slot-boundp}
returns a boolean value that indicates whether a specified slot has a
value; this provides a mechanism for writing \cd{:after} methods for
\cdf{initialize-instance} that initialize slots only if they have
not already been initialized.  The function \cdf{slot-makunbound}
causes the slot to have no value.

\subsubsection{Definitions of Make-Instance and Initialize-Instance}

The generic function \cdf{make-instance} behaves as if it were defined as
follows, except that certain optimizations are permitted:

\begin{lisp}
(defmethod make-instance ((class standard-class) \&rest initargs) \\*
~~(setq initargs (default-initargs class initargs)) \\*
~~... \\*
~~(let ((instance (apply \#'allocate-instance class initargs))) \\*
~~~~(apply \#'initialize-instance instance initargs) \\*
~~~~instance)) \\
\\
(defmethod make-instance ((class-name symbol) \&rest initargs) \\*
~~(apply \#'make-instance (find-class class-name) initargs))
\end{lisp}

%This is the code:
%(defmethod make-instance ((class standard-class) &rest initargs)
%  (setq initargs (default-initargs class initargs))
%  (let* ((proto (class-prototype class))
%         (methods 
%           (append
%	      (compute-applicable-methods #'allocate-instance `(,class))
%	      (compute-applicable-methods #'initialize-instance `(,proto))
%	      (compute-applicable-methods #'shared-initialize `(,proto nil)))))
%	 (unless
%	   (subsetp
%	     (let ((keys '()))
%	       (do ((plist initargs (cddr plist)))
%		   ((null plist) keys)
%	 	 (push (car plist) keys)))
%	     (union 
%	       (class-slot-initargs class)
%	       (reduce #'union (mapcar #'function-keywords methods))))
%	   (error ...)))
%  (let ((instance (apply #'allocate-instance class initargs)))
%    (apply #'initialize-instance instance initargs)
%    instance))

The elided code in the definition of \cdf{make-instance} checks the
supplied initialization arguments to determine whether an initialization
argument was supplied that neither filled a slot nor supplied an argument
to an applicable method. This check could be implemented using the generic
functions \cdf{class-prototype}, \cdf{compute-applicable-methods}, 
\cdf{function-keywords}, and \cdf{class-slot-initargs}. See the third
part of the \CLOS\ specification for a
description of this initialization argument check.

The generic function \cdf{initialize-instance} behaves as if it were
defined as follows, except that certain optimizations are permitted:

\begin{lisp}
(defmethod initialize-instance \\*
~~~~~~~~~~~((instance standard-object) \&rest initargs) \\*
~~(apply \#'shared-initialize instance t initargs)))
\end{lisp}

These procedures can be customized at either the Programmer Interface level,
the meta-object level, or both.  

Customizing at the Programmer Interface level includes using the 
\cd{:initform}, \cd{:initarg}, and \cd{:default-initargs} options to
\cdf{defclass}, as well as defining methods for \cdf{make-instance}
and \cdf{initialize-instance}.  It is also possible to define
methods for \cdf{shared-initialize}, which would be invoked by the
generic functions \cdf{reinitialize-instance}, 
\cdf{update-instance-for-redefined-class}, 
\cdf{update-instance-for-different-class}, and 
\cdf{initialize-instance}.  The meta-object level supports additional
customization by allowing methods to be defined on 
\cdf{make-instance}, \cdf{default-initargs}, and 
\cdf{allocate-instance}.  Parts~2 and~3 of the \CLOS\ specification document each of these generic
functions and the system-supplied primary methods.
[The third part
has not yet been approved by X3J13 for inclusion in the forthcoming
Common Lisp standard and is not included in this book.---GLS]

Implementations are permitted to make certain optimizations to 
\cdf{initialize-instance} and \cdf{shared-initialize}.  The
description of \cdf{shared-initialize} in
section~\ref{Functions-in-the-Programmer-Interface-SECTION}
mentions the
possible optimizations.

Because of optimization, the check for valid initialization arguments
might not be implemented using the generic functions 
\cdf{class-prototype}, \cd{compute-applicable-methods}, 
\cdf{function-keywords}, and \cdf{class-slot-initargs}. In addition,
methods for the generic function \cdf{default-initargs} and the
system-supplied primary methods for \cdf{allocate-instance}, 
\cdf{initialize-instance},
and \cdf{shared-initialize} might not be called on
every call to \cdf{make-instance} or might not receive exactly the
arguments that would be expected.

\subsection{Redefining Classes}
\label{Redefining-Classes-SECTION}

A class that is an instance of \cdf{standard-class} can be redefined
if the new class will also be an instance of \cdf{standard-class}.
Redefining a class modifies the existing class object to reflect the
new class definition; it does not create a new class object for the
class.  Any method object created by a \cd{:reader}, \cd{:writer}, or
\cd{:accessor} option specified by the old \cdf{defclass} form is
removed from the corresponding generic function.
Methods specified by the new \cdf{defclass} form are added.

% any function specified by the \cd{:constructor}
% option of the old \cdf{defclass} form is removed from the
% corresponding symbol function cell.

When the class \emph{C} is redefined, changes are propagated to its instances
and to instances of any of its subclasses.  Updating such an
instance occurs at an implementation-dependent time, but no later than
the next time a slot of that instance is read or written.  Updating an
instance does not change its identity as defined by the \cdf{eq}
function.  The updating process may change the slots of that
particular instance, but it does not create a new instance.  Whether
updating an instance consumes storage is implementation-dependent.

Note that redefining a class may cause slots to be added or deleted.
If a class is redefined in a way that changes the set of local slots
accessible in instances, the instances will be updated.  It is
implementation-dependent whether instances are updated if a class is
redefined in a way that does not change the set of local slots
accessible in instances.

The value of a slot that is specified as shared both in the old class
and in the new class is retained.  If such a shared slot was unbound
in the old class, it will be unbound in the new class.  Slots that
were local in the old class and that are shared in the new class are
initialized.  Newly added shared slots are initialized.

Each newly added shared slot is set to the result of evaluating the
captured \cd{:initform} form for the slot that was specified in the
\cdf{defclass} form for the new class. If there is no \cd{:initform}
form, the slot is unbound.

If a class is redefined in such a way that the set of local slots
accessible in an instance of the class is changed, a two-step process
of updating the instances of the class takes place.  The process may
be explicitly started by invoking the generic function 
\cdf{make-instances-obsolete}.  This two-step process can happen in other
circumstances in some implementations.  For example, in some
implementations this two-step process will be triggered if the order
of slots in storage is changed.

The first step modifies the structure of the instance by adding new
local slots and discarding local slots that are not defined in the new
version of the class.
The second step initializes the newly added local slots and performs
any other user-defined actions. These steps are further specified
in the next two sections.

\subsubsection{Modifying the Structure of Instances}

The first step modifies the structure of instances of the redefined
class to conform to its new class definition.  Local slots specified
by the new class definition that are not specified as either local or
shared by the old class are added, and slots not specified as either
local or shared by the new class definition that are specified as
local by the old class are discarded. The names of these added and discarded
slots are passed as arguments to \cdf{update-instance-for-redefined-class}
as described in the next section.

The values of local slots specified by both the new and old classes
are retained. If such a local slot was unbound, it remains unbound.

The value of a slot that is specified as shared in the old class and
as local in the new class is retained.  If such a shared slot was
unbound, the local slot will be unbound.

\subsubsection{Initializing Newly Added Local Slots}

The second step initializes the newly added local slots and performs
any other user-defined actions.  This step is implemented by the generic
function \cdf{update-instance-for-redefined-class}, which is called after
completion of the first step of modifying the structure of the
instance.

The generic function \cdf{update-instance-for-redefined-class} takes
four required arguments: the instance being updated after it has
undergone the first step, a list of the names of local slots that were
added, a list of the names of local slots that were discarded, and a
property list containing the slot names and values of slots that were
discarded and had values.  Included among the discarded slots are
slots that were local in the old class and that are shared in the new
class.

The generic function \cdf{update-instance-for-redefined-class} also
takes any number of initialization arguments.  When it is called by
the system to update an instance whose class has been redefined, no
initialization arguments are provided.

There is a system-supplied primary method for the generic function
\cdf{update-instance-for-redefined-class} whose parameter specializer for
its instance argument is the class \cdf{standard-object}.  First this
method checks the validity of initialization arguments and signals an
error if an initialization argument is supplied that is not declared
valid (see
section~\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION}.)
Then it calls the generic function
\cdf{shared-initialize} with the following arguments: the instance,
the list of names of the newly added slots, and the initialization
arguments it received.

\subsubsection{Customizing Class Redefinition}

Methods for \cdf{update-instance-for-redefined-class} may be defined
to specify actions to be taken when an instance is updated.  If only
\cd{:after} methods for \cdf{update-instance-for-redefined-class} are
defined, they will be run after the system-supplied primary method for
initialization and therefore will not interfere with the default
behavior of \cdf{update-instance-for-redefined-class}.  Because no
initialization arguments are passed to 
\cdf{update-instance-for-redefined-class} when it is called by the system,
the \cd{:initform} forms for slots that are filled by \cd{:before}
methods for \cdf{update-instance-for-redefined-class} will not be
evaluated by \cdf{shared-initialize}.

Methods for \cdf{shared-initialize} may be defined to customize class
redefinition (see section~\ref{Shared-Initialize-SECTION}).

\subsubsection{Extensions}

There are two allowed extensions to class redefinition: 

\begin{itemize}

\item  The \OS\ may be extended to permit the new class
to be an instance of a metaclass other than the metaclass of the
old class.

\item  The \OS\ may be extended to support an updating process
when either the old or the new class is an instance of a
class other than \cdf{standard-class} that is not a built-in class.
\end{itemize}

\subsection{Changing the Class of an Instance}
\label{Changing-the-Class-of-an-Instance-SECTION}

The function \cdf{change-class} can be used to change the class of an
instance from its current class, $C_{from}$, to a
different class, $C_{to}$; it changes the
structure of the instance to conform to the definition of the class
$C_{to}$.

Note that changing the class of an instance may cause slots to be
added or deleted. 

When \cdf{change-class} is invoked on an instance, a two-step updating
process takes place.  The first step modifies the structure of
the instance by adding new local slots and discarding local slots that
are not specified in the new version of the instance.  The second step
initializes the newly added local slots and performs any other
user-defined actions. These steps are further described in the
following two sections.

\subsubsection{Modifying the Structure of an Instance}

In order to make an instance conform to the class $C_{to}$, local slots
specified by the class $C_{to}$ that are not specified by the class $C_{from}$
are added, and local slots not specified by 
the class $C_{to}$ that are specified by the 
class $C_{from}$ are discarded.

The values of local slots specified by both the class $C_{to}$ and the class
$C_{from}$ are retained. If such a local slot was unbound, it remains 
unbound.

The values of slots specified as shared in the class $C_{from}$ and as local in
the class $C_{to}$ are retained. 

This first step of the update does not affect the values of any shared
slots.

\subsubsection{Initializing Newly Added Local Slots}
 
The second step of the update initializes the newly added slots and
performs any other user-defined actions.  This step is implemented by
the generic function \cdf{update-instance-for-different-class}.  The
generic function \cdf{update-instance-for-different-class} is invoked
by \cdf{change-class} after the first step of the update has been
completed.

The generic function \cdf{update-instance-for-different-class} is
invoked on two arguments computed by \cdf{change-class}.  The first
argument passed is a copy of the instance being updated and is an
instance of the class $C_{from}$; this copy has
dynamic extent within the generic function \cdf{change-class}.  The
second argument is the instance as updated so far by \cdf{change-class}
and is an instance of the class $C_{to}$.

The generic function \cdf{update-instance-for-different-class} also
takes any number of initialization arguments.  When it is called by
\cdf{change-class}, no initialization arguments are provided.

There is a system-supplied primary method for the generic function
\cdf{update-instance-for-different-class} that has two parameter
specializers, each of which is the class \cdf{standard-object}.  First
this method checks the validity of initialization arguments and
signals an error if an initialization argument is supplied that is not
declared valid (see section~\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION}).
Then it calls the
generic function \cdf{shared-initialize} with the following arguments:
the instance, a list of names of the newly added slots, and the
initialization arguments it received.

\subsubsection{Customizing the Change of Class of an Instance}

Methods for \cdf{update-instance-for-different-class} may be defined
to specify actions to be taken when an instance is updated.  If only
\cd{:after} methods for \cdf{update-instance-for-different-class} are
defined, they will be run after the system-supplied primary method for
initialization and will not interfere with the default behavior of
\cdf{update-instance-for-different-class}.  Because no initialization
arguments are passed to \cdf{update-instance-for-different-class} when
it is called by \cdf{change-class}, the \cd{:initform} forms for slots
that are filled by \cd{:before} methods for 
\cdf{update-instance-for-different-class} will not be evaluated by 
\cdf{shared-initialize}.

Methods for \cdf{shared-initialize} may be defined to customize class
redefinition (see section~\ref{Shared-Initialize-SECTION}).

\subsection{Reinitializing an Instance}
\label{Reinitializing-an-Instance-SECTION}

The generic function \cdf{reinitialize-instance} may be used to change
the values of slots according to initialization arguments.

The process of reinitialization changes the values of some slots and
performs any user-defined actions.

Reinitialization does not modify the structure
of an instance to add or delete slots, and it does not use any 
\cd{:initform} forms to initialize slots.

The generic function \cdf{reinitialize-instance} may be called
directly.  It takes one required argument, the instance.  It also
takes any number of initialization arguments to be used by methods for
\cdf{reinitialize-instance} or for \cdf{shared-initialize}. The
arguments after the required instance must form an initialization
argument list.

There is a system-supplied primary method for 
\cdf{reinitialize-instance} whose parameter specializer is the class 
\cdf{standard-object}.  First this method checks the validity of
initialization arguments and signals an error if an initialization
argument is supplied that is not declared valid (see
section~\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION}).
Then it calls the generic function 
\cdf{shared-initialize} with the following arguments: the instance, 
\cdf{nil}, and the initialization arguments it received.

\subsubsection{Customizing Reinitialization}

Methods for the generic function \cdf{reinitialize-instance} may be defined to specify
actions to be taken when an instance is updated.  If only \cd{:after}
methods for \cdf{reinitialize-instance} are defined, they will be run
after the system-supplied primary method for initialization and
therefore will not interfere with the default behavior of 
\cdf{reinitialize-instance}.

Methods for \cdf{shared-initialize} may be defined to customize class
redefinition (see section~\ref{Shared-Initialize-SECTION}).

\section{Functions in the Programmer Interface}
\label{Functions-in-the-Programmer-Interface-SECTION}

This section describes the functions, macros, special operators, and
generic functions provided by the \CLOS\ Programmer Interface.  The
Programmer Interface comprises the functions and macros that are
sufficient for writing most object-oriented programs.

This section is reference material that requires an understanding of
the basic concepts of the Common Lisp Object System.  The functions
are arranged in alphabetical order for convenient reference.

The description of each function, macro, special operator,
and generic function includes its purpose, its syntax, the
semantics of its arguments and returned values, and often an example
and cross-references to related functions.

The syntax description for a function, macro, or special operator
describes its parameters.
The description of a generic function includes descriptions of the
methods that are defined on that generic function by the \CLOS.  A
\emph{method signature} is used to describe the parameters and
parameter specializers for each method.

The following is an example of the format for
the syntax description of a generic function with the method
signature for one primary method:

\begin{defun}[Generic function][Primary method]
f x y &optional z &key :k \\
f (x class) (y t) &optional z &key :k

This description indicates that the generic function \cdf{f} 
has two required parameters, \emph{x} and \emph{y}.  In addition,
there is an optional parameter \emph{z} and a keyword parameter \cd{:k}.

The method signature indicates that this method on the generic function
\cdf{f} has two required parameters, \emph{x}, which must be an
instance of the class \cdf{class}, and \emph{y}, which can be any
object. In addition, there is an optional parameter \emph{z} and a
keyword parameter \cd{:k}.  The signature also indicates that this
method on \cdf{f} is a primary method and has no qualifiers.

The syntax description for a generic function describes the
lambda-list of the generic function itself, while the method
signatures describe the lambda-lists of the defined methods.
\end{defun}   %misplaced to make better break

The generic functions described in this book are all standard
generic functions.  They all use standard method combination.

Any implementation of the \CLOS\ is allowed to provide additional methods
on the generic functions described here.

It is useful to categorize the functions and macros according to their
role in this standard:
\begin{itemize}
\item 
\emph{Tools used for simple object-oriented programming}

These tools allow for defining new classes, methods, and generic 
functions and for making instances.   Some tools used within
method bodies are also listed here.   Some of the macros listed here have 
a corresponding function that performs the same task at a lower level of
abstraction. 

\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\cdf{call-next-method}&\cdf{initialize-instance}\\
\cdf{change-class}&\cdf{make-instance}\\
\cdf{defclass}&\cdf{next-method-p}\\
\cdf{defgeneric}&\cdf{slot-boundp}\\
\cdf{defmethod}&\cdf{slot-value}\\
%\cdf{generic-flet}
&\cdf{with-accessors}\\
\cdf{generic-function}&%\cdf{with-added-methods}
\\
%\cdf{generic-labels}
&\cdf{with-slots}
\end{tabular}
\end{flushleft}

\item 
\emph{Functions underlying the commonly used macros}

\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\cdf{add-method}&\cdf{reinitialize-instance}\\
\cdf{class-name}&\cdf{remove-method}\\
\cdf{compute-applicable-methods}&\cdf{shared-initialize}\\
\cdf{ensure-generic-function}&\cdf{slot-exists-p}\\
\cdf{find-class}&\cdf{slot-makunbound}\\
\cdf{find-method}&\cdf{slot-missing}\\
\cdf{function-keywords}&\cdf{slot-unbound}\\
\cdf{make-instances-obsolete}&\cdf{update-instance-for-different-class}\\
\cdf{no-applicable-method}&\cdf{update-instance-for-redefined-class}\\
\cdf{no-next-method}&
\end{tabular}
\end{flushleft}

\item 
\emph{Tools for declarative method combination}

\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\cdf{call-method}&\cdf{method-combination-error}\\
\cdf{define-method-combination}&\cdf{method-qualifiers}\\
\cdf{invalid-method-error}&
\end{tabular}
\end{flushleft}

\item 
\emph{General Common Lisp support tools}

\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\cdf{class-of}&\cdf{print-object}\\
\cdf{documentation}&\cdf{symbol-macrolet}
\end{tabular}
\end{flushleft}

[Note that \cdf{describe} appeared in this list in the original CLOS proposal
\cite{SIGPLAN-CLOS,LASC-CLOS-PART-2}, but X3J13 voted in March 1989 \issue{DESCRIBE-UNDERSPECIFIED}
not to make \cdf{describe} a generic function after all (see
\cdf{describe-object}).---GLS]

\end{itemize}
\noindent
[At this point the original CLOS report contained a description of the
\Mchoice{ } and \Mind{} notation; that description is omitted here.
I have adopted the notation for use
throughout this book. It is described in
section~\ref{FUNCTION-HEADER-NOTATION-SECTION}.---GLS]

\begin{defun}[Generic function][Primary method]
add-method generic-function method \\
add-method (generic-function standard-generic-function) (method method)

The generic function \cdf{add-method} adds a method to a generic
function.  It destructively modifies the generic function and returns
the modified generic function as its result.

The \emph{generic-function} argument is a generic function
object.

The \emph{method} argument is a method object.  The lambda-list of
the method function must be congruent with the lambda-list of the
generic function, or an error is signaled.

The modified generic function is returned.  The result of \cdf{add-method} 
is \cdf{eq} to the \emph{generic-function} argument.

If the given method agrees with an existing method of the generic
function on parameter specializers and qualifiers, the existing method
is replaced.  See section~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}
for a definition of agreement in this context.

If the method object is a method object of another generic function,
an error is signaled.

See section~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}
as well as
\cdf{defmethod},
\cdf{defgeneric},
\cdf{find-method},
and \cdf{remove-method}.
\end{defun}

\begin{defmac}
call-method method next-method-list

The macro \cdf{call-method} is used in method combination.  This macro hides
the implementation-dependent details of how methods are called. It can be used only within
an effective method form, for the name \cdf{call-method} is defined only 
within the lexical scope of such a form.

The macro \cdf{call-method} invokes the specified method, supplying it
with arguments and with definitions for \cdf{call-next-method} and for
\cdf{next-method-p}.  The arguments are the arguments that were
supplied to the effective method form containing the invocation of
\cdf{call-method}.  The definitions of \cdf{call-next-method} and 
\cdf{next-method-p} rely on the list of method objects given as the second
argument to \cdf{call-method}.

The \cdf{call-next-method} function available to the method that
is the first subform will call the first method in the list that
is the second subform.  The \cdf{call-next-method} function
available in that method, in turn, will call the second
method in the list that is the second subform, and so on, until
the list of next methods is exhausted.

The \emph{method} argument is a method object; the \emph{next-method-list}
argument is a list of method objects.

A list whose first element is the symbol \cdf{make-method} and whose
second element is a Lisp form can be used instead of a method object
as the first subform of \cdf{call-method} or as an element of the
second subform of \cdf{call-method}.  Such a list specifies a method
object whose method function has a body that is the given form.

The result of \cdf{call-method} is the value or values returned by
the method invocation.

See \cdf{call-next-method}, \cdf{define-method-combination}, and
\cdf{next-method-p}.
\end{defmac}

\begin{defun}[Function]
call-next-method &rest args

The function \cdf{call-next-method} can be used within the body of a
method defined by a method-defining form to call the next method.

The function \cdf{call-next-method} returns the value or values
returned by the method it calls.  If there is no next method, 
the generic function \cdf{no-next-method} is called.

The type of method combination used determines which 
methods can invoke \cdf{call-next-method}.  The standard method
combination type allows \cdf{call-next-method}
to be used within primary
methods and \cd{:around} methods.

The standard method combination
type defines the next method according to the following rules:

\begin{itemize}
\item 
If \cdf{call-next-method} is used in an \cd{:around} method,
the next method is the next most specific \cd{:around} method, if one is
applicable.

\item 
If there are no \cd{:around} methods at all or if 
\cdf{call-next-method} is called by the least specific \cd{:around}
method,  other methods are called as follows:

\begin{itemize}
\item  All the \cd{:before} methods are called, in
most-specific-first order.  The function \cdf{call-next-method}
cannot be used in \cd{:before} methods.

\item 
The most specific primary method is called.  Inside the body of a
primary method, \cdf{call-next-method} may be used to pass control to
the next most specific primary method.  The generic function 
\cdf{no-next-method} is called if \cdf{call-next-method} is used and there
are no more primary methods.

\item  All the \cd{:after} methods are called in
most-specific-last order.  The function \cdf{call-next-method}
cannot be used in \cd{:after} methods.
\end{itemize}
\end{itemize}

For further discussion of the use of \cdf{call-next-method}, see
sections~\ref{Standard-Method-Combination-SECTION}
and~\ref{Built-in-Method-Combination-Types-SECTION}.

When \cdf{call-next-method} is called with no arguments, it passes the
current method's original arguments to the next method.  Neither
argument defaulting, nor using \cdf{setq}, nor rebinding variables
with the same names as parameters of the method affects the values
\cdf{call-next-method} passes to the method it calls.

When \cdf{call-next-method} is called with arguments, the next method
is called with those arguments.  When providing arguments to 
\cdf{call-next-method}, the following rule must be satisfied or an error is
signaled: The ordered set of methods applicable for a changed set of
arguments for \cdf{call-next-method} must be the same as the ordered set of
applicable methods for the original arguments to the generic function.
Optimizations of the error checking are possible, but they must 
not change the semantics of \cdf{call-next-method}.

If \cdf{call-next-method} is called with arguments but omits
optional arguments, the next method called defaults those arguments.

The function \cdf{call-next-method} returns the value or values
returned by the method it calls.  

Further computation is possible after \cdf{call-next-method} returns.

The definition of the function \cdf{call-next-method} has lexical scope (for it
is defined only within the body of a method defined by a method-defining form)
and indefinite extent.

For generic functions using a type of method combination defined by
the short form of \cdf{define-method-combination}, 
\cdf{call-next-method} can be used in \cd{:around} methods only.

The function \cdf{next-method-p} can be used to test whether or not there is
a next method.

If \cdf{call-next-method} is used in methods that do not support it,
an error is signaled.

See sections~\ref{Method-Selection-and-Combination-SECTION},
\ref{Standard-Method-Combination-SECTION}, and
\ref{Built-in-Method-Combination-Types-SECTION} as well as the functions
\cdf{define-method-combination},
\cdf{next-method-p},
and \cdf{no-next-method}.
\end{defun}


\begin{defun}[Generic function][Primary method]
change-class instance new-class \\
change-class (instance standard-object) (new-class standard-class) \\
change-class (instance t) (new-class symbol)

The generic function \cdf{change-class} changes the class of an
instance to a new class.  It destructively modifies and returns the
instance.

If in the old class there is any slot of the same name as a local
slot in the new class, the value of that slot is retained.  This
means that if the slot has a value, the value returned by 
\cdf{slot-value} after \cdf{change-class} is invoked is \cdf{eql} to the
value returned by \cdf{slot-value} before \cdf{change-class} is
invoked.  Similarly, if the slot was unbound, it remains
unbound.  The other slots are initialized as described in
section~\ref{Changing-the-Class-of-an-Instance-SECTION}.

The \emph{instance} argument is a Lisp object.

The \emph{new-class} argument is a class object or a symbol that names
a class. 

If the second of the preceding methods is selected, that method
invokes \cdf{change-class} on \emph{instance} and 
\cd{(find-class \emph{new-class})}.

The modified instance is returned.  The result of \cdf{change-class}
is \cdf{eq} to the \emph{instance} argument.

Examples:

\begin{lisp}
(defclass position () ()) \\
\\
(defclass x-y-position (position) \\*
~~((x :initform 0 :initarg :x) \\*
~~~(y :initform 0 :initarg :y))) \\
\\
(defclass rho-theta-position (position) \\*
~~((rho :initform 0) \\*
~~~(theta :initform 0))) \\
\\
(defmethod update-instance-for-different-class :before \\*
~~~~~~~~~~~((old x-y-position)  \\*
~~~~~~~~~~~~(new rho-theta-position) \\*
~~~~~~~~~~~~\&key) \\
~~;; Copy the position information from old to new to make new \\*
~~;; be a rho-theta-position at the same position as old. \\*
~~(let ((x (slot-value old 'x)) \\*
~~~~~~~~(y (slot-value old 'y))) \\*
~~~~(setf (slot-value new 'rho) (sqrt (+ (* x x) (* y y))) \\*
~~~~~~~~~~(slot-value new 'theta) (atan y x))))
\end{lisp}
\begin{lisp}
;;; At this point an instance of the class x-y-position can be \\*
;;; changed to be an instance of the class rho-theta-position \\*
;;; using change-class: \\
\\
(setq p1 (make-instance 'x-y-position :x 2 :y 0)) \\
\\
(change-class p1 'rho-theta-position) \\
\\
;;; The result is that the instance bound to p1 is now \\*
;;; an instance of the class rho-theta-position. \\*
;;; The update-instance-for-different-class method \\*
;;; performed the initialization of the rho and theta \\*
;;; slots based on the values of the x and y slots, \\*
;;; which were maintained by the old instance.
\end{lisp}

After completing all other actions, \cdf{change-class} invokes the generic
function \cdf{update-instance-for-different-class}.  The generic function
\cdf{update-instance-for-different-class}
can be used to assign values to slots in the transformed instance.

The generic function \cdf{change-class} has several semantic difficulties.
First, it performs a destructive operation that can be invoked within a
method on an instance that was used to select that method. When multiple
methods are involved because methods are being combined,
the methods currently executing or about to be executed
may no longer be applicable.  Second, some implementations might use compiler
optimizations of slot access, and when the class of an instance is
changed the assumptions the compiler made might be violated.
This implies that a programmer must not use 
\cdf{change-class} inside a method if any methods for that generic function 
access any slots, or the results are undefined.

See section~\ref{Changing-the-Class-of-an-Instance-SECTION} as well as
\cdf{update-instance-for-different-class}.
\end{defun}

\begin{defun}[Generic function][Primary method]
class-name class \\
class-name (class class)

The generic function \cdf{class-name} takes a class object and returns its
name.

The \emph{class} argument is a class object.
The name of the given class is returned.

The name of an anonymous class is \cdf{nil}.

If \emph{S} is a symbol such that \emph{S}~=\cd{(class-name \emph{C})} and \emph{C}~=
\cd{(find-class \emph{S})}, then \emph{S} is the proper name of \emph{C} (see section~\ref{Classes-SECTION}).

See also section~\ref{Classes-SECTION} and \cdf{find-class}.
\end{defun}

\begin{defun}[Generic function][Primary method]
(setf class-name) new-value class \\
(setf class-name) new-value (class class)

The generic function \cd{(setf class-name)} takes a class object and sets
its name.

The \emph{class} argument is a class object.
The \emph{new-value} argument is any object.
\end{defun}

\begin{defun}[Function]
class-of object

The function \cdf{class-of} returns the class of which
the given object is an instance.
The argument to \cdf{class-of} may be any Common Lisp object.
\end{defun}

\begin{defun}[Function]
compute-applicable-methods generic-function function-arguments

Given a generic function and a set of arguments, the function
\cdf{compute-applicable-methods} returns the set of methods
that are applicable for those arguments.

The methods are
sorted according to precedence order.
See section~\ref{Method-Selection-and-Combination-SECTION}.

The \emph{generic-function} argument must be a generic function object.
The \emph{function-arguments} argument is a list of the arguments to
that generic function.
The result is a list of the applicable methods in order of precedence.
See section~\ref{Method-Selection-and-Combination-SECTION}.
\end{defun}

\begin{defmac}
defclass class-name ({superclass-name}*)
         ({slot-specifier}*) <?class-option>

\begin{tabbing}
\emph{class-name} ::= \emph{symbol} \\
\emph{superclass-name} ::= \emph{symbol}\\
%\cleartabs
\emph{slot-specifier} ::= \emph{slot-name} {\Mor} (\emph{slot-name}
$\lbrack\!\lbrack\downarrow\!slot\mhyphen option\,\rbrack\!\rbrack$)\\
\emph{slot-name} ::= \emph{symbol}\\
\emph{slot-option} ::= \=\Mstar{{\cd{:reader} \emph{reader-function-name}}} \\
\Mor~\Mstar{{\cd{:writer} \emph{writer-function-name}}} \\
\Mor~\Mstar{{\cd{:accessor} \emph{reader-function-name}}} \\
\Mor~\Mgroup{\cd{:allocation} \emph{allocation-type}} \\
\Mor~\Mstar{{\cd{:initarg} \emph{initarg-name}}} \\
\Mor~\Mgroup{\cd{:initform} \emph{form}} \\
\Mor~\Mgroup{\cd{:type} \emph{type-specifier}} \\
\Mor~\Mgroup{\cd{:documentation} \emph{string}}
\end{tabbing}

\begin{tabbing}
\emph{reader-function-name} ::= \emph{symbol}\\
\emph{writer-function-name} ::= \emph{function-name}\\
\emph{function-name} ::= \Mgroup{\emph{symbol} {\Mor} \cd{(setf \emph{symbol})}}\\
\emph{initarg-name} ::= \emph{symbol}\\
\emph{allocation-type} ::= \cd{:instance {\Mor} :class}\\
\emph{class-option} ::= \=\cd{(:default-initargs \emph{initarg-list})} \\
\Mor~\cd{(:documentation \emph{string})} \\
\Mor~\cd{(:metaclass \emph{class-name})}  \\
\emph{initarg-list} ::= \Mstar{\emph{initarg-name default-initial-value-form}}
\end{tabbing}
The macro \cdf{defclass} defines a new named class.  It returns the new class
object as its result.

The syntax of \cdf{defclass} provides options for specifying
initialization arguments for slots, for specifying default
initialization values for slots, and for requesting that methods on
specified generic functions be automatically generated for reading and
writing the values of slots.  No reader or writer functions are
defined by default; their generation must be explicitly requested.

Defining a new class also causes a type of the same name to be
defined.  The predicate \cd{(typep \emph{object class-name})} returns
true if the class of the given object is \emph{class-name} itself or
a subclass of the class \emph{class-name}.  A class object can be used
as a type specifier.  Thus \cd{(typep \emph{object class})} returns true
if the class of the \emph{object} is \emph{class} itself or a
subclass of \emph{class}.

The \emph{class-name} argument is a non-\cdf{nil} symbol.  It becomes
the proper name of the new class.  If a class with the same proper
name already exists and that class is an instance of 
\cdf{standard-class}, and if the \cdf{defclass} form for the definition of the
new class specifies a class of class \cdf{standard-class}, the definition
of the existing class is replaced.

Each \emph{superclass-name} argument is a non-\cdf{nil} symbol that
specifies a direct superclass of the new class.  The new class will
inherit slots and methods from each of its direct superclasses, from
their direct superclasses, and so on.  See
section~\ref{Inheritance-SECTION}
for a discussion of how slots and methods are inherited.

Each \emph{slot-specifier} argument is the name of the slot or a list
consisting of the slot name followed by zero or more slot options.
The \emph{slot-name} argument is a symbol that is syntactically valid
for use as a variable name.  If there are any duplicate
slot names, an error is signaled.

The following slot options are available:

\begin{itemize}

\item 
The \cd{:reader} slot option specifies that an unqualified method is
to be defined on the generic function named \emph{reader-function-name} to read
the value of the given slot. 
The \emph{reader-function-name} argument is a non-\cdf{nil}
symbol.  The \cd{:reader} slot option may be specified more than once
for a given slot.

\item  
The \cd{:writer} slot option specifies that an unqualified method is
to be defined on the generic function named \emph{writer-function-name} to write
the value of the slot.  The 
\emph{writer-function-name} argument is a function-name.
The \cd{:writer} slot option may be specified more than once for a
given slot.

\item  
The \cd{:accessor} slot option specifies that an unqualified method
is to be defined on the generic function named \emph{reader-function-name} to
read the value of the given slot 
and that an unqualified method is to be defined on the generic
function named \cd{(setf \emph{reader-function-name})} to be
used with \cdf{setf} to modify the value of the slot.  The
\emph{reader-function-name} argument is a non-\cdf{nil} symbol. 
The \cd{:accessor} slot option may be specified more than once for a
given slot.

\item  
The \cd{:allocation} slot option is used to specify where storage is
to be allocated for the given slot.  Storage for a slot may be located
in each instance or in the class object itself, for example.  The value of the
\emph{allocation-type} argument can be either the keyword \cd{:instance} 
or the keyword \cd{:class}.  The \cd{:allocation} slot option may be
specified at most once for a given slot.  If the \cd{:allocation}
slot option is not specified, the effect is the same as specifying
\cd{:allocation :instance}.

\begin{itemize}
\item
If \emph{allocation-type} is \cd{:instance}, a local slot of the given name
is allocated in each instance of the class.  

\item
If \emph{allocation-type} is \cd{:class}, a shared slot of the given
name is allocated.  The value of the slot is shared by all instances of the class.
If a class $C_1$ defines such a shared slot, any subclass $C_2$ of
$C_1$ will share this single slot unless the \cdf{defclass} form
for $C_2$ specifies a slot of the same name or there is a
superclass of $C_2$ that precedes $C_1$ in the class precedence
list of $C_2$ and that defines a slot of the same name.
\end{itemize}

\item
The \cd{:initform} slot option is used to provide a default
initial value form to be used in the initialization of the slot.  The
\cd{:initform} slot option may be specified at most once for a given
slot.  This form is evaluated every time it is used to initialize the
slot.  The lexical
environment in which this form is evaluated is the lexical environment
in which the \cdf{defclass} form was evaluated.  Note that the lexical
environment refers both to variables and to functions.  For local
slots, the dynamic environment is the dynamic environment in which
\cdf{make-instance} was called; for shared slots, the dynamic
environment is the dynamic environment in which the \cdf{defclass}
form was evaluated.  See section~\ref{Object-Creation-and-Initialization-SECTION}.

No implementation is permitted to extend the syntax of \cdf{defclass}
to allow \cd{(\emph{slot-name form})} as an abbreviation for 
\cd{(\emph{slot-name} :initform \emph{form})}.

\item 
The \cd{:initarg} slot option declares an initialization argument
named \emph{initarg-name} and specifies that this initialization argument
initializes the given slot.  If the initialization argument has a
value in the call to \cdf{initialize-instance}, the value will be
stored into the given slot, and the slot's \cd{:initform} slot option, if
any, is not evaluated.  If none of the initialization arguments
specified for a given slot has a value, the slot is initialized
according to the \cd{:initform} slot option, if specified.  The 
\cd{:initarg} slot option can be specified more than once for a given
slot.  The \emph{initarg-name} argument can be any symbol.

\item 
The \cd{:type} slot option specifies that the contents of the slot
will always be of the specified data type.  It effectively declares
the result type of the reader generic function when applied to an
object of this class.  The result of attempting to store in a slot a
value that does not satisfy the type of the slot is undefined.  The
\cd{:type} slot option may be specified at most once for a given
slot.  The \cd{:type} slot option is further discussed in
section~\ref{Inheritance-of-Slots-and-Slot-Options-SECTION}.

\item 
The \cd{:documentation} slot option provides a documentation string
for the slot.
\end{itemize}

Each class option is an option that refers to the class as a whole
or to all class slots.  The following class options are available:

\begin{itemize}
\item 
The \cd{:default-initargs} class option is followed by a list of
alternating initialization argument names and default initial value
forms.  If any of these initialization arguments does not appear in
the initialization argument list supplied to \cdf{make-instance}, the
corresponding default initial value form is evaluated, and the
initialization argument name and the form's value are added to the end
of the initialization argument list before the instance is created
(see section~\ref{Object-Creation-and-Initialization-SECTION}).  The default
initial value form is evaluated each time it is used.  The lexical
environment in which this form is evaluated is the lexical environment
in which the \cdf{defclass} form was evaluated.  The dynamic
environment is the dynamic environment in which \cdf{make-instance}
was called.  If an initialization argument name appears more than once
in a \cd{:default-initargs} class option, an error is signaled.  The
\cd{:default-initargs} class option may be specified at most once.

\item  
The \cd{:documentation} class option causes a documentation string to be
attached to the class name.  The documentation type for this string is
\cdf{type}.  The form \cd{(documentation \emph{class-name} 'type)}
may be used to retrieve the documentation string.  The 
\cd{:documentation} class option may be specified at most once.

\item 
The \cd{:metaclass} class option is used to specify that instances of the
class being defined are to have a different metaclass than the default
provided by the system (the class \cdf{standard-class}).  The \emph{class-name}
argument is the name of the desired metaclass.  The  
\cd{:metaclass} class option may be specified at most once.
\end{itemize}

The new class object is returned as the result.

If a class with the same proper name already exists and that class is
an instance of \cdf{standard-class}, and if the \cdf{defclass} form for
the definition of the new class specifies a class of class 
\cdf{standard-class}, the existing class is redefined, and instances of it
(and its subclasses) are updated to the new definition at the time
that they are next accessed (see section~\ref{Redefining-Classes-SECTION}).

Note the following rules of \cdf{defclass} for standard classes:

\begin{itemize}

\item 
It is not required that the superclasses of a class be defined before
the \cdf{defclass} form for that class is evaluated.

\item 
All the superclasses of a class must be defined before 
an instance of the class can be made.

\item 
A class must be defined before it can be used as a parameter
specializer in a \cdf{defmethod} form.
\end{itemize}

The \OS\ may be extended to cover situations where these rules are not
obeyed.

Some slot options are inherited by a class from its superclasses, and
some can be shadowed or altered by providing a local slot description.
No class options except \cd{:default-initargs} are inherited.  For a
detailed description of how slots and slot options are inherited, see
section~\ref{Inheritance-of-Slots-and-Slot-Options-SECTION}.

The options to \cdf{defclass} can be extended.
An implementation must signal an error if it observes a class option or
a slot option that is not implemented locally.

It is valid to specify more than one reader, writer, accessor, or
initialization argument for a slot.  No other slot option may appear
more than once in a single slot description, or an error is
signaled.

If no reader, writer, or accessor is specified for a slot, the slot
can be accessed only by the function \cdf{slot-value}.

See sections \ref{Classes-SECTION},
\ref{Inheritance-SECTION},
\ref{Redefining-Classes-SECTION},
\ref{Determining-the-Class-Precedence-List-SECTION},
\ref{Object-Creation-and-Initialization-SECTION} as well as
\cdf{slot-value},
\cdf{make-instance}, and
\cdf{initialize-instance}.
\end{defmac}

\begin{defmac}
defgeneric function-name lambda-list
           <?option | {method-description}*>

\begin{tabbing}
\emph{function-name} ::= \Mgroup{\emph{symbol} {\Mor} \cd{(setf \emph{symbol})}} \\*
\emph{lambda-list} ::= \cd{(}\=\Mstar{{var}}  \\*
\>\Mopt{\cd{\&optional} \Mstar{{var {\Mor} \cd{(\emph{var})}}}}  \\*
\>\Mopt{\cd{\&rest} \emph{var}} \\*
\>\Mopt{\cd{\&key} \Mstar{keyword-parameter} \Mopt{\cd{\&allow-other-keys}}}\cd{)}
\end{tabbing}
\begin{tabbing}
\emph{keyword-parameter} ::= \emph{var} {\Mor} \cd{(\Mgroup{var {\Mor} \cd{(\emph{keyword} \emph{var})}})} \\[2pt]
\emph{option} ::= \=\cd{(:argument-precedence-order \Mplus{parameter-name})} \\[2pt]
\Mor~\cd{(declare \Mplus{declaration})} \\
\Mor~\cd{(:documentation \emph{string})} \\
\Mor~\cd{(:method-combination \emph{symbol} \Mstar{{arg}})} \\
\Mor~\cd{(:generic-function-class \emph{class-name})} \\
\Mor~\cd{(:method-class \emph{class-name})} \\[2pt]
\emph{method-description} ::= \cd{(:method }\=\Mstar{{method-qualifier}} \\
\emph{specialized-lambda-list} \\
\Mchoice{{\Mstar{declaration} {\Mor} documentation}} \\
\Mstar{{form}}\cd{)}  \\[2pt]
\emph{method-qualifier} ::= \emph{non-nil-atom} \\[2pt]
\emph{specialized-lambda-list} ::= \\*
\cd{(}\=\Mstar{{var {\Mor} \cd{(}var parameter-specializer-name\/\cd{)}}}  \\
\Mopt{\cd{\&optional} \Mstar{{var {\Mor} \cd{(}var \Mopt{initform {\Mopt{supplied-p-parameter}}}\cd{)}}}}  \\
\Mopt{\cd{\&rest \emph{var}}} \\
\Mopt{\cd{\&key} \Mstar{specialized-keyword-parameter} \Mopt{\cd{\&allow-other-keys}}} \\
\Mopt{\cd{\&aux} \Mstar{{var {\Mor} \cd{(\emph{var} \Mopt{initform})}}}}\cd{)} \\[2pt]
\emph{specialized-keyword-parameter} ::= \\
\emph{var} {\Mor} \cd{(}\Mgroup{var {\Mor} \cd{(\emph{keyword} \emph{var}\cd{)}}}
       \Mopt{initform \Mopt{supplied-p-parameter}}\cd{)} \\[2pt]
\emph{parameter-specializer-name} ::= \emph{symbol} {\Mor} \cd{(eql \emph{eql-specializer-form})}
\end{tabbing}
The macro \cdf{defgeneric} is used to define a generic function or to
specify options and declarations that pertain to a generic function as
a whole.

If \cd{(fboundp \emph{function-name})} is \cdf{nil}, a new
generic function is created.  If \cd{(fdefinition \emph{function-specifier})} is
a generic function, that generic function 
is modified.  If \emph{function-name} names a non-generic
function, a macro, or a special operator, an error is signaled.

[X3J13 voted in March 1989 \issue{FUNCTION-NAME} to use \cdf{fdefinition}
in the previous paragraph, as shown, rather than \cdf{symbol-function},
as it appeared in the original report on CLOS~\cite{SIGPLAN-CLOS,LASC-CLOS-PART-2}.
The vote also changed all occurrences of \emph{function-specifier} in the
original report to \emph{function-name}; this change is reflected here.---GLS]

Each \emph{method-description} defines a method on the generic function.
The lambda-list of each method must be congruent with the lambda-list
specified by the \emph{lambda-list} option.  If this condition
does not hold, an error is signaled.
See section~\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}
for a definition
of congruence in this context.

The macro \cdf{defgeneric} returns the generic function object 
as its result.

The \emph{function-name} argument is a non-\cdf{nil} symbol or a
list of the form \cd{(setf \emph{symbol})}.

The \emph{lambda-list} argument is an ordinary function lambda-list
with the following exceptions:

\begin{itemize}
\item 
The use of \cd{\&aux} is not allowed. 

\item 
Optional and keyword arguments may not have default initial value forms
nor use supplied-p parameters.
The generic function passes to the method all the argument values passed to
it, and only those; default values are not supported.
Note that optional and keyword arguments in method definitions, however,
can have default initial value forms and can use supplied-p parameters. 
\end{itemize}

The following options are provided.  A given option may occur only once,
or an error is signaled.
\begin{itemize}
 
\item  
The \cd{:argument-precedence-order} option is used to specify the
order in which the required arguments in a call to the generic
function are tested for specificity when selecting a particular
method.  Each required argument, as specified in the \emph{lambda-list}
argument, must be included exactly once as a \emph{parameter-name} so that the
full and unambiguous precedence order is 
supplied.  If this condition is not met, an error is signaled.

\item 
The \cdf{declare} option is used to specify declarations that pertain
to the generic function.  The following standard Common Lisp
declaration is allowed:

\begin{itemize}
\item
An \cdf{optimize} declaration specifies whether method selection
should be optimized for speed or space, but it has no effect on
methods.  To control how a method is optimized, an \cdf{optimize}
declaration must be placed directly in the \cdf{defmethod} form or
method description.  The optimization qualities \cdf{speed} and 
\cdf{space} are the only qualities this standard requires, but an
implementation can extend the \CLOS\ to recognize other qualities.  A
simple implementation that has only one method selection technique and
ignores the \cdf{optimize} declaration is valid.
\end{itemize}

The \cdf{special}, \cdf{ftype}, \cdf{function}, \cdf{inline}, 
\cdf{notinline}, and \cdf{declaration} declarations are not permitted.
Individual implementations can extend the \cdf{declare} option to
support additional declarations.  If an implementation notices a
declaration that it does not support and that has not been proclaimed
as a non-standard declaration name in a \cdf{declaration} proclamation, it
should issue a warning.

\item  
The \cd{:documentation} argument associates a documentation string
with the generic function.  The documentation type for this string is
\cdf{function}.  The form \cd{(documentation \emph{function-name} 'function)}
may be used to retrieve this 
string.

\item  
The \cd{:generic-function-class} option may be used to specify that
the generic function is to have a different class than the default
provided by the system (the class \cdf{standard-generic-function}).
The \emph{class-name} argument is the name of a class that can be the
class of a generic function.  If \emph{function-name} specifies
an existing generic function that has a different value for the 
\cd{:generic-function-class} argument and the new generic function class
is compatible with the old, \cdf{change-class} is called to change the
class of the generic function; otherwise an error is signaled.

\item  
The \cd{:method-class} option is used to specify that all methods on
this generic function are to have a different class from the default
provided by the system (the class \cdf{standard-method}).  The \emph{class-name}
argument is the name of a class that is capable of being 
the class of a method.

\item  
The \cd{:method-combination} option is followed by a symbol that
names a type of method combination.  The arguments (if any) that
follow that symbol depend on the type of method combination.  Note
that the standard method combination type does not support any
arguments.  However, all types of method combination defined by the
short form of \cdf{define-method-combination} accept an optional
argument named \emph{order}, defaulting to 
\cd{:most-specific-first}, where a value of \cd{:most-specific-last} reverses
the order of the primary methods without affecting the order of the
auxiliary methods.
\end{itemize}

The \emph{method-description} arguments define methods that will
be associated with the generic function.  The \emph{method-qualifier}
and \emph{specialized-lambda-list} arguments in a method description
are the same as for \cdf{defmethod}.

The \emph{form} arguments specify the method body.  The body of the
method is enclosed in an implicit block.  If \emph{function-name} is a symbol,
this block bears the same name as 
the generic function.  If \emph{function-name} is a list of the
form \cd{(setf \emph{symbol})}, the name of the block is \emph{symbol}.

The generic function object is returned as the result. 

The effect of the \cdf{defgeneric} macro is as if the following three
steps were performed: first, methods defined by previous 
\cdf{defgeneric} forms are removed; second, \cdf{ensure-generic-function}
is called; and finally, methods specified by the current 
\cdf{defgeneric} form are added to the generic function. 

If no method descriptions are specified and a generic function of the same
name does not already exist, a generic function with no methods is created.

The \emph{lambda-list} argument of 
\cdf{defgeneric} specifies the shape of lambda-lists for the methods on
this generic function.  All methods on the resulting generic function must have
lambda-lists that are congruent with this shape.  If a 
\cdf{defgeneric} form is evaluated and some methods for that generic
function have lambda-lists that are not congruent with that given in
the \cdf{defgeneric} form, an error is signaled.  For further details
on method congruence,
see
section~\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}.

Implementations can extend \cdf{defgeneric} to include other options.
It is required that an implementation signal an error if
it observes an option that is not implemented locally.

See section~\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}
as well as \cdf{defmethod}, \cdf{ensure-generic-function}, and
\cdf{generic-function}.
\end{defmac}

\begin{defmac}
define-method-combination name <?short-form-option> \\
define-method-combination name lambda-list
    ({method-group-specifier}*)
    [(\!:arguments! \!.! lambda-list)]
    [(\!:generic-function! generic-fn-symbol)]
    <{declaration}* | doc-string>
    {form}*

\begin{tabbing}
\emph{short-form-option} ::= \=\cd{:documentation \emph{string}} \\
\Mor~\cd{:identity-with-one-argument \emph{boolean}} \\
\Mor~\cd{:operator \emph{operator}}  \\
\emph{method-group-specifier} ::= \cd{(}\=\emph{variable}
    \Mgroup{\Mplus{{qualifier-pattern}} {\Mor} predicate} \\
\>\Mchoice{\Mind{long-form-option}}\cd{)} \\
\emph{long-form-option} ::= \=\cd{:description \emph{format-string}} \\
\Mor~\cd{:order \emph{order}} \\
\Mor~\cd{:required \emph{boolean}}
\end{tabbing}
The macro \cdf{define-method-combination} is used to define new types
of method combination.

There are two forms of \cdf{define-method-combination}.  The short
form is a simple facility for the cases that are expected
to be most commonly needed.  The long form is more powerful but more
verbose.  It resembles \cdf{defmacro} in that the body is an
expression, usually using backquote, that computes a Lisp form.  Thus
arbitrary control structures can be implemented.  The long form also
allows arbitrary processing of method qualifiers.

In both the short and long forms, \emph{name} is a symbol.  By convention,
non-keyword, non-\cdf{nil} symbols are usually used.

\medskip

The short-form syntax of \cdf{define-method-combination} is recognized
when the second subform is a non-\cdf{nil} symbol or is not present.
When the short form is used, \emph{name} is defined as a type of
method combination that produces a Lisp form \cd{(\emph{operator
method-call method-call $\ldots$ })}.  The \emph{operator} is a symbol
that can be the name of a function, macro, or special operator.  The
\emph{operator} can be specified by a keyword option; it defaults to
\emph{name}. 

Keyword options for the short form are the following:

\begin{itemize}

\item 
The \cd{:documentation} option is used to document the method-combination type.

\item 
The \cd{:identity-with-one-argument} option enables an optimization
when \emph{boolean} is true (the default is false).  If there is
exactly one applicable method and it is a primary method, that method
serves as the effective method and \emph{operator} is not called.
This optimization avoids the need to create a new effective method and
avoids the overhead of a function call.  This option is designed to be
used with operators such as \cdf{progn}, \cdf{and}, \cdf{+}, and
\cdf{max}.

\item 
The \cd{:operator} option specifies the name of the operator.  The
\emph{operator} argument is a symbol that can be the name of a
function, macro, or special operator.  By convention, \emph{name} and
\emph{operator} are often the same symbol.  This is the default,
but it is not required.
\end{itemize}

None of the subforms is evaluated.

These types of method combination require exactly one qualifier per
method.  An error is signaled if there are applicable methods with no
qualifiers or with qualifiers that are not supported by the method
combination type. 

A method combination procedure defined in this way recognizes two
roles for methods.  A method whose one qualifier is the symbol naming
this type of method combination is defined to be a primary method.  At
least one primary method must be applicable or an error is signaled.
A method with \cd{:around} as its one qualifier is an auxiliary
method that behaves the same as an \cd{:around} method in standard
method combination.  The function \cdf{call-next-method} can be
used only in \cd{:around} methods; it cannot be used in primary methods
defined by the short form of the \cdf{define-method-combination} macro.

A method combination procedure defined in this way accepts an optional
argument named \emph{order}, which defaults to 
\cd{:most-specific-first}.  A value of \cd{:most-specific-last} reverses
the order of the primary methods without affecting the order of the
auxiliary methods.

The short form automatically includes error checking and support for
\cd{:around} methods.

For a discussion of built-in method combination types,
see section~\ref{Built-in-Method-Combination-Types-SECTION}.

\medskip

The long-form syntax of \cdf{define-method-combination} is recognized 
when the second subform is a list.  

The \emph{lambda-list} argument is an ordinary lambda-list.  It
receives any arguments provided after the name of the method
combination type in the \cd{:method-combination} option to 
\cdf{defgeneric}.

A list of method group specifiers follows.  Each specifier selects a subset
of the applicable methods to play a particular role, either by matching
their qualifiers against some patterns or by testing their qualifiers with
a predicate.   These method group specifiers define all method qualifiers
that can be used with this type of method combination.  If an applicable 
method does not fall into any method group, the system signals the error
that the method is invalid for the kind of method combination in use.

Each method group specifier names a variable.  During the execution of
the forms in the body of \cdf{define-method-combination}, this
variable is bound to a list of the methods in the method group.  The
methods in this list occur in most-specific-first order.

A qualifier pattern is a list or the symbol \cdf{*}.  A method matches
a qualifier pattern if the method's list of qualifiers is \cdf{equal}
to the qualifier pattern (except that the symbol \cdf{*} in a qualifier
pattern matches anything).  Thus a qualifier pattern can be one of the
following: the empty list \cd{()}, which matches unqualified methods;
the symbol \cdf{*}, which matches all methods; a true list, which
matches methods with the same number of qualifiers as the length of
the list when each qualifier matches the corresponding list element;
or a dotted list that ends in the symbol \cdf{*} (the \cdf{*} matches
any number of additional qualifiers).

Each applicable method is tested against the qualifier patterns and
predicates in left-to-right order.  As soon as a qualifier pattern matches
or a predicate returns true, the method becomes a member of the
corresponding method group and no further tests are made.  Thus if a method
could be a member of more than one method group, it joins only the first
such group.  If a method group has more than one qualifier pattern, a
method need only satisfy one of the qualifier patterns to be a member of
the group.

The name of a predicate function can appear instead of qualifier
patterns in a method group specifier.  The predicate is called for
each method that has not been assigned to an earlier method group; it
is called with one argument, the method's qualifier list.  The
predicate should return true if the method is to be a member of the
method group.  A predicate can be distinguished from a qualifier pattern
because it is a symbol other than \cdf{nil} or \cdf{*}.

If there is an applicable method whose qualifiers are not valid
for the method combination type, the function \cdf{invalid-method-error}
is called.

Method group specifiers can have keyword options following the
qualifier patterns or predicate.  Keyword options can be distinguished from
additional qualifier patterns because they are neither lists nor the symbol
\cdf{*}.  The keyword options are:

\begin{itemize}

\item 
The \cd{:description} option is used to provide a description of the
role of methods in the method group.  Programming environment tools
use \cd{(apply \#'format stream \emph{format-string}
(method-qualifiers \emph{method}))} to print this description, which
is expected to be concise.  This keyword
option allows the description of a method qualifier to be defined in
the same module that defines the meaning of the method
qualifier.  In most cases, \emph{format-string} will not contain any
\cdf{format} directives, but they are available for generality.  If 
\cd{:description} is not specified, a default description is generated
based on the variable name and the qualifier patterns and on whether
this method group includes the unqualified methods.  The argument
\emph{format-string} is not evaluated. 

\item 
The \cd{:order} option specifies the order of methods.  The \emph{order}
argument is a form that evaluates to  
\cd{:most-specific-first} or \cd{:most-specific-last}.  If it evaluates
to any other value, an error is signaled.  This keyword option is a
convenience and does not add any expressive power.
If \cd{:order} is not specified, it defaults to \cd{:most-specific-first}.

\item 
The \cd{:required} option specifies whether at least one method in
this method group is required.  If the \emph{boolean} argument is
non-\cdf{nil} and the method group is empty (that is, no applicable
methods match the qualifier patterns or satisfy the predicate), an
error is signaled.  This keyword option is a convenience and does not
add any expressive power.  If \cd{:required} is not specified,
it defaults to \cdf{nil}.  The \emph{boolean} argument is not
evaluated.
\end{itemize}

The use of method group specifiers provides a convenient syntax to
select methods, to divide them among the possible roles, and to perform the
necessary error checking.  It is possible to perform further filtering
of methods in the body forms by using normal list-processing operations
and the functions \cdf{method-qualifiers} and 
\cdf{invalid-method-error}.  It is permissible to use \cdf{setq} on the
variables named in the method group specifiers and to bind additional
variables.  It is also possible to bypass the method group specifier
mechanism and do everything in the body forms.  This is accomplished
by writing a single method group with \cdf{*} as its only qualifier
pattern; the variable is then bound to a list of all of the applicable
methods, in most-specific-first order.

The body \emph{forms} compute and return the Lisp form that specifies
how the methods are combined, that is, the effective method.  The
effective method uses the macro \cdf{call-method}.  The definition of this macro has
lexical scope and is available only in an effective method form.
Given a method object in one of the lists produced by the method group
specifiers and a list of next methods, the macro \cdf{call-method}
will invoke the method so that \cdf{call-next-method} will have available
the next methods.

When an effective method has no effect other than to call a single
method, some implementations employ an optimization that uses the
single method directly as the effective method, thus avoiding the need
to create a new effective method.  This optimization is active when
the effective method form consists entirely of an invocation of
the \cdf{call-method} macro whose first subform is a method object and
whose second subform is \cdf{nil}.  Each 
\cdf{define-method-combination} body is responsible for stripping off
redundant invocations of \cdf{progn}, \cdf{and}, 
\cdf{multiple-value-prog1}, and the like, if this optimization is desired.

The list \cd{(:arguments . \emph{lambda-list})} can appear before
any declaration or documentation string.  This form is useful when
the method combination type performs some specific behavior as part of
the combined method and that behavior needs access to the arguments to
the generic function.  Each parameter variable defined by \emph{lambda-list}
is bound to a form that can be inserted into the effective method.  When this
form is evaluated during execution of the 
effective method, its value is the corresponding argument to the
generic function.  If \emph{lambda-list} is not congruent to the
generic function's lambda-list, additional ignored parameters are
automatically inserted until it is congruent.  Thus it is permissible
for \emph{lambda-list} to receive fewer arguments than the number
that the generic function expects.

Erroneous conditions detected by the body should be reported with
\cdf{method-combination-error} or
\cdf{invalid-method-error}; these functions
add any necessary contextual information to the error message and will
signal the appropriate error.

The body \emph{forms} are evaluated inside the bindings created by the
lambda-list and method group specifiers.  Declarations at the head of
the body are positioned directly inside bindings created by the
lambda-list and outside the bindings of the method group variables. 
Thus method group variables cannot be declared.

Within the body \emph{forms}, \emph{generic-function-symbol}
is bound to the generic function object.

If a \emph{doc-string} argument is present, it provides the
documentation for the method combination type.

The functions \cdf{method-combination-error} and 
\cdf{invalid-method-error} can be called from the body \emph{forms} or
from functions called by the body \emph{forms}.  The actions of these
two functions can depend on implementation-dependent dynamic variables
automatically bound before the generic function 
\cdf{compute-effective-method} is called.

Note that two methods with identical specializers, but with different
qualifiers, are not ordered by the algorithm described in step~2 of
the method selection and combination process described in
section~\ref{Method-Selection-and-Combination-SECTION}.
Normally the two methods play
different roles in the effective method because they have different
qualifiers, and no matter how they are ordered in the result of step~2
the effective method is the same.  If the two methods play the same
role and their order matters, an error is signaled.  This happens as
part of the qualifier pattern matching in 
\cdf{define-method-combination}.

The value returned by the \cdf{define-method-combination} macro is the new
method combination object.

Most examples of the long form of \cdf{define-method-combination} also
illustrate the use of the related functions that are provided as part
of the declarative method combination facility.

\begin{lisp}
;;; Examples of the short form of define-method-combination \\
\\
(define-method-combination and :identity-with-one-argument t) \\
\\
(defmethod func and ((x class1) y) \\
~~...) \\
\\
;;; The equivalent of this example in the long form is: \\*
\\*
(define-method-combination and \\*
~~~~~~~~(\&optional (order ':most-specific-first)) \\*
~~~~~~~~((around (:around)) \\*
~~~~~~~~~(primary (and) :order order :required t)) \\
~~(let ((form (if (rest primary) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(and ,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~primary)) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,(first primary) ())))) \\
~~~~(if around \\*
~~~~~~~~{\Xbq}(call-method ,(first around) \\*
~~~~~~~~~~~~~~~~~~~~~~(,{\Xatsign}(rest around) \\*
~~~~~~~~~~~~~~~~~~~~~~~(make-method form))) \\*
~~~~~~~~form))) \\
\\
\\
;;; Examples of the long form of define-method-combination \\*
\\*
;;; The default method-combination technique \\*
\\*
(define-method-combination standard () \\*
~~~~~~~~((around (:around)) \\*
~~~~~~~~~(before (:before)) \\*
~~~~~~~~~(primary () :required t) \\*
~~~~~~~~~(after (:after))) \\
~~(flet ((call-methods (methods) \\*
~~~~~~~~~~~(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~methods))) \\
~~~~(let ((form (if (or before after (rest primary)) \\*
~~~~~~~~~~~~~~~~~~~~{\Xbq}(multiple-value-prog1 \\*
~~~~~~~~~~~~~~~~~~~~~~~(progn ,{\Xatsign}(call-methods before) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(call-method ,(first primary) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~,(rest primary))) \\*
~~~~~~~~~~~~~~~~~~~~~~~,{\Xatsign}(call-methods (reverse after))) \\*
~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,(first primary) ())))) \\
~~~~~~(if around \\*
~~~~~~~~~~{\Xbq}(call-method ,(first around) \\*
~~~~~~~~~~~~~~~~~~~~~~~~(,{\Xatsign}(rest around) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~(make-method form))) \\*
~~~~~~~~~~form))))
\end{lisp}
\vskip 0pt plus 10pt
\hrule width 0pt\relax
\begin{lisp}
;;; A simple way to try several methods until one returns non-nil \\*
\\*
(define-method-combination or () \\*
~~~~~~~~((methods (or))) \\*
~~{\Xbq}(or ,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~methods))) \\
\\
;;; A more complete version of the preceding \\*
\\*
(define-method-combination or  \\*
~~~~~~~~(\&optional (order ':most-specific-first)) \\*
~~~~~~~~((around (:around)) \\*
~~~~~~~~~(primary (or))) \\
~~;; Process the order argument \\*
~~(case order \\*
~~~~(:most-specific-first) \\*
~~~~(:most-specific-last (setq primary (reverse primary))) \\*
~~~~(otherwise (method-combination-error \\*
~~~~~~~~~~~~~~~~~"{\Xtilde}S is an invalid order.{\Xtilde}{\Xatsign} \\*
~~~~~~~~~~~~~~~~~~:most-specific-first and :most-specific-last {\Xtilde} \\*
~~~~~~~~~~~~~~~~~~~~are the possible values." \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~order))) \\
~~;; Must have a primary method \\*
~~(unless primary \\*
~~~~(method-combination-error "A primary method is required.")) \\
~~;; Construct the form that calls the primary methods \\*
~~(let ((form (if (rest primary) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(or ,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~primary)) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,(first primary) ())))) \\
~~~~;; Wrap the around methods around that form \\*
~~~~(if around \\*
~~~~~~~~{\Xbq}(call-method ,(first around) \\*
~~~~~~~~~~~~~~~~~~~~~~(,{\Xatsign}(rest around) \\*
~~~~~~~~~~~~~~~~~~~~~~~(make-method form))) \\*
~~~~~~~~form)))
\end{lisp}
\vskip 0pt plus 10pt
\hrule width 0pt\relax
\begin{lisp}
;;; The same thing, using the :order and :required keyword options \\*
(define-method-combination or  \\*
~~~~~~~~(\&optional (order ':most-specific-first)) \\*
~~~~~~~~((around (:around)) \\*
~~~~~~~~~(primary (or) :order order :required t)) \\
~~(let ((form (if (rest primary) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(or ,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~primary)) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,(first primary) ())))) \\
~~~~(if around \\*
~~~~~~~~{\Xbq}(call-method ,(first around) \\*
~~~~~~~~~~~~~~~~~~~~~~(,{\Xatsign}(rest around) \\*
~~~~~~~~~~~~~~~~~~~~~~~(make-method form))) \\*
~~~~~~~~form))) \\
\\
;;; This short-form call is behaviorally identical to the preceding. \\*
(define-method-combination or :identity-with-one-argument t) \\
 \\
;;; Order methods by positive integer qualifiers; note that :around \\*
;;; methods are disallowed here in order to keep the example small. \\*
\\*
(define-method-combination example-method-combination () \\*
~~~~~~~~((methods positive-integer-qualifier-p)) \\
~~{\Xbq}(progn ,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~~(stable-sort methods \#'< \\*
~~~~~~~~~~~~~~~~~~~~~~:key \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(first (method-qualifiers \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~method))))))) \\
\\
(defun positive-integer-qualifier-p (method-qualifiers) \\*
~~(and (= (length method-qualifiers) 1) \\*
~~~~~~~(typep (first method-qualifiers) '(integer 0 *)))) \\
\\
;;; Example of the use of :arguments \\*
(define-method-combination progn-with-lock () \\*
~~~~~~~~((methods ())) \\*
~~~~~~~~(:arguments object) \\
~~{\Xbq}(unwind-protect \\*
~~~~~~~(progn (lock (object-lock ,object)) \\*
~~~~~~~~~~~~~~,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~~~~~~methods)) \\*
~~~~~(unlock (object-lock ,object))))
\end{lisp}


The \cd{:method-combination} option of \cdf{defgeneric} is used to
specify that a generic function should use a particular method
combination type.  The argument to the \cd{:method-combination}
option is the name of a method combination type.
 
See sections~\ref{Method-Selection-and-Combination-SECTION} and
\ref{Built-in-Method-Combination-Types-SECTION} as well as
\cdf{call-method},
\cdf{method-qualifiers},
\cdf{method-combination-error},
\cdf{invalid-method-error},
and \cdf{defgeneric}.
\end{defmac}

\begin{defmac}
defmethod function-name {method-qualifier}*
          specialized-lambda-list
          <{declaration}* | doc-string> {form}*

\begin{tabbing}
\emph{function-name} ::= \Mgroup{\emph{symbol} {\Mor} \cd{(setf \emph{symbol})}} \\*
\emph{method-qualifier} ::= \emph{non-nil-atom} \\*
\emph{parameter-specializer-name} ::= \emph{symbol} {\Mor} \cd{(eql \emph{eql-specializer-form})}
\end{tabbing}
The macro \cdf{defmethod} defines a method on a generic function.

If \cd{(fboundp \emph{function-name})} is \cdf{nil}, a generic
function is created with default values for the argument precedence
order (each argument is more specific than the arguments to its right
in the argument list), for the generic function class (the class 
\cdf{standard-generic-function}), for the method class (the class 
\cdf{standard-method}), and for the method combination type (the standard
method combination type).  The lambda-list of the generic function is
congruent with the lambda-list of the method being defined; if the
\cdf{defmethod} form mentions keyword arguments, the lambda-list of
the generic function will mention \cd{\&key} (but no keyword
arguments).  If \emph{function-name} names a non-generic
function, a macro, or a special operator, an error is signaled.

If a generic function is currently named by \emph{function-name}, where
\emph{function-name} is a symbol or a list of the form \cd{(setf
  \emph{symbol})}, the lambda-list of the 
method must be congruent with the lambda-list of the generic function.
If this condition does not hold, an error is signaled.  See
section~\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}
for a definition of congruence in this context.

The \emph{function-name} argument is a non-\cdf{nil} symbol or a
list of the form \cd{(setf \emph{symbol})}.  It names the generic
function on which the method is defined.

Each \emph{method-qualifier} argument is an object that is used by
method combination to identify the given method.  A method qualifier
is a non-\cdf{nil} atom. The method combination type may further
restrict what a method qualifier may be.  The standard method
combination type allows for unqualified methods or methods whose sole
qualifier is the keyword \cd{:before}, the keyword 
\cd{:after}, or the keyword \cd{:around}.

A \emph{specialized-lambda-list} is like an ordinary
function lambda-list except that the name of a required parameter can
be replaced by a specialized parameter, a
list of the form \cd{(\emph{variable-name
parameter-specializer-name})}.  Only required parameters may be
specialized.  A parameter specializer name is a symbol that names a
class or \cd{(eql \emph{eql-specializer-form})}.  The parameter
specializer name \cd{(eql \emph{eql-specializer-form})} indicates
that the corresponding argument must be \cdf{eql} to the object that
is the value of \emph{eql-specializer-form} for the method to be
applicable.  If no parameter specializer name is specified for a given
required parameter, the parameter specializer defaults to the class
named \cdf{t}.  See section~\ref{Introduction-to-Methods-SECTION}.

The \emph{form} arguments specify the method body.
The body of the method is enclosed in an implicit block.  If
\emph{function-name} is a symbol, this block bears the same name as the
generic function.  If \emph{function-name} is a list of the form 
\cd{(setf \emph{symbol})}, the name of the block is \emph{symbol}.

The result of \cdf{defmethod} is the method object.

The class of the method object that is created is that given by the 
method class option of the generic function on which the method is defined.

If the generic function already has a method that agrees with the
method being defined on parameter specializers and qualifiers, 
\cdf{defmethod} replaces the existing method with the one now being
defined.  See
section~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}
for a definition of agreement in this context.

The parameter specializers are derived from the parameter specializer
names as described in section~\ref{Introduction-to-Methods-SECTION}.

The expansion of the \cdf{defmethod} macro refers to each
specialized parameter (see the \cdf{ignore} declaration specifier), including
parameters that
have an explicit parameter specializer name of \cdf{t}.  This means
that a compiler warning does not occur if the body of the method does
not refer to a specialized parameter.  Note that a parameter that
specializes on \cdf{t} is not synonymous with an unspecialized
parameter in this context.

See sections~\ref{Introduction-to-Methods-SECTION},
\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION},
and \ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}.
\end{defmac}


[At this point the original CLOS report \cite{SIGPLAN-CLOS,LASC-CLOS-PART-2}
contained a specification for \cdf{describe} as a generic function.
This specification is omitted here because X3J13 voted in March 1989 \issue{DESCRIBE-UNDERSPECIFIED}
not to make \cdf{describe} a generic function after all (see \cdf{describe-object}).---GLS]


\begin{defun}[Generic function][Primary method]
documentation x &optional doc-type \\
documentation (method standard-method)  &optional doc-type \\
documentation (generic-function standard-generic-function) &optional doc-type \\
documentation (class standard-class)  &optional doc-type \\
documentation (method-combination method-combination) &optional doc-type \\
documentation (slot-description standard-slot-description) &optional doc-type \\
documentation (symbol symbol) &optional doc-type \\
documentation (list list) &optional doc-type

The ordinary function \cdf{documentation} (see section~\ref{DOCUMENTATION-SECTION})
is replaced by a generic
function.  The generic function \cdf{documentation} returns the
documentation string associated with the given object if it is
available; otherwise \cdf{documentation} returns \cdf{nil}.

The first argument of \cdf{documentation} is a symbol, a
function-name list of the form \cd{(setf \emph{symbol})}, a
method object, a class object, a generic function object, a method
combination object, or a slot description object.
Whether a second argument should be supplied depends on the
type of the first argument.

\begin{itemize}
\item 
If the first argument is a method object, a class object, a generic
function object, a method combination object, or a slot description
object, the second argument must not be supplied, or an error is
signaled.

\item  
If the first argument is a symbol or a list of the form
\cd{(setf \emph{symbol})}, the second argument must be
supplied.

\begin{itemize}
\item
The forms
\begin{lisp}
(documentation \emph{symbol} 'function)
\end{lisp}
and
\begin{lisp}
(documentation '(setf \emph{symbol}) 'function)
\end{lisp}
return the
documentation string of the function, generic function, special operator, or
macro named by the symbol or list.

\item
The form \cd{(documentation \emph{symbol} 'variable)} returns the
documentation string of the special variable or constant named by the
symbol.

\item
The form \cd{(documentation \emph{symbol} 'structure)} returns the
documentation string of the \cdf{defstruct} structure named by the
symbol.

\item
The form \cd{(documentation \emph{symbol} 'type)} returns the documentation
string of the class object named by the symbol, if there is such a
class.   If there is no such class, it returns the documentation string
of the type specifier named by the symbol. 

\item
The form \cd{(documentation \emph{symbol} 'setf)} returns the documentation
string of the \cdf{defsetf} or \cdf{define-setf-method} definition
associated with the symbol.

\item
The form \cd{(documentation \emph{symbol} 'method-combination)} returns the
documentation string of the method combination type named by the
symbol.
\end{itemize}

\end{itemize}

An implementation may extend the set of symbols that are acceptable as
the second argument.  If a symbol is not recognized as an acceptable
argument by the implementation, an error must be signaled.

The documentation string associated with the given object is returned
unless none is available, in which case \cdf{documentation} returns
\cdf{nil}.
\end{defun}


\begin{defun}[Generic function][Primary method]
(setf documentation) new-value x &optional doc-type \\
(setf documentation) new-value (method standard-method) &optional doc-type \\
(setf documentation) new-value (generic-function standard-generic-function) &optional doc-type \\
(setf documentation) new-value (class standard-class) &optional doc-type \\
(setf documentation) new-value (method-combination method-combination) &optional doc-type \\
(setf documentation) new-value (slot-description standard-slot-description) &optional doc-type \\
(setf documentation) new-value (symbol symbol) &optional doc-type \\
(setf documentation) new-value (list list) &optional doc-type

The generic function \cd{(setf documentation)} is used to update the
documentation.

The first argument of \cd{(setf documentation)} is the new documentation.

The second argument of \cdf{documentation} is a symbol, a
function-name list of the form \cd{(setf \emph{symbol})}, a
method object, a class object, a generic function object, a method
combination object, or a slot description object.
Whether a third argument should be supplied depends on the
type of the second argument.
See \cdf{documentation}.
\end{defun}


\begin{defun}[Function]
ensure-generic-function function-name &key :lambda-list
:argument-precedence-order
:declare
:documentation
:generic-function-class
:method-combination
:method-class
:environment

\begin{tabbing}
\emph{function-name} ::= \Mgroup{\emph{symbol} {\Mor} \cd{(setf \emph{symbol})}}
\end{tabbing}
The function \cdf{ensure-generic-function} is used to define a
globally named generic function with no methods or to specify or
modify options and declarations that pertain to a globally named
generic function as a whole.

If \cd{(fboundp \emph{function-name})} is \cdf{nil}, a new
generic function is created.  If \cd{(fdefinition \emph{function-name})} is a
non-generic function, a macro, or a 
special operator, an error is signaled.

[X3J13 voted in March 1989 \issue{FUNCTION-NAME} to use \cdf{fdefinition}
in the previous paragraph, as shown, rather than \cdf{symbol-function},
as it appeared in the original report on CLOS~\cite{SIGPLAN-CLOS,LASC-CLOS-PART-2}.
The vote also changed all occurrences of \emph{function-specifier} in the
original report to \emph{function-name}; this change is reflected here.---GLS]

If \emph{function-name} specifies a generic function that has a
different value for any of the following arguments, the generic
function is modified to have the new value: 
\cd{:argument-precedence-order}, \cd{:declare}, \cd{:documentation},
\cd{:method-combination}.

If \emph{function-name} specifies a generic function that has a
different value for the \cd{:lambda-list} argument, and the new value
is congruent with the lambda-lists of all existing methods or there
are no methods, the value is changed; otherwise an error is signaled.

If \emph{function-name} specifies a generic function that has a
different value for the \cd{:generic-function-class} argument and if
the new generic function class is compatible with the old, 
\cdf{change-class} is called to change the class of the generic function;
otherwise an error is signaled.

If \emph{function-name} specifies a generic function that has a
different \cd{:method-class} value, the value is
changed but any existing methods are not changed.

The \emph{function-name} argument is a symbol or a list of the
form \cd{(setf \emph{symbol})}.

The keyword arguments correspond to the \emph{option} arguments of
\cdf{defgeneric}, except that the \cd{:method-class} and
\cd{:generic-function-class} arguments can be class objects
as well as names.

The \cd{:environment} argument is the same as the 
\cd{\&environment} argument to macro expansion functions.  It is typically
used to distinguish between compile-time and run-time environments.

The \cd{:method-combination} argument is a method combination object.

The generic function object is returned.

See \cdf{defgeneric}.
\end{defun}

\begin{defun}[Function]
find-class symbol &optional errorp environment

The function \cdf{find-class} returns the class object named by the
given symbol in the given environment.

The first argument to \cdf{find-class} is a symbol. 

If there is no such class and the \emph{errorp} argument is
not supplied or is non-\cdf{nil}, \cdf{find-class} signals an error.
If there is no such class and the \emph{errorp} argument is
\cdf{nil}, \cdf{find-class} returns \cdf{nil}.  The default value of
\emph{errorp} is \cdf{t}.

The optional \emph{environment} argument is the same as the 
\cd{\&environment} argument to macro expansion functions.  It is typically
used to distinguish between compile-time and run-time environments.

The result of \cdf{find-class} is the class object named by the given symbol.

The class associated with a particular symbol can be changed by using
\cdf{setf} with \cdf{find-class}.  The results are undefined if
the user attempts to change the class associated with a symbol that is
defined as a type specifier in chapter~\ref{DTSPEC}.
See section~\ref{Integrating-Types-and-Classes-SECTION}.
\end{defun}


\begin{defun}[Generic function][Primary method]
find-method generic-function method-qualifiers specializers &optional errorp \\
find-method (generic-function standard-generic-function)
   method-qualifiers specializers &optional errorp

The generic function \cdf{find-method} takes a generic function and
returns the method object that agrees on method qualifiers and
parameter specializers with the \emph{method-qualifiers} and \emph{specializers}
arguments of \cdf{find-method}. 
See section~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION} for a
definition of agreement in this context.

The \emph{generic-function} argument is a generic function.

The \emph{method-qualifiers} argument is a list of the
method qualifiers for the method.   The order of the method qualifiers
is significant.  

The \emph{specializers} argument is a list of the parameter
specializers for the method.  It must correspond in length to
the number of required arguments of the generic function, or
an error is signaled.  This means that to obtain the
default method on a given generic function, a list whose
elements are the class named \cdf{t} must be given.

If there is no such method and the \emph{errorp} argument is
not supplied or is non-\cdf{nil}, \cdf{find-method} signals an error.
If there is no such method and the \emph{errorp} argument is
\cdf{nil}, \cdf{find-method} returns \cdf{nil}.  The default value of
\emph{errorp} is \cdf{t}.

The result of \cdf{find-method} is the method object with the given
method qualifiers and parameter specializers.

See section~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}.
\end{defun}


\begin{defun}[Generic function][Primary method]
function-keywords method \\
function-keywords (method standard-method)

The generic function \cdf{function-keywords} is used to return the keyword
parameter specifiers for a given method.

The \emph{method} argument is a method object.

The generic function \cdf{function-keywords} returns two values:
a list of the explicitly named keywords and a boolean that states whether
\cd{\&allow-other-keys} had been specified in the method definition.
\end{defun}

% \begin{defspec}
% generic-flet ({(function-name lambda-list
%                 <?option | {method-description}*>)}*)
%             {form}*

% The \cdf{generic-flet} special operator is analogous to the
% \cdf{flet} special operator.  It produces new generic functions and
% establishes new lexical function definition bindings.  Each generic
% function is created with the set of methods specified by its method
% descriptions.


% The special operator \cdf{generic-flet} is used to define generic functions whose
% names are meaningful only locally and to execute a series of forms
% with these function definition bindings.  Any number of such local
% generic functions may be defined.


% The names of functions defined by \cdf{generic-flet} have lexical
% scope; they retain their local definitions only within the body of the
% \cdf{generic-flet}.  Any references within the body of the 
% \cdf{generic-flet} to functions whose names are the same as those defined
% within the \cdf{generic-flet} are thus references to the local
% functions instead of to any global functions of the same names.  The
% scope of these generic function definition bindings, however, includes only
% the body of \cdf{generic-flet}, not the definitions themselves.
% Within the method bodies, local function names that match those
% being defined refer to global functions defined outside the 
% \cdf{generic-flet}.  It is thus not possible to define recursive functions
% with \cdf{generic-flet}.


% The \emph{function-name}, \emph{lambda-list}, \emph{option}, \emph{
% method-qualifier}, and \emph{specialized-lambda-list} arguments are
% the same as for \cdf{defgeneric}.


% A \cdf{generic-flet} local method definition is identical in form to the
% method definition part of a \cdf{defmethod}.


% The body of each method is enclosed in an implicit block.  If \emph{
% function-name} is a symbol, this block bears the same name as
% the generic function.  If \emph{function-name} is a list of the
% form \cd{(setf \emph{symbol})}, the name of the block is \emph{
% symbol}.


% The result returned by \cdf{generic-flet} is the value or values
% returned by the last form executed.  If no forms are specified, 
% \cdf{generic-flet} returns \cdf{nil}.

% See \cdf{generic-labels}, \cdf{defmethod}, \cdf{defgeneric}, and \cdf{generic-function}.
% \end{defspec}


\begin{defmac}
generic-function lambda-list <?option | {method-description}*>

\begin{tabbing}
\emph{option} ::= \cd{(:argument-precedence-order \Mplus{parameter-name})} \\
~~~ \Mor~\cd{(declare \Mplus{declaration})} \\
~~~ \Mor~\cd{(:documentation
  \emph{string})} \\
~~~ \Mor~\cd{(:method-combination \emph{symbol} \Mstar{{arg}})} \\
~~~ \Mor~\cd{(:generic-function-class \emph{class-name})} \\
~~~ \Mor~\cd{(:method-class \emph{class-name})} \\\\
 \emph{method-description} ::= \cd{(:method } \Mstar{{method-qualifier}}  \emph{specialized-lambda-list} 
\Mstar{{declaration\/ {\Mor} documentation}} 
\Mstar{{form}}\cd{)}
\end{tabbing}
The \cdf{generic-function} macro creates an anonymous generic
function. The generic function is created with the set of methods
specified by its method descriptions.

The \emph{option}, \emph{method-qualifier}, and \emph{specialized-lambda-list}
arguments are the same as for \cdf{defgeneric}.

The generic function object is returned as the result.

If no method descriptions are specified, an anonymous generic function with no
methods is created.

See \cdf{defgeneric}, 
%\cdf{generic-flet}, \cdf{generic-labels},
 and \cdf{defmethod}.
\end{defmac}


% \begin{defspec}
% generic-labels ({(function-name lambda-list
%                 <?option | {method-description}*>)}*)
%                {form}*


% The \cdf{generic-labels} special operator is analogous to the
% \cdf{labels} special operator.  It produces new generic functions and
% establishes new lexical function definition bindings.  Each generic
% function is created with the set of methods specified by its method
% descriptions.



% The special operator \cdf{generic-labels} is used to define generic functions
% whose names are meaningful only locally and to execute a series of
% forms with these function definition bindings.  Any number of
% such  local generic functions may be defined.  



% The names of functions defined by \cdf{generic-labels} have lexical
% scope; they retain their local definitions only within the body of the
% \cdf{generic-labels} construct.  Any references within the body of the
% \cdf{generic-labels} construct to functions whose names are the same
% as those defined within the \cdf{generic-labels} form are thus
% references to the local functions instead of to any global functions
% of the same names.  The scope of these generic function definition bindings
% includes the method bodies themselves as well as the body of the 
% \cdf{generic-labels} construct.




% The \emph{function-name}, \emph{lambda-list}, \emph{option},
% \emph{method-qualifier}, and \emph{specialized-lambda-list} arguments are 
% the same as for \cdf{defgeneric}.

% A \cdf{generic-labels} local method definition is identical in form to the
% method definition part of a \cdf{defmethod}.

% The body of each method is enclosed in an implicit block.  If
% \emph{function-name} is a symbol, this block bears the same name as 
% the generic function.  If \emph{function-name} is a list of the
% form \cd{(setf \emph{symbol})}, the name of the block is \emph{symbol}.


% The result returned by \cdf{generic-labels} is the value or values
% returned by the last form executed.  If no forms are specified, 
% \cdf{generic-labels} returns \cdf{nil}.

% See \cdf{generic-flet}, \cdf{defmethod}, \cdf{defgeneric}, \cdf{generic-function}.
% \end{defspec}


\begin{defun}[Generic function][Primary method]
initialize-instance instance &rest initargs \\
initialize-instance (instance standard-object) &rest initargs

The generic function \cdf{initialize-instance} is called by 
\cdf{make-instance} to initialize a newly created instance.  The generic
function \cdf{initialize-instance} is called with the new instance and
the defaulted initialization arguments.

The system-supplied primary method on \cdf{initialize-instance}
initializes the slots of the instance with values according to the
initialization arguments and the \cd{:initform} forms of the slots.
It does this by calling the generic function \cdf{shared-initialize}
with the following arguments: the instance, \cdf{t} (this indicates
that all slots for which no initialization arguments are provided
should be initialized according to their \cd{:initform} forms) and
the defaulted initialization arguments.

The \emph{instance} argument is the object to be initialized.

The \emph{initargs} argument consists of alternating initialization
argument names and values.

The modified instance is returned as the result.

Programmers can define methods for \cdf{initialize-instance} to
specify actions to be taken when an instance is initialized.  If only
\cd{:after} methods are defined, they will be run after the
system-supplied primary method for initialization and therefore will
not interfere with the default behavior of \cdf{initialize-instance}.

See sections~\ref{Object-Creation-and-Initialization-SECTION},
\ref{Rules-for-Initialization-Arguments-SECTION}, and
\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION} as well as
\cdf{shared-initialize},
\cdf{make-instance},
\cdf{slot-boundp},
and \cdf{slot-makunbound}.
\end{defun}

\begin{defun}[Function]
invalid-method-error method format-string &rest args

The function \cdf{invalid-method-error} is used to signal an error
when there is an applicable method whose qualifiers are not valid for
the method combination type.  The error message is constructed by
using a \cdf{format} string and any arguments to it.  Because an
implementation may need to add additional contextual information to
the error message, \cdf{invalid-method-error} should be called only
within the dynamic extent of a method combination function.

The function \cdf{invalid-method-error} is called automatically when a
method fails to satisfy every qualifier pattern and predicate in a
\cdf{define-method-combination} form.
A method combination function
that imposes additional restrictions should call 
\cdf{invalid-method-error} explicitly if it encounters a method it cannot
accept.

The \emph{method} argument is the invalid method object.  

The \emph{format-string} argument is a control string that can be
given to \cdf{format}, and \emph{args} are any arguments required by
that string.

Whether \cdf{invalid-method-error} returns to its caller or exits via
\cdf{throw} is implementation-dependent.

See \cdf{define-method-combination}.
\end{defun}

\begin{defun}[Generic function][Primary method]
make-instance class &rest initargs \\
make-instance (class standard-class) &rest initargs \\
make-instance (class symbol) &rest initargs

The generic function \cdf{make-instance} creates a new
instance of the given class.

The generic function \cdf{make-instance} may be used as described in
section~\ref{Object-Creation-and-Initialization-SECTION}.

The \emph{class} argument is a class object or a symbol that
names a class.  The remaining arguments form a list of alternating
initialization argument names and values.

If the second of the preceding methods is selected, that method invokes
\cdf{make-instance} on the arguments \cd{(find-class \emph{class})} and
\emph{initargs}.

The initialization arguments are checked within \cdf{make-instance}
(see section~\ref{Object-Creation-and-Initialization-SECTION}).

The new instance is returned.

The meta-object protocol can be used to define new methods on 
\cdf{make-instance} to replace the object-creation protocol.

See section~\ref{Object-Creation-and-Initialization-SECTION} as well as
\cdf{defclass}, \cdf{initialize-instance}, and \cdf{class-of}.
\end{defun}

\begin{defun}[Generic function][Primary method]
make-instances-obsolete class \\
make-instances-obsolete (class standard-class) \\
make-instances-obsolete (class symbol)

The generic function \cdf{make-instances-obsolete} is invoked
automatically by the system when \cdf{defclass} has been used to
redefine an existing standard class and the set of local slots accessible in an
instance is changed or the order of slots in storage is changed.  It
can also be explicitly invoked by the user.

The function \cdf{make-instances-obsolete} has the effect of
initiating the process of updating the instances of the
class. During updating, the generic function 
\cdf{update-instance-for-redefined-class} will be invoked.

The \emph{class} argument is a class object or symbol that names
the class whose instances are to be made obsolete.

If the second of the preceding methods is selected, that method invokes
\cdf{make-instances-obsolete} on \cd{(find-class \emph{class})}.

The modified class is returned.  The result of \cdf{make-instances-obsolete}
is \cdf{eq} to the \emph{class} argument supplied to the first of the preceding
methods.

See section~\ref{Redefining-Classes-SECTION} as well as
\cdf{update-instance-for-redefined-class}.
\end{defun}

\begin{defun}[Function]
method-combination-error format-string &rest args

The function \cdf{method-combination-error} is used to signal an error
in method combination.  The error message is constructed by using a
\cdf{format} string and any arguments to it.  Because an implementation may
need to add additional contextual information to the error message,
\cdf{method-combination-error} should be called only within the
dynamic extent of a method combination function.

The \emph{format-string} argument is a control string that can be
given to \cdf{format}, and \emph{args} are any arguments required by
that string.

Whether \cdf{method-combination-error} returns to its caller or exits
via \cdf{throw} is implementation-dependent.

See \cdf{define-method-combination}.
\end{defun}

\begin{defun}[Generic function][Primary method]
method-qualifiers method \\
method-qualifiers (method standard-method)

The generic function \cdf{method-qualifiers} returns a list of the
qualifiers of the given method.

The \emph{method} argument is a method object. 

A list of the qualifiers of the given method is returned.

Example:
\begin{lisp}
(setq methods (remove-duplicates methods \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:from-end t \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:key \#'method-qualifiers \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:test \#'equal))
\end{lisp}

See \cdf{define-method-combination}.
\end{defun}

\begin{defun}[Function]
next-method-p

The locally defined function \cdf{next-method-p} can be used within
the body of a method defined by a method-defining form to determine
whether a next method exists.

The function \cdf{next-method-p} takes no arguments.

The function \cdf{next-method-p} returns true or false.

Like \cdf{call-next-method}, the function \cdf{next-method-p} has 
lexical scope (for it
is defined only within the body of a method defined by a method-defining form)
and indefinite extent.

See \cdf{call-next-method}.
\end{defun}

\begin{defun}[Generic function][Primary method]
no-applicable-method generic-function &rest function-arguments \\
no-applicable-method (generic-function t) &rest function-arguments

The generic function \cdf{no-applicable-method} is called when a
generic function of the class \cdf{standard-generic-function} is invoked
and no method on that generic function is applicable.
The default method signals an error.

The generic function \cdf{no-applicable-method} is not intended to be called
by programmers.  Programmers may write methods for it.

The \emph{generic-function} argument of \cdf{no-applicable-method} is the
generic function object on which no applicable method was found.  

The \emph{function-arguments} argument is a list of the arguments to that
generic function.
\end{defun}

\begin{defun}[Generic function][Primary method]
no-next-method generic-function method &rest args \\
no-next-method (generic-function standard-generic-function)
    (method standard-method) &rest args

The generic function \cdf{no-next-method} is called by 
\cdf{call-next-method} when there is no next method.  The system-supplied
method on \cdf{no-next-method} signals an error.

The generic function \cdf{no-next-method} is not intended to be called
by programmers.  Programmers may write methods for it.

The \emph{generic-function} argument is the generic function object
to which the method that is the second argument belongs.

The \emph{method} argument is the method that contains the call to
\cdf{call-next-method} for which there is no next method.

The \emph{args} argument is a list of the arguments to
\cdf{call-next-method}.

See \cdf{call-next-method}.
\end{defun}


\begin{defun}[Generic function][Primary method]
print-object object stream \\
print-object (object standard-object) stream

The generic function \cdf{print-object} writes the printed
representation of an object to a stream.  The function 
\cdf{print-object} is called by the print system; it should not be called
by the user.

Each implementation must provide a method on the class 
\cdf{standard-object} and methods on enough other classes so as to ensure
that there is always an applicable method.  Implementations are free
to add methods for other classes.  Users can write methods for 
\cdf{print-object} for their own classes if they do not wish to inherit an
implementation-supplied method.

The first argument is any Lisp object.   The second argument is a
stream; it cannot be \cdf{t} or \cdf{nil}. 

The function \cdf{print-object} returns its first argument, the object.  

Methods on \cdf{print-object} must obey the print control special
variables named \cd{*print-\emph{xxx}*} for various \emph{xxx}.  The
specific details are the following:

\begin{itemize}

\item 
Each method must implement \cdf{*print-escape*}. 

\item  
The \cdf{*print-pretty*} control variable can be ignored
by most methods other than the one for lists.

\item 
The \cdf{*print-circle*} control variable is handled by the printer
and can be ignored by methods.

\item 
The printer takes care of \cdf{*print-level*} automatically, provided that
each method handles exactly one level of structure and
calls \cdf{write} (or an equivalent function) recursively if
there are more structural levels.  The printer's decision
of whether an object has components (and therefore should
not be printed when the printing depth is not less than
\cdf{*print-level*}) is implementation-dependent.  In some
implementations its \cdf{print-object} method is not called; in
others the method is called, and the determination that the
object has components is based on what it tries to write
to the stream.

\item 
Methods that produce output of indefinite length must obey
\cdf{*print-length*}, but most methods other than the one for lists can
ignore it.

\item 
The \cdf{*print-base*}, \cdf{*print-radix*}, \cdf{*print-case*}, 
\cdf{*print-gensym*}, and \cdf{*print-array*} control variables apply
to specific types of objects and are handled by the methods for those
objects.

\item X3J13 voted in June 1989 \issue{DATA-IO} to add the following point.
   All methods for \cdf{print-object} must obey \cd{*print-readably*},
   which takes precedence over all other printer control variables.  This
   includes both user-defined methods and implementation-defined methods.
\end{itemize}

If these rules are not obeyed, the results are undefined.

In general, the printer and the \cdf{print-object} methods should not
rebind the print control variables as they operate recursively through the
structure, but this is implementation-dependent.

In some implementations the stream argument passed to a 
\cdf{print-object} method is not the original stream but is an
intermediate stream that implements part of the printer.  Methods
should therefore not depend on the identity of this stream.

All of the existing printing functions (\cdf{write}, \cd{prin1}, 
\cdf{print}, \cdf{princ}, \cdf{pprint}, \cdf{write-to-string}, 
\cd{prin1-to-string}, \cdf{princ-to-string}, the \cd{{\Xtilde}S} and 
\cd{{\Xtilde}A} \cdf{format} operations, and the \cd{{\Xtilde}B}, \cd{{\Xtilde}D},
\cd{{\Xtilde}E}, \cd{{\Xtilde}F}, \cd{{\Xtilde}G}, \cd{{\Xtilde}\$}, 
\cd{{\Xtilde}O}, \cd{{\Xtilde}R}, and \cd{{\Xtilde}X} \cdf{format} operations when they
encounter a non-numeric value) are required to be changed to go
through the \cdf{print-object} generic function.  Each implementation is
required to replace its former implementation of printing with one or
more \cdf{print-object} methods.  Exactly which classes have methods for
\cdf{print-object} is not specified; it would be valid for an implementation
to have one default method that is inherited by all system-defined
classes.
\end{defun}

\begin{defun}[Generic function][Primary method]
reinitialize-instance instance &rest initargs \\
reinitialize-instance (instance standard-object) &rest initargs

The generic function \cdf{reinitialize-instance} can be used to change
the values of local slots according to initialization arguments.  This
generic function is called by the Meta-Object Protocol.   It can also be
called by users.

The system-supplied primary method for \cdf{reinitialize-instance}
checks the validity of initialization arguments and signals an error if
an initialization argument is supplied that is not declared valid.
The method then calls the generic function \cdf{shared-initialize}
with the following arguments:  the instance, \cdf{nil} (which means no slots
should be initialized according to their \cd{:initform} forms) and the
initialization arguments it received.

The \emph{instance} argument is the object to be initialized.

The \emph{initargs} argument consists of alternating initialization
argument names and values.

The modified instance is returned as the result.

Initialization arguments are declared valid by using the 
\cd{:initarg} option to \cdf{defclass}, or by defining methods for 
\cdf{reinitialize-instance} or \cd{shared-initialize}.  The keyword name
of each keyword parameter specifier in the lambda-list of any method
defined on \cdf{reinitialize-instance} or \cd{shared-initialize} is
declared a valid initialization argument name for all classes for
which that method is applicable.

See sections~\ref{Reinitializing-an-Instance-SECTION},
\ref{Rules-for-Initialization-Arguments-SECTION},
\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION} as well as
\cdf{initialize-instance}, \cdf{slot-boundp},
\cdf{update-instance-for-redefined-class},
\cdf{update-instance-for-different-class},
\cdf{slot-makunbound}, and \cdf{shared-initialize}.
\end{defun}


\begin{defun}[Generic function][Primary method]
remove-method generic-function method \\
remove-method (generic-function standard-generic-function) method

The generic function \cdf{remove-method} removes a method from a
generic function.  It destructively modifies the specified generic
function and returns the modified generic function as its result.

The \emph{generic-function} argument is a generic function
object.

The \emph{method} argument is a method object.  The function 
\cdf{remove-method} does not signal an error if the method is not one of the
methods on the generic function.

The modified generic function is returned.  The result of \cdf{remove-method} 
is \cdf{eq} to the \emph{generic-function} argument.

See \cdf{find-method}.
\end{defun}

\begin{defun}[Generic function][Primary method]
shared-initialize instance slot-names &rest initargs \\
shared-initialize (instance standard-object) slot-names &rest initargs

The generic function \cdf{shared-initialize} is used to fill the slots
of an instance using initialization arguments and \cd{:initform}
forms.  It is called when an instance is created, when an instance is
re-initialized, when an instance is updated to conform to a redefined
class, and when an instance is updated to conform to a different
class.  The generic function \cd{shared-initialize} is called by the
system-supplied primary method for \cdf{initialize-instance}, 
\cdf{reinitialize-instance},
\cdf{update-instance-for-redefined-class}, and
\cdf{update-instance-for-different-class}.

The generic function \cdf{shared-initialize} takes the following
arguments: the instance to be initialized, a specification of a set of
names of slots accessible in that instance, and any number of initialization
arguments.  The arguments after the first two must form an initialization
argument list.  The system-supplied primary method on 
\cdf{shared-initialize} initializes the slots with values according to the
initialization arguments and specified \cd{:initform} forms.  The
second argument indicates which slots should be initialized according
to their \cd{:initform} forms if no initialization arguments are
provided for those slots. 

The system-supplied primary method behaves as follows, regardless of
whether the slots are local or shared: 

\begin{itemize}
\item  If an initialization argument in the
initialization argument list specifies a value for that slot, that
value is stored into the slot,  even if a value has
already been stored in the slot before the method is run.

\item  Any slots indicated by the second argument that are still
unbound at this point are initialized according to their 
\cd{:initform} forms.  For any such slot that has an \cd{:initform} form,
that form is evaluated in the lexical environment of its defining 
\cdf{defclass} form and the result is stored into the slot.  For example, if
a \cd{:before} method stores a value in the slot, the \cd{:initform}
form will not be used to supply a value for the slot.

\item  The rules mentioned in
  section~\ref{Rules-for-Initialization-Arguments-SECTION} are obeyed.
\end{itemize}

The \emph{instance} argument is the object to be initialized.

The \emph{slot-names} argument specifies the slots that are to be
initialized according to their \cd{:initform} forms if no
initialization arguments apply.  It is supplied in one of three forms
as follows:

\begin{itemize}

\item  It can be a list of slot names, which specifies
the set of those slot names.

\item  It can be \cdf{nil}, which specifies the empty set of
slot names.

\item  It can be the symbol \cdf{t}, which specifies the set of
all of the slots.
\end{itemize}

The \emph{initargs} argument consists of alternating initialization 
argument names and values.

The modified instance is returned as the result.

Initialization arguments are declared valid by using the 
\cd{:initarg} option to \cdf{defclass}, or by defining methods for 
\cdf{shared-initialize}.  The keyword name of each keyword parameter
specifier in the lambda-list of any method defined on 
\cdf{shared-initialize} is declared a valid initialization argument
name for all classes for which that method is applicable.

Implementations are permitted to optimize \cd{:initform} forms that 
neither produce nor depend on side effects by evaluating these forms
and storing them into slots before running any 
\cdf{initialize-instance} methods, rather than by handling them in the
primary \cdf{initialize-instance} method.  (This optimization might
be implemented by having the \cdf{allocate-instance} method copy a
prototype instance.)

Implementations are permitted to optimize default initial value forms
for initialization arguments associated with slots by not actually
creating the complete initialization argument list when the only method
that would receive the complete list is the method on 
\cdf{standard-object}.  In this case, default initial value forms can be 
treated like \cd{:initform} forms.  This optimization has no visible
effects other than a performance improvement.

See sections~\ref{Object-Creation-and-Initialization-SECTION},
\ref{Rules-for-Initialization-Arguments-SECTION},
\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION} as well as
\cdf{initialize-instance},
\cdf{reinitialize-instance},
\cdf{update-instance-for-redefined-class},
\cdf{update-instance-for-different-class},
\cdf{slot-boundp},
and \cdf{slot-makunbound}.
\end{defun}


\begin{defun}[Function]
slot-boundp instance slot-name

The function \cdf{slot-boundp} tests whether a specific slot in an
instance is bound.

The arguments are the instance and the name of the slot.

The function \cdf{slot-boundp} returns true or false.

This function allows for writing \cd{:after}
methods on \cdf{initialize-instance} in order to initialize only
those slots that have not already been bound.

If no slot of the given name exists in the instance, \cdf{slot-missing}
is called as follows:
\begin{lisp}
(slot-missing (class-of \emph{instance}) \\
~~~~~~~~~~~~~~\emph{instance} \\
~~~~~~~~~~~~~~\emph{slot-name} \\
~~~~~~~~~~~~~~'slot-boundp)
\end{lisp}

The function \cdf{slot-boundp} is implemented using 
\cdf{slot-boundp-using-class}.
See \cdf{slot-missing}.
\end{defun}


\begin{defun}[Function]
slot-exists-p object slot-name

The function \cdf{slot-exists-p} tests whether the specified object has
a slot of the given name.

The \emph{object} argument is any object.  The \emph{slot-name} argument
is a symbol.

The function \cdf{slot-exists-p} returns true or false.

The function \cdf{slot-exists-p} is implemented using 
\cdf{slot-exists-p-using-class}.
\end{defun}


\begin{defun}[Function]
slot-makunbound instance slot-name

The function \cdf{slot-makunbound} restores a slot in an instance to
the unbound state.

The arguments to \cdf{slot-makunbound} are the instance and the name of
the slot.

The instance is returned as the result.

If no slot of the given name exists in the instance, \cdf{slot-missing}
is called as follows:
\begin{lisp}
(slot-missing (class-of \emph{instance}) \\
~~~~~~~~~~~~~~\emph{instance} \\
~~~~~~~~~~~~~~\emph{slot-name} \\
~~~~~~~~~~~~~~'slot-makunbound)
\end{lisp}

The function \cdf{slot-makunbound} is implemented using 
\cdf{slot-makunbound-using-class}.
See \cdf{slot-missing}.
\end{defun}

\begin{defun}[Generic function][Primary method]
slot-missing class object slot-name operation &optional new-value \\
slot-missing (class t) object slot-name operation &optional new-value

The generic function \cdf{slot-missing} is invoked when an attempt is
made to access a slot in an object whose metaclass is 
\cdf{standard-class} and the name of the slot provided is not a name of a
slot in that class.  
The default method signals an error.

The generic function \cdf{slot-missing} is not intended to be called by
programmers. Programmers may write methods for it.

The required arguments to \cdf{slot-missing} are the class of the object
that is being accessed, the object, the slot name, and a symbol that
indicates the operation that caused  \cdf{slot-missing} to be invoked.
The optional argument to \cdf{slot-missing} is used when the operation
is attempting to set the value of the slot.

If a method written for \cdf{slot-missing} returns values, these
values get returned as the values of the original function invocation.

The generic function \cdf{slot-missing} may be called during
evaluation of \cdf{slot-value}, \cd{(setf slot-value)}, 
\cdf{slot-boundp}, and \cdf{slot-makunbound}.  For each
of these operations the corresponding symbol for the \emph{operation}
argument is \cdf{slot-value}, \cdf{setf}, \cdf{slot-boundp}, and 
\cdf{slot-makunbound}, respectively.

The set of arguments (including the class of the instance) facilitates
defining methods on the metaclass for \cdf{slot-missing}.
\end{defun}


\begin{defun}[Generic function][Primary method]
slot-unbound class instance slot-name \\
slot-unbound (class t) instance slot-name

The generic function \cdf{slot-unbound} is called when an
unbound slot is read in an instance whose metaclass is 
\cdf{standard-class}.
The default method signals an error.

The generic function \cdf{slot-unbound} is not intended to be called
by programmers.  Programmers may write methods for it.
The function \cdf{slot-unbound} is called only by the function
\cdf{slot-value-using-class} and thus indirectly by \cdf{slot-value}.

The arguments to \cdf{slot-unbound} are the class of the instance
whose slot was accessed, the instance itself, and the name of the
slot.

If a method written for \cdf{slot-unbound} returns values, these
values get returned as the values of the original function invocation.

An unbound slot may occur if no \cd{:initform} form was
specified for the slot and the slot value has not been set, or if 
\cdf{slot-makunbound} has been called on the slot.

See \cdf{slot-makunbound}.
\end{defun}


\begin{defun}[Function]
slot-value object slot-name

The function \cdf{slot-value} returns the value contained in the slot
\emph{slot-name} of the given object.  If there is no slot with that
name, \cdf{slot-missing} is called.  If the slot is unbound,
\cdf{slot-unbound} is called.

The macro \cdf{setf} can be used with \cdf{slot-value} to change the value
of a slot. 

If an attempt is made to read a slot and no slot of the given name
exists in the instance, \cdf{slot-missing} is called as follows: 
\begin{lisp}
(slot-missing (class-of \emph{instance}) \\
~~~~~~~~~~~~~~\emph{instance} \\
~~~~~~~~~~~~~~\emph{slot-name} \\
~~~~~~~~~~~~~~'slot-value)
\end{lisp}

If an attempt is made to write a slot and no slot of the given name
exists in the instance, \cdf{slot-missing} is called as follows: 
\begin{lisp}
(slot-missing (class-of \emph{instance}) \\
~~~~~~~~~~~~~~\emph{instance} \\
~~~~~~~~~~~~~~\emph{slot-name} \\
~~~~~~~~~~~~~~'setf \\
~~~~~~~~~~~~~~\emph{new-value})
\end{lisp}

The function \cdf{slot-value} is implemented using 
\cdf{slot-value-using-class}.

Implementations may optimize \cdf{slot-value} by compiling it in-line.

See \cdf{slot-missing} and \cdf{slot-unbound}.
\end{defun}

[At this point the original CLOS report \cite{SIGPLAN-CLOS,LASC-CLOS-PART-2}
contained a specification for \cdf{symbol-macrolet}.
This specification is omitted here.  Instead, a description
of \cdf{symbol-macrolet} appears with those of related constructs in chapter~\ref{CONTRL}.---GLS]

\begin{defun}[Generic function][Primary method]
update-instance-for-different-class previous current &rest initargs \\
update-instance-for-different-class (previous standard-object)
     (current standard-object) &rest initargs

The generic function \cdf{update-instance-for-different-class} is not
intended to be called by programmers.  Programmers may write
methods for it.  This function is called only by the function \cdf{change-class}.

The system-supplied primary method on 
\cdf{update-instance-for-different-class} checks the validity of
initialization arguments and signals an error if an initialization
argument is supplied that is not declared valid.  This method then
initializes slots with values according to the initialization
arguments and initializes the newly added slots with values according
to their \cd{:initform} forms.  It does this by calling the generic
function \cdf{shared-initialize} with the following arguments: the instance,
a list of names of the newly added slots, and the initialization
arguments it received.  Newly added slots are those local slots for which
no slot of the same name exists in the previous class.

Methods for
\cdf{update-instance-for-different-class}
can be defined to
specify actions to be taken when an instance is updated.  If only 
\cd{:after} methods for \cdf{update-instance-for-different-class} are
defined, they will be run after the system-supplied primary method for
initialization and therefore will not interfere with the default
behavior of \cdf{update-instance-for-different-class}.

The arguments to \cdf{update-instance-for-different-class} are
computed by \cdf{change-class}.  When \cdf{change-class} is invoked on
an instance, a copy of that instance is made; \cdf{change-class} then
destructively alters the original instance.  The first argument to
\cdf{update-instance-for-different-class}, \emph{previous}, is that
copy; it holds the old slot values temporarily.  This argument has
dynamic extent within \cdf{change-class}; if it is referenced in any
way once \cdf{update-instance-for-different-class} returns, the
results are undefined.  The second argument to 
\cdf{update-instance-for-different-class}, \emph{current}, is the altered
original instance.

The intended use of \emph{previous} is to extract old slot values by using
\cdf{slot-value} or \cdf{with-slots} or by invoking a reader generic
function, or to run other methods that were applicable to instances of
the original class.

The \emph{initargs} argument consists of alternating initialization
argument names and values.

The value returned by \cdf{update-instance-for-different-class} is
ignored by \cdf{change-class}.

See the example for the function \cdf{change-class}.

Initialization arguments are declared valid by using the 
\cd{:initarg} option to \cdf{defclass}, or by defining methods for 
\cdf{update-instance-for-different-class} or \cdf{shared-initialize}.  The
keyword name of each keyword parameter specifier in the lambda-list of
any method defined on \cdf{update-instance-for-different-class} or 
\cdf{shared-initialize} is declared a valid initialization argument name
for all classes for which that method is applicable.

Methods on \cdf{update-instance-for-different-class} can be defined to
initialize slots differently from \cdf{change-class}.  The default
behavior of \cdf{change-class} is described in
section~\ref{Changing-the-Class-of-an-Instance-SECTION}.

See sections~\ref{Changing-the-Class-of-an-Instance-SECTION},
\ref{Rules-for-Initialization-Arguments-SECTION}, and
\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION} as well as
\cdf{change-class} and \cdf{shared-initialize}.
\end{defun}

\begin{defun}[Generic function][Primary method]
update-instance-for-redefined-class instance added-slots
    discarded-slots property-list &rest initargs \\
update-instance-for-redefined-class (instance standard-object) added-slots
    discarded-slots property-list &rest initargs

The generic function \cdf{update-instance-for-redefined-class} is not
intended to be called by programmers. Programmers may
write methods for it.  The generic function 
\cdf{update-instance-for-redefined-class} is called by the mechanism
activated by \cdf{make-instances-obsolete}.

The system-supplied primary method on 
\cdf{update-instance-for-redefined-class} checks the validity of
initialization arguments and signals an error if an initialization
argument is supplied that is not declared valid.  This method then
initializes slots with values according to the initialization
arguments and initializes the newly added slots with values according
to their \cd{:initform} forms.  It does this by calling the generic
function \cdf{shared-initialize} with the following arguments: the instance,
a list of names of the newly added slots, and the initialization
arguments it received.  Newly added slots are those local slots for which
no slot of the same name exists in the old version of the class.

When \cdf{make-instances-obsolete} is invoked or when a class has been
redefined and an instance is being updated, a property list is created
that captures the slot names and values of all the discarded slots with
values in the original instance.  The structure of the instance is
transformed so that it conforms to the current class definition.  The
arguments to \cdf{update-instance-for-redefined-class} are this
transformed instance, a list of the names of the new slots added to the
instance, a list of the names of the old slots discarded from the
instance, and the property list containing the slot names and values for
slots that were discarded and had values.  Included in this list of
discarded slots are slots that were local in the old class and are
shared in the new class.

The \emph{initargs} argument consists of alternating initialization
argument names and values.

The value returned by \cdf{update-instance-for-redefined-class} is ignored.

Initialization arguments are declared valid by using the 
\cd{:initarg} option to \cdf{defclass} or by defining methods for 
\cdf{update-instance-for-redefined-class} or \cdf{shared-initialize}.  The
keyword name of each keyword parameter specifier in the lambda-list of
any method defined on \cdf{update-instance-for-redefined-class} or 
\cdf{shared-initialize} is declared a valid initialization argument name
for all classes for which that method is applicable.

See sections~\ref{Redefining-Classes-SECTION},
\ref{Rules-for-Initialization-Arguments-SECTION}, and
\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION} as well as
\cdf{shared-initialize} and \cdf{make-instances-obsolete}.
\begin{lisp}
(defclass position () ()) \\
\\
(defclass x-y-position (position) \\*
~~((x :initform 0 :accessor position-x) \\*
~~~(y :initform 0 :accessor position-y))) \\
\\
;;; It turns out polar coordinates are used more than Cartesian  \\*
;;; coordinates, so the representation is altered and some new \\*
;;; accessor methods are added. \\
\\
(defmethod update-instance-for-redefined-class :before \\*
~~~~~~~~~~~((pos x-y-position) added deleted plist \&key) \\*
~~;; Transform the x-y coordinates to polar coordinates \\*
~~;; and store into the new slots. \\*
~~(let ((x (getf plist 'x)) \\*
~~~~~~~~(y (getf plist 'y))) \\*
~~~~(setf (position-rho pos) (sqrt (+ (* x x) (* y y))) \\*
~~~~~~~~~~(position-theta pos) (atan y x)))) \\
\\
(defclass x-y-position (position) \\*
~~~~((rho :initform 0 :accessor position-rho) \\*
~~~~~(theta :initform 0 :accessor position-theta)))
\end{lisp}
\vskip 0pt plus 10pt
\hrule width 0pt\relax
\begin{lisp}
;;; All instances of the old x-y-position class will be updated \\*
;;; automatically. \\
\\
;;; The new representation has the look and feel of the old one. \\
\\
(defmethod position-x ((pos x-y-position)) \\*
~~~(with-slots (rho theta) pos (* rho (cos theta)))) \\
\\
(defmethod (setf position-x) (new-x (pos x-y-position)) \\*
~~~(with-slots (rho theta) pos \\*
~~~~~(let ((y (position-y pos))) \\*
~~~~~~~(setq rho (sqrt (+ (* new-x new-x) (* y y))) \\*
~~~~~~~~~~~~~theta (atan y new-x)) \\*
~~~~~~~new-x))) \\
\\
(defmethod position-y ((pos x-y-position)) \\*
~~~(with-slots (rho theta) pos (* rho (sin theta))))
\end{lisp}
\begin{lisp}
(defmethod (setf position-y) (new-y (pos x-y-position)) \\*
~~~(with-slots (rho theta) pos \\*
~~~~~(let ((x (position-x pos))) \\*
~~~~~~~(setq rho (sqrt (+ (* x x) (* new-y new-y))) \\*
~~~~~~~~~~~~~theta (atan new-y x)) \\*
~~~~~~~new-y)))
\end{lisp}
\end{defun}

\begin{defmac}
with-accessors ({slot-entry}*) instance-form
     {declaration}* {form}*

The macro \cdf{with-accessors} creates a lexical environment in which
specified slots are lexically available through their accessors as if
they were variables.  The macro \cdf{with-accessors} invokes the
appropriate accessors to access the specified slots.  Both \cdf{setf}
and \cdf{setq} can be used to set the value of the slot. 

The result returned is that obtained by executing the forms specified
by the \emph{body} argument.

Example:

\begin{lisp}
(with-accessors ((x position-x) (y position-y)) p1 \\*
~~(setq x y))
\end{lisp}


A \cdf{with-accessors} expression of the form
\begin{lisp}
(with-accessors (\textrm{$slot_1$} ... \textrm{$slot_{n}$}) \emph{instance} \\*
~~$declaration_1$ ... $declaration_{m}$) \\*
~~$form_1$ ... $form_{k}$)
\end{lisp}
expands into the equivalent of
\begin{lisp}
(let ((\emph{in} \emph{instance})) \\
~~(symbol-macrolet ((\textrm{$variable_1$} (\textrm{$accessor_1$} \emph{in})) \\*
~~~~~~~~~~~~~~~~~~~~... \\*
~~~~~~~~~~~~~~~~~~~~(\textrm{$variable_{n}$} (\textrm{$accessor_{n}$} \emph{in}))) \\*
~~~~$declaration_1$ ... $declaration_{m}$) \\*
~~~~$form_1$ ... $form_{k}$)
\end{lisp}


[X3J13 voted in March 1989
\issue{SYMBOL-MACROLET-SEMANTICS}
to modify the definition of \cdf{symbol-macrolet} substantially
and also voted
\issue{SYMBOL-MACROLET-DECLARE} to allow declarations before the body
of \cdf{symbol-macrolet} but with peculiar treatment of \cdf{special}
and type declarations.  The syntactic changes are reflected in this definition
of \cdf{with-accessors}.---GLS]

See \cdf{with-slots} and \cdf{symbol-macrolet}.
\end{defmac}

% \begin{defspec}
% with-added-methods (function-name lambda-list
%       <?option | {method-description}*>)
%       {form}*

% \relax
% \vskip 0pt plus 4pt
% \noindent
% The \cdf{with-added-methods} special operator
% produces new generic functions and establishes new
% lexical function definition bindings.  Each generic function is created by
% adding the set of methods specified by its method definitions to a copy of the
% lexically visible generic function of the same name and its methods.  If
% such a generic function does not already exist, a new generic function is
% created; this generic function has lexical scope.

% The special operator \cdf{with-added-methods} is used to define functions
% whose names are meaningful only locally and to execute a series of
% forms with these function definition bindings.


% The names of functions defined by \cdf{with-added-methods} have lexical
% scope; they retain their local definitions only within the body of the
% \cdf{with-added-methods} construct.  Any references within the body of the
% \cdf{with-added-methods} construct to functions whose names are the same
% as those defined within the \cdf{with-added-methods} form are thus
% references to the local functions instead of to any global functions
% of the same names.  The scope of these generic function definition bindings
% includes the method bodies themselves as well as the body of the 
% \cdf{with-added-methods} construct.





% The \emph{function-name}, \emph{option}, \emph{method-qualifier}, and
% \emph{specialized-lambda-list} arguments are the same as for
% \cdf{defgeneric}. 

% The body of each method is enclosed in an implicit block.  If
% \emph{function-name} is a symbol, this block bears the same name as the
% generic function.  If \emph{function-name} is a list of the form 
% \cd{(setf \emph{symbol})}, the name of the block is \emph{symbol}.  


% The result returned by \cdf{with-added-methods} is the value or values
% of the last form executed.  If no forms are specified, 
% \cdf{with-added-methods} returns \cdf{nil}.


% If a generic function with the given name already exists, the
% lambda-list specified in the \cdf{with-added-methods} form must be
% congruent with the lambda-lists of all existing methods on that
% function as well as with the lambda-lists of all methods defined by the
% \cdf{with-added-methods} form; otherwise an error is signaled.

% If \emph{function-name} specifies an existing generic function that has a
% different value for any of the following \emph{option} arguments, the
% copy of that generic function is modified to have the new value: 
% \cd{:argument-precedence-order}, \cdf{declare}, \cd{:documentation}, 
% \cd{:generic-function-class}, \cd{:method-combination}.

% If \emph{function-name} specifies an existing generic function that has a
% different value for the \cd{:method-class} \emph{option} argument,
% that value is changed in the copy of that generic function, but any
% methods copied from the existing generic function are not changed.

% If a function of the given name already exists, that function is copied into
% the default method for a generic function of the given name.  Note that
% this behavior differs from that of \cdf{defgeneric}.

% If a macro or special operator of the given name already exists, an error
% is signaled.

% If there is no existing generic function, the \emph{option} arguments have
% the same default values as the \emph{option} arguments to \cdf{defgeneric}.

% See \cdf{generic-labels},
% \cdf{generic-flet},
% \cdf{defmethod},
% \cdf{defgeneric},
% and \cdf{ensure-generic-function}.
% \end{defspec}


\begin{defmac}
with-slots ({slot-entry}*) instance-form {declaration}* {form}*

\begin{tabbing}
\emph{slot-entry} ::= \emph{slot-name} {\Mor} \cd{(\emph{variable-name} \emph{slot-name})}
\end{tabbing}
The macro \cdf{with-slots} creates a lexical context for referring to
specified slots as though they were variables.  Within such a context
the value of the slot can be specified by using its slot name, as if
it were a lexically bound variable.  Both \cdf{setf} and \cdf{setq}
can be used to set the value of the slot.

The macro \cdf{with-slots} translates an appearance of the slot name as
a variable into a call to \cdf{slot-value}.

The result returned is that obtained by executing the forms specified
by the \emph{body} argument.

Example:

\begin{lisp}
(with-slots (x y) position-1 \\*
~~(sqrt (+ (* x x) (* y y)))) \\
\\
(with-slots ((x1 x) (y1 y)) position-1 \\*
~~(with-slots ((x2 x) (y2 y)) position-2 \\*
~~~~(psetf x1 x2 \\*
~~~~~~~~~~~y1 y2)))) \\
\\
(with-slots (x y) position \\*
~~(setq x (1+ x) \\*
~~~~~~~~y (1+ y)))
\end{lisp}

A \cdf{with-slots} expression of the form:
\begin{lisp}
(with-slots ($slot\mhyphen entry_{1}$ ... $slot\mhyphen entry_{n}$) \emph{instance} \\*
~~$declaration_1$ ... $declaration_{m}$) \\*
~~$form_1$ ... $form_{k}$)
\end{lisp}
expands into the equivalent of
\begin{lisp}
(let ((\emph{in} \emph{instance})) \\
~~(symbol-macrolet ($Q_1$ ... $Q_{n}$) \\*
~~~~$declaration_1$ ... $declaration_{m}$) \\*
~~~~$form_1$ ... $form_{k}$)
\end{lisp}
where ${Q}_{j}$ is 
\begin{lisp}
($slot\mhyphen entry_{j}$ (slot-value \emph{in} '$slot\mhyphen entry_{j}$))
\end{lisp}
if $slot\mhyphen entry_{j}$ is a symbol and is
\begin{lisp}
($variable\mhyphen name_{j}$ (slot-value \emph{in} '$slot\mhyphen name_{j}$))
\end{lisp}
if ${slot\mhyphen entry}_{j}$
is of the form \cd{($variable\mhyphen name_{j}$ $slot\mhyphen name_{j}$)}.

[X3J13 voted in March 1989
\issue{SYMBOL-MACROLET-SEMANTICS}
to modify the definition of \cdf{symbol-macrolet} substantially
and also voted
\issue{SYMBOL-MACROLET-DECLARE} to allow declarations before the body
of \cdf{symbol-macrolet} but with peculiar treatment of \cdf{special}
and type declarations.  The syntactic changes are reflected in this definition
of \cdf{with-slots}.---GLS]

See \cdf{with-accessors} and \cdf{symbol-macrolet}.
\end{defmac}


\else %RUSSIAN

\chapter{Объектная система Common Lisp'а}
\label{CLOS}

Авторы:  Daniel G.~Bobrow, Linda G.~DeMichiel,
Richard P.~Gabriel, Sonya E.~Keene, Gregor Kiczales,
и David A.~Moon

\section{Концепция программного интерфейса}

Common Lisp Object System (CLOS [клос]) --- это объектно-ориентированное
расширение для Common Lisp'а.  Объектная система основана на обобщённых
функциях, множественном наследовании, декларации сочетания методов и
метаобъектном протоколе.

Первые две части данной спецификации описывают программный интерфейс для
использования CLOS'а. Первая часть содержит описание концепций CLOS'а, а вторая
--- описание функций и макросов, используемых в 
интерфейсе для программиста. Третья часть описывает методы для изменения
поведения объектной системы.

Основными объектами CLOS'а являются классы, экземпляры классов, обобщённые
функции и методы.

Объект \emph{класса} отображает структуру и поведение множества других
объектов, которые называются \emph{экземплярами} класса.
Каждый объект Common Lisp'а является \emph{экземпляром} класса. Класс объекта
устанавливает ряд операций, которые могут быть выполнены над объектом.

\emph{Обобщённые функций} --- это функции, поведение которых зависит от классов
или типов её аргументов. Объект обобщённой функции имеет множество методов,
лямбда-список, тип сочетания методов и другую информацию. \emph{Методы} содержат
поведение, которое зависит от класса или типа, переданный аргументов, и операции
обобщённой функции. Говорится, что метод \emph{специализирует} обобщённую
функцию. При вызове обобщённая функция выполняет подмножество методов. Какие
методы будут выполнены зависит от классов или типов аргументов функции.

Обобщённая функция может использоваться также как и обычная функция. В
частности, обобщённая функция может быть аргументом для таких функций, как
\cdf{funcall} и \cdf{apply}, и может иметь глобальное имя.% или локальное имена.

\emph{Метод} является объектом, который содержит функцию, последовательность
\emph{специализаторов параметров}, которые указывают возможные для данного
метода классы и типы аргументов, и последовательность \emph{квалификаторов},
которые используются для \emph{сочетания методов} при определении позиции метода
относительно других методов.  Каждый обязательный формальный параметр каждого
метода имеет связанный специализатор, и метод будет вызываться только при
аргументах, удовлетворяющих данным специализаторам.

Функционал сочетаний методов управляет порядком вызова методов и возвратом
значений обобщённой функцией. По-умолчанию CLOS использует
стандартный тип сочетания методов, но он также предоставляет возможность
определения новых типов сочетаний.

\subsection{Терминология для ошибок}
\label{Error-Terminology-SECTION}

Ситуация --- это выполнение выражения в некотором заданном контексте. Например,
ситуацией может быть вызов функции с аргументами, которые не удовлетворяют
некоторым заданным ограничениям.

В спецификации CLOS'а описано поведение программ во всех ситуациях. Кроме того
указаны некоторые возможности для разработчиков реализаций. Реализация не может
расширять синтаксис или семантику объектной системы за исключением явно
описанных возможностей.  В частности, реализация не может расширять синтаксис
объектной системы так, чтобы появлялась двусмысленность между спецификацией и
расширением.

\begin{flushdesc}

\item[<<При наступлении события \emph{S} сигнализируется ошибка.>>]

Данная терминология имеет следующий смысл:

\begin{itemize}
\item Если возникает данная ситуация, в интерпретаторе и компиляторе при всех
  возможных уровнях оптимизации будет сигнализирована ошибка.

\item Корректные программы могут полагаться на тот факт, что если возникает
  данная ситуация, в интерпретаторе и компиляторе при всех возможных уровнях
  оптимизации будет сигнализирована ошибка.

\item Любая реализация должна определять такие ошибки в  интерпретаторе и
  компиляторе при всех возможных уровнях оптимизации. 
\end{itemize}

\item[<<При наступлении события \emph{S} должна бы быть сигнализирована ошибка.>>]
  
  Данная терминология имеет следующий смысл:
  
  \begin{itemize}
  \item Если возникает данная ситуация, будет сигнализирована ошибка по
    крайней мере в интерпретаторе и в компиляторе при самом безопасном уровне
    оптимизации.
    
  \item Корректная программа не может полагаться на тот факт, что ошибка будет
    сигнализирована.
    
  \item При сигнализировании результаты выполнения не определены (смотрите
    ниже).
  \end{itemize}
\item[<<При наступлении события \emph{S} результаты не определены.>>]

  Данная терминология имеет следующий смысл:
  
  \begin{itemize}
  \item При наступлении данного события, результаты не могут быть
    определены. Результаты могут быть от безобидных до фатальных.
    
  \item Реализация может детектировать данную ситуацию и сигнализировать ошибку,
    но это не является требованием.
    
  \item Программа не может как-либо полагаться на данную ситуацию.
  \end{itemize}

\item[<<При наступлении события \emph{S} результаты точно не установлены.>>]
  
Данная терминология имеет следующий смысл:

\begin{itemize}
\item В объектной системе эффекты от данной ситуации не определены, но они
  безобидны.
  
\item Реализация может явно определять последствия данной ситуации.
  
\item Программы не могут зависеть от последствий данной ситуации, однако программы
  должны обрабатывать данную ситуацию как не установленную, но безобидную.
\end{itemize}

\item[<<CLOS может быть расширен для покрытия ситуации \emph{S}.>>]

Смысл данной терминологии в том, что реализация может обрабатывать данную
ситуацию \emph{S} одним из трёх случаев:

\begin{itemize}
\item При наступлении события \emph{S} будет сигнализирована ошибка по
  крайней мере в интерпретаторе и в компиляторе при самом безопасном уровне
  оптимизации.
  
\item При наступлении события \emph{S} результаты выполнения не определены.

\item При наступлении события \emph{S} результаты точно определены.
\end{itemize}

В дополнение данная терминология имеет следующий смысл:

\begin{itemize}
\item Переносимая программа не может зависеть от последствий данной
  ситуации. Переносимая программа должна считать данную ситуацию не
  определённой.
\end{itemize}

\item[<<Реализация может расширять синтаксис \emph{S}.>>]

Эта терминология имеет следующий смысл:

\begin{itemize}
\item Реализация может определять недвусмысленные расширения для синтаксиса
  \emph{S}.

\item Переносимая программа не может зависеть от этого расширения. Все
  переносимые программы должны считать синтаксис как бессмысленный.
\end{itemize}
\end{flushdesc}

Спецификация CLOS может запрещать данные расширения, но разрешая другие. 

\subsection{Классы}
\label{Classes-SECTION}

\emph{Класс} является объектом, который устанавливает структуру и поведение
некоторого множества других объектов, которые называются \emph{экземплярами}
класса.

Класс может наследовать структуру и поведение от других классов.
Класс, определение которого при наследовании ссылается на другие классы,
называется \emph{подклассом} каждого из этих классов. Классы, на которые при
наследовании происходит ссылка, называются \emph{суперклассами} для наследующего
класса.

У класса может быть \emph{имя}. Для получения имени класса может использоваться
функция \cdf{class-name}, которая принимает объект класса и
возвращает его имя. Имя анонимного класса --- \cdf{nil}. Имя класса может
задаваться символом. Функция \cdf{find-class} принимает символ и возвращает класс, имя
которого заданно символом. Класс имеет \emph{собственное имя}, если имя является
символом и если имя задаёт данный класс. То есть, класс~\emph{C} имеет
\emph{собственное имя}~\emph{S}, если \emph{S}~= \cd{(class-name \emph{C})} и
\emph{C}~= \cd{(find-class \emph{S})}. Следует отметить, что существует
возможность того, что \cd{(find-class $S_1$)} = \cd{(find-class $S_2$)} и
$S_1\neq S_2$.
Если \emph{C}~= \cd{(find-class \emph{S})}, мы говорим, что \emph{C} является
\emph{классом с именем} \emph{S}.

Класс $C_1$ является \emph{прямым суперклассом} класса $C_2$, если $C_2$ в своём
определении явно указывает $C_1$ как родительский. В этом случае $C_2$ является
\emph{прямым подклассом} $C_1$. Класс $C_n$ является \emph{суперклассом} для
класса $C_1$ в том случае, если существует ряд классов $C_{2},\ldots,C_{n-1}$
такой, что $C_{i+1}$ является прямым суперклассом $C_i$ для $1 \leq \emph{i} <
\emph{n}$. В этом случае $C_1$ является подклассом $C_n$. Класс никогда не
рассматривается как суперкласс или подкласс самого себя. То есть, если $C_1$
является суперклассом $C_2$, тогда $C_{1} \neq C_{2}$. Множество классов,
составленное из некоторого класса \emph{C} и его суперклассов, называется
<<\emph{С} и его суперклассы>>.

Каждый класс имеет \emph{список приоритетности классов}, который является списком
из данного класса и его суперклассов.
Список отсортирован от наиболее
специфичного к наименее специфичному классу.
Список приоритетности классов используется в нескольких случаях. В общем случае
наиболее специфичные классы могут \emph{скрывать}, или перезаписывать свойства,
которые могли бы быть унаследованы от менее специфичных классов. Выбор метода и
процесс сочетания методов использует список приоритетности классов для
упорядочивания методов от наиболее к наименее специфичным.

При определении класса является важным порядок прямых суперклассов. Каждый класс
имеет \emph{локальный список приоритетности классов}, состоящий из данного класса
и его прямых суперклассов в порядке, в котором они перечислены в определении.

Список приоритетности классов всегда состоит из локальных списков приоритетности
классов для каждого класса, перечисленногов первом списка. Классы в каждом
локальном списке находятся в том же порядке, что и в общем списке. Если порядок
в локальном списке противоречит всем остальным, то список приоритетности не
создаётся, и сигнализируется ошибка.  Список приоритетности классов и его
создание описывается в
разделе~\ref{Determining-the-Class-Precedence-List-SECTION}.

Классы организованы в ориентированный ациклический граф. Существует два наиболее
значимых класса: \cdf{t} и \cdf{standard-object}. Класс \cdf{t} не имеет
суперклассов (родителей). Он является суперклассом для всех классов, за
исключением самого себя. Класс \cdf{standard-object} является экземпляром класса
\cdf{standard-class} и является суперклассом для всех классов - экземпляров
\cdf{standard-class}, за исключением самого себя.

В языке предусмотрено отображение пространства CLOS классов в пространство
типов. Большинство стандартных типов Common Lisp'а имеют соответствующий класс с
тем же именем, что и тип. Но некоторые типы соответствия не имеют. Интеграция
типов и классов описана в разделе~\ref{Integrating-Types-and-Classes-SECTION}.

Классы представлены объектами, которые в свою очередь являются экземплярами
классов. Класс класса объекта называется \emph{метаклассом} данного
объекта. Когда конкретной объект не оговаривается, термин \emph{метакласс} будет
использоваться для обозначения класса, экземпляры которого сами являются
классами.  
Метакласс устанавливает форму наследования, используемую классами,
которые являются его экземплярами, и представление экземпляров этих классов.
CLOS предоставляет основной метакласс, \cdf{standard-class}, которого вполне
достаточно для большинства программ. Метаобъектный протокол предоставляет
механизм для определения и использования новых метаклассов.

За исключением явного указания, все классы упомянутые в этой главе являются
экземплярами класса \cdf{standard-class}, все обобщённые функции являются
экземплярами класса \cdf{standard-generic-function}, и все методы являются
экземплярами класса \cdf{standard-method}.

\subsubsection{Определение классов}

Для определения новых классов используется макрос \cdf{defclass}.
Определение класса включает следующие пункты:
\begin{itemize}
\item Имя нового класса. Для вновь определяемого класса имя будет являться
  собственным.

\item Список прямых суперклассов нового класса.

\item Множество \emph{спецификаторов слотов}. Каждый спецификатор слота включает
  имя слота и ноль или более \emph{параметров слота}. Параметры слота
  принадлежат только одному слоту. Если определение класса содержит два
  спецификатора слотов с одинаковыми именами, то сигнализируется ошибка.

\item Множество \emph{параметров класса}. Каждый параметр класса принадлежит
  всему классу в целом.
\end{itemize}

Параметры слота и класса формы \cdf{defclass} предоставляют механизм для
следующих пунктов:
\begin{itemize}
\item Указание первоначального значения по-умолчанию для заданного слота.

\item Указание, что методы для обобщённых функций для записи и чтения слотов
  будут сгенерированы автоматически.

\item Указание будет ли заданный слот общим для всех экземпляров класса, или
  каждый экземпляр будет иметь свой собственный слот.

\item Указание множества первоначальных аргументов и их значений при создании
  экземпляра класса.

\item Указание того, какой метакласс использоваться для данного класса.

\item Указание того, какой тип данных будет храниться в слоте.

\item Указание строк документации для слотов.
\end{itemize}

\subsubsection{Создание экземпляров классов}

Обобщённая функция \cdf{make-instance} создаёт и возвращает новый экземпляр
объекта. Объектная система предоставляет несколько способов для указания того,
как будет инициализирован новый экземпляр. Например, можно указать
первоначальные значения для слотов с помощью аргументов для \cdf{make-instance}
или с помощью указания их в спецификаторе слота.

В методах для обобщённых
функций, которые являются частью инициализационного протокола, могут быть
выполнены другие действия для инициализации. Весь
инициализационный протокол описан в
разделе~\ref{Object-Creation-and-Initialization-SECTION}.

\subsubsection{Слоты}

Объект, метаклассом которого является \cdf{standard-class}, имеет ноль или более
слотов.
Слоты объекта определяются классом объекта. Каждый слот может содержать одно
значение. Имя слота является обычным символом, который может использоваться и
для переменной.

Когда слот не имеет значения, слот называется \emph{несвязанным}. Когда
происходит чтение несвязанного слота, вызывается обобщённая функция
\cdf{slot-unbound}. По-умолчанию установленный системой главный метод для
\cdf{slot-unbound} сигнализирует ошибку.

Значение по-умолчанию для слота устанавливается с помощью параметра слота
\cd{:initform}. Когда для установки значения используется форма \cd{:initform},
то она вычисляется в том же лексическом окружении, что и
\cdf{defclass}. \cdf{:initform} вместе с лексическим окружением, тем же что и
для \cdf{defclass}, называется \emph{захваченной} \cd{:initform}.
Смотрите раздел~\ref{Object-Creation-and-Initialization-SECTION}.

\emph{Локальный слот} --- это слот, который доступен только в рамках одного
экземпляра класса. \emph{Разделяемый слот} --- это слот, который одновременно
доступен для нескольких экземпляров класса.

Говорится, что класс \emph{определяет} слот с заданным именем, если форма
\cdf{defclass}, которая создаёт класс, содержит спецификатор слота с этим
именем.
Определение локального слота не создаёт его немедленно. Определение указывает,
что слот будет создаваться каждый раз при создании экземпляра
класса. Определение разделяемого слота создаёт его немедленно.

Параметр \cd{:allocation} для \cdf{defclass} указывает тип создаваемого слота.
Если значение \cd{:allocation} равно \cd{:instance}, тогда слот будет
локальным. Если значение \cd{:allocation} равно \cd{:class}, тогда слот будет
разделяемым.

Слот называется \emph{доступным} для экземпляра класса, если слот был определён
в этом классе, или был унаследован от суперкласса. Заданное имя может указывать
на не более чем один слот экземпляра класса. Разделяемый слот доступен для всех
экземпляров класса. Подробное описание наследования слотов дано в
разделе~\ref{Inheritance-of-Slots-and-Slot-Options-SECTION}.

\subsubsection{Получение доступа к слотам}

К слоту можно получить доступ двумя способами: с помощью использования простой
функции \cdf{slot-value} или с помощью обобщённых функций, созданных с помощью
формы \cdf{defclass}.

\cdf{slot-value} может быть использована с любым именем слота, которое было
определено в форме \cdf{defclass}, для доступа к некоторому слоту,
доступному в экземпляре класса. 

Макрос \cdf{defclass} предоставляет синтаксис для генерации методов для чтения и
записи слотов. Если необходимо \emph{чтение}, тогда автоматически генерируется
метод для чтения значения слота, однако для записи метод не генерируется. Если
необходима \emph{запись}, тогда автоматически генерируется метод для записи
значение в слот, однако для чтения метод не генерируется. Если необходим
\emph{аксессор}, тогда автоматически генерируются методы для чтения и для
записи. Метода для чтения и записи реализуются с помощью \cdf{slot-value}.

Когда для слота указываются методы чтения и записи, то также указывается имя для
обобщённой функции. Если в качестве имени метода указан символ \emph{name},
тогда именем обобщённой функции для записи слота является символ \emph{name}, и
обобщённая функция принимает два аргумента: новое значение и экземпляр класса,
соответственно. Если имя указанное для аксессора является символом \emph{name},
имя обобщённой функции для чтения слота является символом \emph{name}, и имя
обобщённой функции для записи слота является символом списком \cd{(setf
  \emph{name})}.

Обобщённая функция созданная в результате использования параметров слота чтения,
записи или аксессора является обычной обобщённой функцией, и может
использоваться в соответствующих местах.

Следует отметить, что \cdf{slot-value} может использоваться для чтения или
записи значение в слот вне зависимости от того, существуют ли метода для чтения
или записи слота.
Когда используется \cdf{slot-value}, методы чтения или записи не вызываются.

Макрос \cdf{with-slots} может быть использован для установки лексического
окружения, в котором указанные слоты доступны лексически как если бы они были
просто переменными. Макрос \cdf{with-slots} вызывает функцию \cdf{slot-value}
для доступа к указанным слотам.

Макрос \cdf{with-accessors} может быть использован для установки лексического
окружения, в котором указанные слоты доступны лексически с помощью аксессоров
как если бы они были просто переменными. Макрос \cdf{with-accessors} вызывает
соответствующие аксессоры для доступа к указанным слотам. Любой аксессор,
указанный в \cdf{with-accessors} должен быть уже доступным перед
использованием.

\subsection{Наследование}
\label{Inheritance-SECTION}

Класс может наследовать методы, слоты и другие параметры формы \cdf{defclass} от
своих суперклассов (родительских классов). Следующие разделы описывают
наследование методов, слотов и их параметров, и параметров класса.

\subsubsection{Наследование методов}
\label{Inheritance-of-Methods-SECTION}

Подкласс наследует методы в том смысле, что любой метод применимый ко всем
экземплярам некоторого класса также может быть применён ко всем экземплярам
любого подкласса данного класса.

Наследование методов работает одинаково вне зависимости от того, был ли метод
создан с помощью формы определения метода или с помощью параметра формы
\cdf{defclass}, который указал на автоматическую генерацию метода.

Подробное описание наследования методов дано в
разделе~\ref{Method-Selection-and-Combination-SECTION}.

\subsubsection{Наследование слотов и их параметров}
\label{Inheritance-of-Slots-and-Slot-Options-SECTION}

Множество имен всех слотов доступных в экземпляре класса \emph{C} является
объединением множеств слотов определяемых классом \emph{С} и его суперклассами.
\emph{Структура} экземпляра --- это множество имён локальных слотов в данном
экземпляре.

В простейшем случае, среди класса \emph{C} и его суперклассов только один из них
определяет слот с заданным именем. Если слот определён в суперклассе \emph{C},
слот называется \emph{унаследованным}. Характеристики слота установлены с
помощью спецификатора слота в определяющем его классе. Рассмотрим класс
определяющий слот \emph{S}. Если значение параметра слота \cd{:allocation} равно
\cd{:instance}, тогда \emph{S} является локальным слотом и каждый экземпляр
класса \emph{C} имеет свой собственный слот с именем \emph{S}. Если значение
параметра слота \cd{:allocation} равно \cd{:class}, тогда \emph{S} является
разделяемым слотом, класс, который определял \emph{S} хранит значение слота, и
все экземпляры \emph{C} могут получить доступ к этому слоту. Если параметр слота
\cd{:allocation} не указан, по-умолчанию используется \cd{:instance}.

В общем случае, среди классов \emph{C} и его суперклассов определять слот с
заданным именем могут несколько классов. В таких случаях в экземпляре класса
\emph{C} будет доступен только один слот, и свойства этого слота будут
комбинацией нескольких спецификаторов слотов в соответствие с пунктами:

\begin{itemize}

\item Все спецификаторы слота для данного имени слота упорядочиваются от
  наиболее к наименее специфичному, в соответствие списка приоритетности классов
  для \emph{C}, которые этот слот определяют. All references to the specificity
  of slot specifiers immediately following refer to this ordering.

\item Тип слота (разделяемый, локальный) определяется наиболее близким
  спецификатором слота. Если наиболее близкий спецификатор слота не содержит
  параметр \cd{:allocation}, используется значение \cd{:instance}. Более
  дальние спецификаторы слота влияния на тип слота не
  оказывают.

\item По-умолчанию первоначальная форма значения для слота является значением
  параметра слота \cd{:initform} из наиболее близкого спецификатора слота,
  который такой параметр содержит. Если ни один спецификатор слота не содержит
  параметр \cd{:initform}, слот не будет иметь первоначальное значение
  по-умолчанию.

\item Содержимое слота всегда будет принадлежать типу
  \cd{(and $T_1$ $\ldots$ $T_{n}$)},
  где $T_1, \ldots, T_{n}$ являются значениями параметра слота \cd{:type},
  содержащимися во всех спецификаторах слота. Если спецификатор слота не содержит
  параметр \cd{:type}, содержимое слота будет всегда принадлежать типу
  \cdf{t}. Результат попытки сохранить в слоте значение, которое не
  принадлежит указанному типу, не определён.

\item Множество аргументов, которые инициализируют заданный является
  объединением всех аргументов перечисленных в параметре слота \cd{:initarg} во
  всех спецификаторах.

\item Строка документации для слота будет взята из наиболее ближнего
  спецификатора, который содержит параметр \cd{:documentation}. Если ни один
  спецификатор не содержал данного параметра, то слот не будет содержать строку
  документации.
\end{itemize}

Следствие правила назначения типа слота (разделяемого, локального) заключается в
том, что разделяемый слот 
может быть затенён. Например, если класс $C_1$ определяется слот с именем
\emph{S}, значение параметра \cd{:allocation} которого равно \cd{:class}, то
этот слот будет доступен для всех экземпляров $C_1$ и его подклассов. Однако,
если $C_2$ является подклассом $C_1$ и также определяет слот с именем \emph{S},
слот из $C_1$ не будет разделяемым между экземплярами $C_2$ и его
подклассами. Если класс $C_1$ определяет разделяемый слот, тогда любой подкласс
$C_2$ для $C_1$ будет иметь этот разделяемый слот, пока форма \cdf{defclass} для
$C_2$ не определит слот с тем же именем, или $C_2$ не получит суперкласс
приоритетнее суперкласса $C_1$, который определяет слот с таким же именем.

Следствие из правила указания типа содержимого слота заключается в том, что
значение слота удовлетворяет ограничениям типа каждого спецификатора слота в
данном классе и всех его суперклассов. Так как результат попытки сохранения
значения, которое не удовлетворяет типу, не определён, то слот может случайно
содержать это значение.

Параметры слота \cd{:reader}, \cd{:writer} и \cd{:accessor} создают методы, а не
определяют какие-либо свойства слота.
Наследование методов чтения и записи описано в разделе~\ref{Inheritance-of-Methods-SECTION}.

Методы, которые выполняют доступ к слотам, используют только имя слота и тип
значения слота. Предположим, что суперкласс предоставляет метод, который
обеспечивает доступ к разделяемому слота с некоторым именем, и подкласс
определяет локальный слот с этим же именем. Если метод, представленный от
суперкласса, используется для экземпляра подкласса, метод будет оперировать с
локальным слотом.

\subsubsection{Наследование параметров класса}

Параметр класса \cd{:default-initargs} наследуется. Множество всех
первоначальных аргументов класса является объединением множеств этих аргументов
для данного класса и всех его суперклассов.
В случае коллизий выбирается значение наиболее близкого класса.

Если некоторый параметр класса \cd{:default-initargs} определяет аргумент с
одним и тем же именем более одного раза, сигнализируется ошибка.

\subsubsection{Примеры}

\begin{lisp}
(defclass C1 () \\*
~~((S1 :initform 5.4 :type number) \\*
~~~(S2 :allocation :class))) \\
\\
(defclass C2 (C1) \\*
~~((S1 :initform 5 :type integer)\\*
~~~(S2 :allocation :instance)\\*
~~~(S3 :accessor C2-S3)))
\end{lisp}

Экземпляры класса \cd{C1} содержат локальный слот с именем \cd{S1}, значение
по-умолчанию которого 5.4 и это значение всегда должно быть числовым.
Класс \cd{C1} также содержит разделяемый слот с именем \cd{S2}.

В экземплярах класса \cd{C2} будут присутствовать слоты с именем
\cd{S1}. Первоначальное значение по-умолчанию для слота \cd{S1} равно 5.
Значение слота \cd{S1} принадлежит типу \cd{(and integer number)}. В экземплярах
\cd{C2} также будут присутствовать слоты с именами \cd{S2} и \cd{S3}. Класс
\cd{C2} также имеет метод \cd{C2-S3} для чтения значения слота \cd{S3}. Данный
метод также используется для записи значения в слот \cd{S3}.

\subsection{Интеграция типов и классов} 
\label{Integrating-Types-and-Classes-SECTION} 

CLOS отображает пространство классов в пространство типов Common Lisp'а.
Каждый класс, который имеет имя собственное, имеет соответствующий одноимённый тип.

Собственное имя любого класса является корректным спецификатором типа. Кроме
того, каждый объект класса (не экземпляр) является корректным спецификатором
типа. Таким образом выражение \cd{(typep \emph{object class})} вычисляется в
истину, если класс \emph{object} является собственно классом \emph{class} или
подклассом для \emph{class}.
Вычисление выражения \cd{(subtypep \emph{class1 class2})} возвращает значения
\cdf{t}~и~\cdf{t}, если \emph{class1} является подклассом \emph{class2} или если
они являются одним и тем же классом, иначе выражение возвращает значения
\cdf{nil}~и~\cdf{t}. Если \emph{I} является экземпляром некоторого класса
\emph{C} с именем \emph{S} и \emph{C} является экземпляром метакласса
\cdf{standard-class}, тогда вычисление выражения \cd{(type-of \emph{I}} будет
возвращать \cdf{S}, если \emph{S} является собственным именем \emph{C}. Если
\emph{S} не является именем собственным \emph{C}, выражение \cd{(type-of
  \emph{I})} будет возвращать \emph{C}.

Так как имена классов и объекты (не экземпляры) классов является спецификаторами
типов, они могут быть использованы в специальном операторе \cdf{the} и в
декларациях типов.

Многие, но не все, определённые стандартом спецификаторы типов имеют
соответствующие классы с тем же именем собственным. Эти типы перечислены в
таблице~\ref{CLOS-PRECEDENCE-TABLE}. Например, тип \cdf{array} имеет
соответствующий одноимённый класс. Спецификаторы типов, представленные списками,
не имеют соответствующих классов. Форма \cdf{deftype} не создаёт никаких классов.

Любой класс, который соответствует определённому стандартом спецификатору типа,
может быть реализован тремя способами на усмотрение реализации. Он может быть
\emph{стандартным классом} (типов класса, определяемым с помощью
\cdf{defclass}), \emph{классом структуры} (определяемым с помощью
\cdf{defstruct}), или \emph{встроенным классом} (реализованным специальным
нерасширяемым способом).

Встроенный класс тот, экземпляры которого имеют ограниченные возможности или
специальные представления. При попытке использовать \cdf{defclass} для определения
подкласса для встроенного класса будет сигнализирована ошибка. При вызове
\cdf{make-instance} для создания экземпляра встроенного класса будет
сигнализирована ошибка. При вызове
\cdf{slot-value} для создания экземпляра встроенного класса будет
сигнализирована ошибка. 
При переопределении встроенного класса или использовании \cdf{change-class} для
изменения класса экземпляра в или из встроенного класса будет сигнализирована
ошибка.
Однако встроенные классы могут быть использованы в качестве специализатора
параметра в методах.

Существует возможность определения является ли класс встроенным с помощью
проверки метакласса. Стандартный класс является экземпляром метакласса
\cdf{standard-class}, встроенный класс является экземпляром метакласса
\cdf{built-in-class}, и класс структуры является экземпляром метакласса
\cdf{structure-class}.

Любой тип структуры, созданный с помощью \cdf{defstruct} без использования
параметра \cd{:type}, имеет соответствующий класс. Этот класс является
экземпляром метакласса \cdf{structure-class}.

Параметр \cd{:include} \cdf{defstruct} создаёт прямой подкласс класса,
соответствующего наследуемой структуре.

Много стандартных Common Lisp'овых спецификаторов
типов имеют соответствующие классы для того, чтобы пользователи могли писать
методы, которые различаются на основе этих типов.

Иерархические отношения между спецификаторами типов зеркально отражены на
отношения между классами, соответствующим данным типам.
Существующая иерархия типов используется для установки списков приоритетности
классов для каждого класса, соответствующего Common Lisp'овому типу.

В таблице~\ref{CLOS-PRECEDENCE-TABLE} перечислены все классы, которые имеют
соответствующие спецификаторы типов. Суперклассы для каждого такого класса
представлены в порядке от наиболее близкого к наиболее дальнему, или просто в
порядке приоритетности. По этой таблице может быть составлен локальный
список приоритетности классов для каждого 
такого класса, который соответствует типу.

Отдельные реализации могут расширять этот список добавляя другие спецификаторы
типов и соответствующие классы.
Отдельные реализации могут расширять список приоритетности классов при условии,
что не нарушится иерархия отношений типов и дизъюнкция, описанная в
разделе~\ref{DATA-TYPE-RELATIONSHIPS}.
Стандартный класс, определённый без прямых суперклассов, гарантированно не
пересекается с другими классами в таблице, за исключением класса с именем
\cdf{t}. FIXME

[At this point the original CLOS report specified that certain Common Lisp
types were to appear in table~\ref{CLOS-PRECEDENCE-TABLE} if and only if
X3J13 voted to make them disjoint from
\cdf{cons}, \cdf{symbol}, \cdf{array}, \cdf{number}, and \cdf{character}.
X3J13 voted to do so in June 1988
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}.  I have added these types
and their class precedence lists to the table; the new types are indicated
by asterisks.---GLS]

\begin{table}[t]
\caption{Родительские классы для отображения Common Lisp'овых типов}
\label{CLOS-PRECEDENCE-TABLE}
\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\textrm{Common Lisp'овый тип}&\textrm{Список приоритетности классов для
  соответствующего типа/класса} \\
\hlinesp
array&(array t)\\
bit-vector&(bit-vector vector array sequence t)\\
character&(character t)\\
complex&(complex number t)\\
cons&(cons list sequence t)\\
float&(float number t)\\
function \textrm{*}&(function t) \\
hash-table \textrm{*}&(hash-table t) \\
integer&(integer rational number t)\\
list&(list sequence t)\\
null&(null symbol list sequence t)\\
number&(number t)\\
package \textrm{*}&(package t) \\
pathname \textrm{*}&(pathname t) \\
random-state \textrm{*}&(random-state t) \\
ratio&(ratio rational number t)\\
rational&(rational number t)\\
readtable \textrm{*}&(readtable t) \\
sequence&(sequence t)\\
stream \textrm{*}&(stream t) \\
string&(string vector array sequence t)\\
symbol&(symbol t)\\
t&(t)\\
vector&(vector array sequence t)
\end{tabular}
\end{flushleft}
[An asterisk indicates a type added to this table as a consequence
of a portion of the CLOS specification that was conditional on X3J13 voting
to make that type disjoint from certain other built-in types
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}.---GLS]
\end{table}

\subsection{Определение списка приоритетности классов}
\label{Determining-the-Class-Precedence-List-SECTION}

Форма \cdf{defclass} содержит список упорядоченных прямых суперклассов для
задаваемого класса. Этот список называется \emph{локальным списком 
приоритетности  классов}. Это отсортированный список из класса и его прямых 
суперклассов. \emph{Список приоритетности классов} для класса \emph{C} является
упорядоченным списком из класса \emph{C} и всех его суперклассов, который
согласуется с локальными списками для \emph{C} и его суперклассов.

Класс имеет приоритет перед его прямыми суперклассами, и прямой суперкласс стоит
перед всеми другими прямыми суперклассами указанными правее в форме
\cdf{defclass}.
Для любого класса \emph{C},
истинно определение
$$R_C=\{(C,C_1),(C_1,C_2),\ldots,(C_{n-1},C_{n})\}$$
, где $C_1,\ldots,C_{n}$ --- прямые суперклассы для \emph{C} в порядке, в
котором они перечислены в форме \cdf{defclass}. Данные упорядоченные пары
образуют упорядоченный список из класса \emph{C} и его прямых суперклассов.

Пусть $S_C$ является множеством из \emph{C} и его суперклассов. Пусть \emph{R}
является 
$$R=\bigcup_{\textstyle c\in {S_{C}}} R_{c}$$

Множество \emph{R} может образовывать или не образовывать частичное
упорядочение, в зависимости от того, согласованы ли $R_{c}$, $c\in
S_{C}$. Предполагается, что они согласованы, и что \emph{R} образовывает
частичное упорядочение. Когда $R_{c}$ не согласовано, говориться, что \emph{R}
несогласовано. FIXME 

Для вычисления списка приоритетности классов для класса \emph{C}, необходимо
топологически отсортировать элементы множества $S_{C}$ по отношению к частичному
упорядочению, созданному с помощью \emph{R}. Когда топологическая сортировка
должна выбрать класс из множества из двух или более классов, и в соответствие с
множеством \emph{R} ни один не приоритетнее другого , класс
выбирается детерминированно так, как описано ниже.
Если множество \emph{R} не согласовано, сигнализируется ошибка.

\subsubsection{Топологическая сортировка}

\href{http://ru.wikipedia.org/wiki/Топологическая_сортировка}{Топологическая
  сортировка}

Топологическая сортировка осуществляет поиск такого класса \emph{C} в $S_{c}$,
если в соответствии с элементами \emph{R} никакой другой класс не предшествует
данному. Класс \emph{C} размещается в самом начале результирующего
списка. Удаляется \emph{C} из $C_{c}$ и удаляются все пары вида $(C,D)$,
$D\in S_{C}$ из \emph{R}. Процесс повторяется, в конец результирующего списка
добавляются классы без предшествующих классов. Остановка происходит,
когда элементов, у которых нет предшествующих элементов, больше не осталось.

Если множество $S_{C}$ не пустое и процесс сортировка завершился, множество
\emph{R} является несолгасованным. Если каждый класс в конечном множестве
классов имеет предшествующие классы, тогда \emph{R} содержит циклическую
структуру. Это значит, что существует такая цепочка классов $C_1,\ldots,C_{n}$,
что $C_{i}$ имеет предшествующий $C_{i+1}$, $1\leq i<n$, и $C_{n}$ предшествует
$C_1$.

Иногда случается так, что в $S_{C}$ есть несколько классов без предшественников.
В этом случае выбирается один, который имеет прямой подкласс, стоящий наиболее
правее в вычисленном списке предшествующих классов.
Если такого класса нет, \emph{R} не образовывает частичное упорядочение ---
$R_{c}$, $c\in S_{C}$ не согласованы.

Более подробно, пусть $\{N_1,\ldots,N_{m}\}$,
$m\geq 2$ будут классами из $S_{C}$ без предшественников. Пусть $(C_1\ldots C_{n})$, $n\geq
1$, будут вычисленным списком приоритетности классов. $C_1$ --- наиболее
специфичный класс, и $C_n$ --- наименее специфичный. Пусть $1\leq j\leq n$ будет
наибольшим числом таким, что существует \emph{i}, где $1\leq i\leq m$ и $N_{i}$
является прямым суперклассом $C_{j}$, $N_{i}$ находится рядом.

Результат этого правила выбора из множества класса без предшественников
заключается в том, что классы в простой цепочке суперклассов являются смежными в
списке приоритетности классов, и эти классы в каждом относительно раздельном
подграфе являются смежными в списке приоритетности классов. Например, пусть
$T_1$ и $T_2$ будут подграфами, у которого общим элементом является только
\emph{J}. Предположим, что для \emph{J} не ни одного суперкласса ни в $T_1$, ни
в $T_2$. Пусть $C_1$ будет нижней частью $T_1$ и $C_2$ --- нижней частью
$T_2$. Предположим \emph{C} является классом, у которого прямые суперклассы
$C_1$ и $C_2$ вот в этом порядке. Тогда список приоритетности класса для
\emph{C} будет начинаться с \emph{C} и продолжаться всеми классами из $T_1$ за
исключением \emph{J}. Следующими будут классы из $T_2$. Класс \emph{J} и его
суперклассы будут последними.

\subsubsection{Примеры}

Данный пример устанавливает список родительских классов для класса
\cdf{pie}. Классы определены следующим образом:

\begin{lisp}
(defclass pie (apple cinnamon) ()) \\*
(defclass apple (fruit) ()) \\*
(defclass cinnamon (spice) ()) \\
(defclass fruit (food) ()) \\
(defclass spice (food) ()) \\*
(defclass food () ())
\end{lisp}

\begin{flushleft}

Множество
S=\{\cdf{pie},
\cdf{apple},
\cdf{cinnamon},
\cdf{fruit},
\cdf{spice},
\cdf{food},
\cdf{standard-object},
\cdf{t}\}.
Множество
R=\{(\cdf{pie},
\cdf{apple}),
(\cdf{apple},
\cdf{cinnamon}),
(\cdf{cinnamon},
\cdf{standard-object}),
(\cdf{apple},
\cdf{fruit}),
(\cdf{fruit},
\cdf{standard-object}),
(\cdf{cinnamon},
\cdf{spice}),
(\cdf{spice},
\cdf{standard-object}),
(\cdf{fruit},
\cdf{food}),
(\cdf{food},
\cdf{standard-object}),
(\cdf{spice},
\cdf{food}),
(\cdf{standard-object},
\cdf{t})\}.

Класс \cdf{pie} не имеет предшественников, поэтому он идёт первым. Результат
пока что просто \cd{(pie)}. Происходит удаление \cdf{pie} из \emph{S} и пар,
содержащих \cdf{pie}, из \emph{R}. Получается:
S=\{\cdf{apple},
\cdf{cinnamon},
\cdf{fruit},
\cdf{spice},
\cdf{food},
\cdf{standard-object},
\cdf{t}\} and R=\{
(\cdf{apple},
\cdf{cinnamon}),
(\cdf{cinnamon},
\cdf{standard-object}),
(\cdf{apple},
\cdf{fruit}),
(\cdf{fruit},
\cdf{standard-object}),
(\cdf{cinnamon},
\cdf{spice}),
(\cdf{spice},
\cdf{standard-object}),
(\cdf{fruit},
\cdf{food}),
(\cdf{food},
\cdf{standard-object}),
(\cdf{spice},
\cdf{food}),
(\cdf{standard-object},
\cdf{t})\}.

Класс \cdf{apple} не имеет предшественников, поэтому он следующий. Результат
теперь \cd{(pie~apple)}. Происходит удаление \cdf{apple} из \emph{S} и пар,
содержащих \cdf{pie}, из \emph{R}. Получается:
S=\{\cdf{cinnamon},
\cdf{fruit},
\cdf{spice},
\cdf{food},
\cdf{standard-object},
\cdf{t}\} and R=\{(\cdf{cinnamon},
\cdf{standard-object}),
(\cdf{fruit},
\cdf{standard-object}),
(\cdf{cinnamon},
\cdf{spice}),
(\cdf{spice},
\cdf{standard-object}),
(\cdf{fruit},
\cdf{food}),
(\cdf{food},
\cdf{standard-object}),
(\cdf{spice},
\cdf{food}),
(\cdf{standard-object},
\cdf{t})\}.

Классы \cdf{cinnamon} и \cdf{fruit} не имеют предшественников, поэтому следующим
будет тот, у которого прямые подклассы в вычисленном списке приоритетности
классов стоят правее. Класс \cdf{apple} прямой подкласс \cdf{fruit}, и класс
\cdf{pie} прямой подкласс \cdf{cinnamon}. Так как \cdf{apple} стоит правее чем
\cdf{pie} в списке приоритетности, следующим становиться \cdf{fruit} и
результат выглядит \cd{(pie apple fruit)}. 
S=\{\cdf{cinnamon},
\cdf{spice},
\cdf{food},
\cdf{standard-object},
\cdf{t}\}; R=\{(\cdf{cinnamon},
\cdf{standard-object}),
(\cdf{cinnamon},
\cdf{spice}),
(\cdf{spice},
\cdf{standard-object}),
(\cdf{food},
\cdf{standard-object}),
(\cdf{spice},
\cdf{food}),
(\cdf{standard-object},
\cdf{t})\}.

Класс \cdf{cinnamon} следующий, и результат получается \cd{(pie apple fruit
  cinnamon)}. В данный момент:
 S=\{\cdf{spice},
\cdf{food},
\cdf{standard-object},
\cdf{t}\}; R=\{(\cdf{spice},
\cdf{standard-object}),
(\cdf{food},
\cdf{standard-object}),
(\cdf{spice},
\cdf{food}),
(\cdf{standard-object},
\cdf{t})\}.
\end{flushleft}

Затем добавляются классы \cdf{spice}, \cdf{food}, \cdf{standard-object} и
\cdf{t} в таком же порядке. Результат списка приоритетности классов для
\cdf{pie} является
\begin{lisp}
(pie apple fruit cinnamon spice food standard-object t)
\end{lisp}

Можно записать множество определений классов, которые не могут быть
упорядочены. Например:
\begin{lisp}
(defclass new-class (fruit apple) ()) \\
(defclass apple (fruit) ())
\end{lisp}

Класс \cdf{fruit} должен быть приоритетнее \cdf{apple}, так как должен быть
сохранён локальный порядок приоритетности суперклассов. Класс \cdf{apple}
должен быть приоритетным \cdf{fruit}, так как класс всегда стоит перед его
суперклассами. При возникновении данной ситуации при вычислении списка
приоритетности классов, сигнализируется ошибка.

Следующий набор определений классов может показаться противоречивым:
\begin{lisp}
(defclass pie (apple cinnamon) ()) \\
(defclass pastry (cinnamon apple) ()) \\
(defclass apple () ()) \\
(defclass cinnamon () ())
\end{lisp}

Список приоритетности классов для \cdf{pie}
\begin{lisp}
(pie apple cinnamon standard-object t)
\end{lisp}

Список приоритетности классов для \cdf{pastry}
\begin{lisp}
(pastry cinnamon apple standard-object t)
\end{lisp}

В упорядочении суперклассов для \cdf{pie} \cdf{apple} может быть приоритетнее
\cdf{cinnamon}, но в упорядочении \cdf{pastry} это невозможно. Так или
иначе, создать новый класс, у которого два суперкласса \cdf{pie} и \cdf{pastry},
невозможно.

\subsection{Обобщённые функции и методы}

\emph{Обобщённая функция} --- это функция, поведение которой зависит от
передаваемых аргументов. \emph{Методы} определяют поведение и операции этой функции для
конкретных классов аргументов. Следующий раздел описывает обобщённые функции и методы.

\subsubsection{Введение в обобщённые функции}

Объект обобщённой функции содержит множество методов, лямбда-список, тип
сочетания методов и другую информацию.

Как и обычная Lisp'овая функция, обобщённая функция принимает аргументы,
выполняет последовательность операций, и, возможно, возвращает полезные значения.
Обычная функция имеет одно тело с кодом, которое выполняется во всех случаях
вызова функции. Обобщённая функция имеет множество тел с кодом, и при вызове для
исполнения из данного множества выделяется подмножество. Выбранное подмножество
и порядок этих тел устанавливается с помощью класса(ов) одного или
нескольких переданных аргументов и типа сочетания методов.

Синтаксис вызова обычной и обобщённой функции одинаков.

Обобщённые функции являются обычными функциями. Их можно передать в
качестве аргументов, вернуть в качестве результата, и использовать первым
аргументом в \cdf{funcall} и \cdf{apply}, и вообще везде, где можно использовать
обычные функции.

Макрос \cdf{generic-function} создаёт анонимную обобщённую функцию со множеством
методов, указанных в форме \cdf{generic-function}.

При вычислении формы \cdf{defgeneric} происходит одно из трёх действий:

\begin{itemize}
\item Если обобщённая функция с данным именем уже существует, тогда
  модифицируется её объект. Методы указанные в новой форме \cdf{defgeneric}
  добавляются, а методы созданные ранее с помощью старой формы \cdf{defgeneric}
  удаляются. Методы добавленные из новой формы \cdf{defgeneric} могут заменять
  методы определённые с помощью \cdf{defmethod} или \cdf{defclass}. Другие
  методы для данной обобщённой функции не меняются и не удаляются.

\item Если данное имя определяет необобщённую функцию, макрос или специальный
  оператор, тогда сигнализируется ошибка.

\item В противном случае создаётся обобщённая функция с методами указанными в
  данной форме \cdf{defgeneric}.
\end{itemize}

Некоторые формы содержат параметры обобщённой функции, такие как тип сочетания
методов или порядок приоритета аргументов. Они будут называться, как <<формы,
которые указывают параметры обобщённой функции>>. Это формы: \cdf{defgeneric},
\cdf{generic-function}.

Некоторые формы определяют методы для обобщённой функции. Они называются <<формы
определяющие методы>>. Это формы: \cdf{defgeneric}, \cdf{defmethod},
\cdf{generic-function} и \cdf{defclass}. Следует отметить, что все эти формы за
исключением \cdf{defclass} и \cdf{defmethod} также определяют параметры
обобщённой функции.

\subsubsection{Введение в методы}
\label{Introduction-to-Methods-SECTION}

Объект метода содержит функцию метода, последовательность \emph{специализаторов
  параметров}, который указывают для чего применим данный метод, лямбда-список и
последовательность \emph{квалификаторов}, которые используются для функциональности
сочетания методов.

Объект метода не является функцией и не может быть вызван как функция. Различные
механизмы в OS принимают объект метода и вызывают функцию этого метода, как в
случае вызова обобщённой функции. В этом случае говорится, что метод вызывается.

Форма, определяющая метод, содержит код, который будет выполнен, когда аргументы
обобщённой функции такие, что должен быть вызван данный метод. Когда такая форма
вычисляется, создаётся объект метода и происходит одно из четырёх действий:

\begin{itemize}
\item Если обобщённая функция с данным именем уже существует и если объект
  метода уже существует, и этот объект согласуется с новым в специализаторах
  параметров и квалификаторах, существующий объект обобщённой функции
  модифицируется и будет содержать новый объект метода. Для определения того,
  как методы согласуются между собой в специализаторах параметров и
  квалификаторах смотрите
  раздел~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}.

\item Если обобщённая функция с данным именем уже существует и если не
  существует объекта метода, согласующегося с новым в специализаторах
  параметров и квалификаторах, существующий объект обобщённой функции
  модифицируется и будет содержать новый объект метода.
\item Если данное имя указывает на необобщённую функцию, макрос или специальный
  оператор, сигнализируется ошибка.

\item В противном случае создаётся обобщённая функция с методами указанными в
  форме.
\end{itemize}

Если лямбда-список нового метода не соответствует лямбда-списку обобщённой
функции, сигнализируется ошибка. Если форма, определяющая метод и которая не
может задавать параметры обобщённой функции, создаёт новую обобщённую функцию,
лямбда-список для этой обобщённой функции будет производным от и согласованным с
лямбда-списком формы, которая определила метод. Для детального описания
\emph{согласованности}, смотрите
раздел~\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}.

Каждый метод имеет \emph{специализированный лямбда-список}, который
устанавливает, в каких случаях данный метод может быть
применён. Специализированный лямбда-список похож на обычный, однако содержит
\emph{специализированные параметры}, которые могут быть использованы на месте
обычных обязательных параметров. Специализированный параметр является списком
\cd{\emph{(variable-name parameter-specializer-name)}}, где
\emph{parameter-specializer-name} является или именем класса, или списком
\cd{(\cdf{eql} \emph{form})}.
Имя специализатора параметра означает следующее:

\begin{itemize}
\item Имя, которое указывает на класс означает класс.

\item Список \cd{(\cdf{eql} \emph{form})} обозначает спецификатор типа
  \cd{(\cdf{eql} \emph{object})}, где объект т\emph{object} является результатом
  вычисления формы \emph{form}. Форма \emph{form} вычисляется в лексическом
  окружении, в котором вычислялась форма, определяющая метод. Следует отметить,
  что форма \emph{form} вычисляется только единожды во время определения метода,
  а не каждый раз при вызове обобщённой функции.
\end{itemize}

Имена специализаторов параметров используются в макросах, предназначенных для
пользовательского интерфейса (\cdf{defmethod}), тогда как специализаторы
параметров используются в функциональном интерфейсе.

[It is very important to understand clearly the distinction made
in the preceding paragraph.  A parameter specializer name
has the form of a type specifier but is semantically quite different
from a type specifier: a parameter specializer name of the form
\cd{(\cdf{eql} \emph{form})} is not a type specifier, for it contains
a \emph{form} to be evaluated.   Type specifiers
never contain forms to be evaluated.  All parameter specializers
(as opposed to parameter specializer names) are valid type specifiers,
but not all type specifiers are valid parameter specializers.  Macros such as \cdf{defmethod}
take parameter specializer names and treat them as specifications for
constructing certain type specifiers (parameter specializers) that may then be used
with such functions as \cdf{find-method}.---GLS]

Только обязательные параметры могут быть специализированы, и наоборот
специализатор параметра может быть только для обязательного параметра. Для
упрощения записи, если некоторый обязательный параметр в специализированном
лямбда-списке в форме, определяющей метод, является просто именем переменной, то
специализатор параметра по-умолчанию указывает на класс с именем \cdf{t}.

В рамках заданной обобщённой функции и списка аргументов, \emph{применимый
  метод} --- это метод для данной функции, у которого специализаторы параметров
удовлетворяют соответствующим аргументам. Следующее определение разъясняет, что
имеется ввиду под применимым методом и под аргументом, удовлетворяющим
специализатору параметра.

Пусть $\langle A_1, \ldots, A_{n}\rangle$ будут обязательными аргументами
обобщённой функции. Пусть $\langle P_1, \ldots, P_{n}\rangle$ будут
специализаторами параметров, соответствующие обязательным параметрам метода
\emph{M}. Метод \emph{M} является \emph{применимым}, когда $A_{i}$
\emph{удовлетворяет} $P_{i}$. Если $P_{i}$ является классом, и если $A_{i}$
является экземпляром класса \emph{C}, тогда говорится, что $A_{i}$
\emph{удовлетворяет} $P_{i}$, когда $C=P_{i}$ или когда \emph{C} является
подклассом $P_{i}$. Если $P_{i}$ является формой \cd{(\cdf{eql} \emph{object})},
тогда говорится, что $A_{i}$ \emph{удовлетворяет} $P_{i}$, когда функция
\cdf{eql} применённая к $A_{i}$ и \emph{object} истинна.

Так как специализатор параметра является спецификатором типа, во время выбора
метода для определения того, удовлетворяют ли аргумента спецификатору параметра
может использоваться функция \cdf{typep}. Специализатор параметра не может быть
списком спецификатора типа, таким как \cd{(\cd{vector
    single-float})}. Специализатор параметра может быть только таким списком как
\cd{(\cdf{eql} \emph{object})}. Common Lisp определяет спецификатор типа
\cdf{eql}, как если бы было выполнено следующее выражение:

\begin{lisp}
(deftype eql (\emph{object}) {\Xbq}(member ,\emph{object}))
\end{lisp}
[Смотрите раздел ~\ref{PREDICATING-TYPE-SPECIFIERS-SECTION}.---GLS]

Метод, у которого все специализаторы параметров являются классами \cdf{t},
называется \emph{метод по-умолчанию}. Такое метод применим всегда, но может быть
скрыт с помощью более специализированного метода.

Методы могут иметь \emph{квалификаторы}, которые указывают процедуре сочетания
методов способ вызова методов. Метод, который имеет один или более
квалификатор, называется \emph{квалифицированным} методом.
Метод без квалификаторов называется \emph{неквалифицированным методом}.
Квалификатором является любой объект, кроме списка, т.е. любой не-\cdf{nil}
атом. Квалификаторы, определённые с помощью стандартного сочетания методов и
системного типа сочетания методов, являются символами. 

В данной спецификации, термины \emph{главный метод} и \emph{вспомогательный
  метод} используются для разделения методов по типу сочетания. В стандартном
типе сочетания методов, главные методы это неквалифицированные методы, и
вспомогательные методы это методы с одним из квалификаторов \cd{:around},
\cd{:before} или \cd{:after}. Когда определяется тип сочетания методов с помощью
краткой формы \cdf{define-method-combination}, главные методы это те, которые
квалифицированы с помощью имени сочетания методов, и вспомогательные методы имеют
квалификатор \cd{:around}. Таким образом определение терминов \emph{главный метод} и
\emph{вспомогательный метод} имеет значение относительно текущего типу сочетания
методов.

\subsubsection{Согласованность в специализаторах параметров и квалификаторах}
\label{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}

Два метода согласованы друг с другом в специализаторах параметров и
квалификаторах, если выполняются следующие условия:

\begin{itemize}
\item Оба метода имеют одинаковое количество обязательных
  параметров.

Предположим, что специализаторы параметров двух методов являются 
$P\sub{1,1}\ldots P\sub{1,n}$
и $P\sub{2,1}\ldots P\sub{2,n}$ соответственно.

\item Для каждого $1\leq i\leq n$, $P\sub{1,i}$ согласуется с $P\sub{2,i}$.
Специализатор параметра $P\sub{1,i}$ согласуется с $P\sub{2,i}$, если
$P\sub{1,i}$ и $P\sub{2,i}$ являются одним и тем же классом или если
$P\sub{1,i}=(\cdf{eql} object_1)$, 
$P\sub{2,i}=(\cdf{eql} object_2)$, и
\cd{(\cdf{eql} $object_1$ $object_2$)}.
В противном случае $P\sub{1,i}$ и $P\sub{2,i}$ несогласованны.
\end{itemize}

\subsubsection{Гармония лямбда-списков для всех методов обобщённой функции}
\label{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}

Следующие правила определяют гармонию множества лямбда-списков, включая
лямбда-списки каждого метода некоторой обобщённой функции и лямбда-список
определённый для самой этой функции, если он, конечно, был указан.
\begin{itemize}

\item Каждый лямбда-список должен содержать одинаковое количество обязательных
  параметров.

\item Каждый лямбда-список должен иметь одинаковое количество необязательных
  параметров. Каждый метод может определять свои значения по-умолчанию для
  необязательных параметров.

\item Если какой-либо лямбда-список содержит \cd{\&rest} или \cd{\&key}, каждый
  лямбда-список должен содержать один или оба этих символа.

\item Если лямбда-список обобщённой функции содержит \cd{\&key}, каждый метод
  должен принимать все именованные параметры указанные в обобщённой функции или
  явно, или с помощью \cd{\&allow-other-keys}, или с помощью указания
  \cd{\&rest}, но не \cd{\&key}.
  Каждый метод может принимать свои дополнительные именованные параметры.
  Проверка на корректность именованный параметров производится в обобщённой
  функции, а не в каждом методе. Метод вызывается так, как если указан
  именованный аргумент \cd{:allow-other-keys} со значением \cd{t}, однако сам
  этот аргумент не указывается.

\item Использование \cd{\&allow-other-keys} не обязательно согласовывать между
  лямбда-списками. Если \cd{\&allow-other-keys} содержится в лямбда-списке
  какого-либо применимого метода или обобщённой функции, в вызове обобщённой
  функции может использоваться любые именованные параметры.

\item Использования \cd{\&aux} не обязательно согласовывать между методами.
\end{itemize}

Если форма, которая определяет метод и не может указывать параметры обобщённой
функции, создаёт обобщённую функцию, и если лямбда-список для метода содержит
именованные параметры, тогда лямбда-список обобщённой функции будет содержать
символ \cd{\&key} (но сами параметры содержать не будет).

\subsubsection{Именованные параметры в обобщённых функциях и методах}

Когда обобщённая функция или любой из её методов содержат в своих лямбда-списках
\cd{\&key}, определённый набор именованный параметров, принятых обобщённой
функцией, меняется в зависимости от применяемых методов. Набор именованных
параметров, принимаемых обобщённой функцией для отдельного вызова, является
объединением всех именованных параметров, принимаемых всеми применимыми
методами, и именованных параметров, указанных после \cd{\&key} в определении
обобщённой функции. Метод, который содержит \cd{\&rest}, но не содержит
\cd{\&key}, не попадает в список применимых методов. Если лямбда-список любого
применимого метода или обобщённой функции содержит \cd{\&allow-other-keys},
обобщённая функция принимает все именованные параметры.

Правила согласования лямбда-списков требуют, чтобы каждый метод принимал все
именованные параметры, указанные после \cd{\&key} в определении обобщённой
функции, причём делал это явно указанием \cd{\&allow-other-keys} или указанием
\cd{\&rest}, но не \cd{\&key}. Каждый метод может принимать свои дополнительные
именованные параметры в дополнение к тем, которые были в определении обобщённой
функции.

Если в обобщённую функцию передан именованный параметр такой, что применимого
метода найдено не было, генерируется ошибка.

Например, определим два метода для \cdf{width}.

\begin{lisp}
(defmethod width ((c character-class) \&key font) ...)\\*
\\*
(defmethod width ((p picture-class) \&key pixel-size) ...)
\end{lisp}

Предположим, что больше методов нет, и определения обобщённой функции для
\cdf{width} тоже нет. Вычисление следующей формы сигнализирует ошибку, потому
что именованный параметр \cd{:pixel-size} не может быть передан в применяемый
метод.

\begin{lisp}
(width (make-instance 'character-class :char \#{\Xbackslash}Q) \\*
~~~~~~~:font 'baskerville :pixel-size 10)
\end{lisp}

Вычисление следующей формы сигнализирует ошибку.

\begin{lisp}
(width (make-instance 'picture-class :glyph (glyph \#{\Xbackslash}Q)) \\*
~~~~~~~:font 'baskerville :pixel-size 10)
\end{lisp}

Вычисление следующей формы не сигнализирует ошибку, если класс
\cdf{character-picture-class} является подклассом и \cdf{picture-class} и \cdf{character-class}.

\begin{lisp}
(width (make-instance 'character-picture-class :char \#{\Xbackslash}Q) \\*
~~~~~~~:font 'baskerville :pixel-size 10)
\end{lisp}

\subsection{Выбор и сочетание методов}
\label{Method-Selection-and-Combination-SECTION}

Когда общая функция вызывается с конкретными аргументами, она должна
определить какой код выполнять. Этот код называется \emph{действующий (рабочий)
  метод} для этих аргументов. Действующий метод является \emph{сочетанием}
применимых методов в обобщённой функции.
Сочетание методов --- это Lisp'овое выражение, которые содержит вызовы к
некоторым или всем методам. Если обобщённая функция вызвана и при этом методов
для применения найдено не было, вызывается обобщённая функция \cdf{no-applicable-method}.

Когда установлен действующий метод, он вызывает с теми же аргументами, что были
переданы в обобщённую функцию. Все значения возвращённые этим методом,
возвращаются из обобщённой функции.

\subsubsection{Определение действующего метода}
\label{Determining-the-Effective-Method-SECTION}

Действующий метод для набора аргументов устанавливается следующими тремя шагами:

\begin{enumerate}

\item Выбор применимых методов.

\item Сортировка применимых методов в порядке приоритетности, размещение первым наиболее
  специфичного метода.

\item Применение процедуры сочетания методов к сортированному списку применимых
  методов, создание действующего метода.

\end{enumerate}

\textbf{Выбор применимых методов}
Этот шаг описан в разделе~\ref{Introduction-to-Methods-SECTION}.

\textbf{Сортировка применимых методов в порядке приоритетности.}
Для сравнения того, кто из двух методов приоритетнее, по порядку
исследуются их специализаторы параметров. По-умолчанию порядок исследования
слева направо, но в параметре \cd{:argument-precedence-order} в функции
\cdf{defgeneric} или в любой другой форме, задающей параметры обобщённой
функции, можно изменить этот порядок.

Из каждого метода сравниваются специализаторы параметров. Когда пара
специализаторов параметров эквивалентна, сравнивается следующая пара. Если все
соответствующие пары эквивалентны, два метода должны иметь разные
квалификаторы. В этом случае один из двух методов может быть приоритетнее другого.

Если соответствующие специализаторы параметров не эквивалентны, первая же
неэквивалентная пара определяет порядок следования методов. Если оба
специализатора параметра являются классами, наиболее специфичным является тот
метод, у которого в данном специализаторе указан класс, который приоритетнее
класса, указанному в другом специализаторе. А так как до этого из всех методов
были выбраны только применимые, эти два класса гарантированно находятся в одном
списке приоритетности классов.

Если один из специализаторов выглядит \cd{(\cdf{eql} \emph{object})}, то его
содержащий метод будет приоритетнее другого метода. Если оба специализатора
являются формами \cdf{eql}, то они должны быть одинаковыми (иначе два метода не
могли бы быть применимыми к этому аргументу).

Результирующий список применимых методов первым содержит наиболее специфичный
метод, и последним наименее специфичный.

\textbf{Применение процедуры сочетания методов к отсортированному списке
  применимых методов.}

В простейшем случае --- если используется стандартное сочетание методов и все
применимые методы являются главными --- рабочим методом является наиболее
специфичный метод. Этот метод, используя функцию \cdf{call-next-method}, может
вызвать следующий наиболее специфичный метод. Метод, который будет вызван
функцией \cdf{call-next-method}, называется следующим методом. Предикат
\cdf{next-method-p} проверяет существование следующего метода. Если
вызывается \cdf{call-next-method}, а следующего метода нет, тогда вызывается
обобщённая функция \cdf{no-next-method}.

В общем случае, рабочий метод --- это некоторое сочетание применимых
методов. Она определяется Lisp'овой формой, которая содержит вызовы к некоторым
или всем применимым методам, и возвращает значение(я), которые будут возвращены
из обобщённой функции, и опционально делает доступными через
\cdf{call-next-method} некоторые методы. Эта Lisp'овая форма является телом
рабочего метода. Она расширяется соответствующим лямбда-списком для создания из
него функции.

Роль каждого метода в рабочем методе устанавливается с помощью его
квалификаторов и специфичности. Квалификатор
служит для обозначения метода, и смысл квалификатора
определяется таким образом, что это обозначение используется этим шагом
процедуры. Если применимый метод имеет непризнанный квалификатор, этот шаг
сигнализирует ошибку и не включает этот метод в рабочий.

Когда используется стандартный тип сочетания методов и используются
квалифицированные методы, рабочий метод составляется так, как описано в
разделе~\ref{Standard-Method-Combination-SECTION}.

Другой тип сочетания методов может быть указан с помощью параметра 
\cd{:method-combination} функции \cdf{defgeneric} или любой другой формы,
определяющей параметры обобщённой функции. В таком случае данный шаг процедуры
может быть изменён.

Новые типы сочетания методов могут быть определены с помощью макроса
\cdf{define-method-combination}.

Уровень метаобъектов также содержит механизм для определения новых типов
сочетаний методов. Обобщённая функция \cdf{compute-effective-method} принимает
в качестве аргументов: обобщённую функцию, объект сочетания методов, и
отсортированный список применимых методов. Она возвращает Lisp'овую форму,
которая определяет рабочий метод.
Метод для \cdf{compute-effective-method} может быть определён напрямую с
использованием \cdf{defmethod} или не напрямую с использованием
\cdf{define-method-combination}.
\emph{Объект сочетания методов} --- это объект, который инкапсулирует тип
сочетания методов и параметры указанные в параметре \cd{:method-combination} в
формах, которые указывают параметры для обобщённых функций.

\beforenoterule
\begin{implementation}

В простейших реализациях, обобщённые функции будут вычислять рабочий метод при
каждом вызове. На практике это будет неэффективной стратегией. Вместо этого эти
реализации могут использовать ряд оптимизация данных шагов. Некоторые примеры
таких оптимизаций:

\begin{itemize}

\item Использование хеш-таблицы с ключами: классами аргументов, для сохранения
  рабочих методов.

\item Компиляция рабочего метода и сохранения результирующей функции в таблице.

\item Распознавание Lisp'овой формы, как экземпляра шаблона управляющей
  структуры и замещение на замыкание, которое реализует эту структуру.

\item Исследование специализаторов параметров всех методов для обобщённой
  функции и перечисление всех возможных рабочих методов. Сочетание рабочих
  методов вместе с кодом для выбора среди них в одну функцию, и компиляция этой
  функции. Вызов этой функции всегда, когда вызывается обобщённая функция.
\end{itemize}
\end{implementation}
\afternoterule

\subsubsection{Стандартное сочетание методов}
\label{Standard-Method-Combination-SECTION}

Стандартное сочетание методов поддерживается классом
\cdf{standard-generic-function}.
Оно используется, если не указаны другие типы сочетаний методов или если
указан встроенный \cdf{standard} тип сочетания методов.

\emph{Главные методы} определяют главное действие рабочего метода, тогда как
\emph{вспомогательные методы} изменяют это действие одним из трёх способов. 
Главные методы не имеют квалификаторов.

Вспомогательный метод --- это метод, у которого квалификатор является
\cd{:before}, \cd{:after} или \cd{:around}. Стандартное сочетание методов
позволяет использовать максимум один квалификатор для метода, в случае
использования более одного квалификатора, сигнализируется ошибка.

\begin{itemize}

\item 
Квалификатор \cd{:before} метода задаётся ключевым символом
\cd{:before}. \cd{:before} метод запускается перед любым главным методом.

\item 
Квалификатор \cd{:after} метода задаётся ключевым символом
\cd{:after}. \cd{:after} метод запускается после главных методов.

\item 
Квалификатор \cd{:around} метода задаётся ключевым символом
\cd{:around}. \cd{:around} метод запускается вместо других применимых методов,
но также возможно запустить некоторые из них.
\end{itemize}

Семантика стандартного сочетания методов:

\begin{figure}
\caption{Common Lisp Standard Method Invocation by Rainer Joswig}
\label{METHOD-COMBINATION-GRAPHIC}
\igraphics{clos1}
\small\noindent
\end{figure}


\begin{itemize}

\item Если присутствуют какие-либо \cd{:around} методы, из них вызывается
  наиболее специфичный. Данный метод возвращает значение(я), которые
  возвращаются из обобщённой функции.

\item Внутри тела \cd{:around} метода для вызова следующего метода может
  использоваться функция \cdf{call-next-method}. Когда следующий метод
  возвращает управление, \cd{:around} метод может продолжить своё выполнение, в
  том числе на основании возвращённых значений. В случае использования
  \cdf{call-next-method} и отсутствия следующего метода, вызывается обобщённая
  функция \cdf{no-next-method}. Для определения существует ли следующий метод
  может использоваться функция \cdf{next-method-p}.

\item Если \cd{:around} метод вызывает \cdf{call-next-method}, то вызывается
  следующий наиболее специфичный \cdf{:around} применимый метод. Если
  \cd{:around} методов нет, или если \cdf{call-next-method} была вызвана в
  последнем \cd{:around} методе, то следующие методы вызываются так, как описано
  ниже:

\begin{itemize}

\item Вызывается все \cd{:before} методы по порядку от наиболее специфичного к
  наименее. Их значения игнорируются. Если \cdf{call-next-method} используется в
  \cd{:before} методе, сигнализируется ошибка.

\item Вызывается наиболее специфичный главный метод. Внутри тела главного метода
  для вызова следующего специфичного главного может использоваться
  \cdf{call-next-method}. Когда этот метод возвращает управление, предыдущий
  главный метод может продолжить выполнение некоторого кода, возможно
  основываясь на результате вызванного метода. Если была вызвана
  \cdf{call-next-method}, а применимых главных методов больше нет, вызывается
  обобщённая функция \cdf{no-next-method}. Для проверки существует ли следующий
  метод может использоваться \cdf{next-method-p}. Если функция
  \cdf{call-next-method} не использовалась, вызван будет только один наиболее
  специфичный главный метод.

\item Вызываются все \cd{:after} методы в порядке от наименее к
  наиболее специфичному. Их значения игнорируются. Если \cdf{call-next-method}
  используется в \cd{:after} методе, сигнализируется ошибка.
\end{itemize}

\item Если \cd{:around} методы не вызывались, из обобщённой функции возвращаются
  значение(я), полученные от наиболее специфичного главного метода. Значение(я)
  полученные от вызова \cd{call-next-method} в наименее специфичном \cd{:around}
  методе являются теми значениями, которые вернул наиболее специфичный метод.
\end{itemize}

В стандартном сочетании методов если есть применимый метод, но он не является
главным, сигнализируется ошибка.

\cd{:before} методы запускаются в порядке от наиболее к наименее специфичному и
\cd{:after} методы запускаются в порядке от наименее к наиболее
специфичному. Обоснование данного механизма может быть показан в следующем
примере.
Предположим класс $C_1$ изменяет поведение своего суперкласса $C_2$ добавлением
\cd{:before} и \cd{:after} методов.  Определено ли поведение класса $C_2$
напрямую методами для $C_2$ или унаследовано от его суперклассов не влияет на
относительные вызовы методов для экземпляра класса $C_1$. \cd{:before} метод
класса $C_1$ вызывается перед всем методами класса $C_2$. \cd{:after} метод
класса $C_1$ вызывается после всех методов класса $C_2$. 

Методы \cd{:around} вызываются перед тем, как будет вызван любой другой
метод. Таким образом наименее специфичный \cd{:around} метод вызывается перед
наиболее специфичным главным методом.

Если используются только главные методы, и не используется
\cdf{call-next-method}, вызываться будет только самый специфичный метод. То есть
наиболее специфичный метод скрывает более общий.

\subsubsection{Декларация сочетания методов}

Макрос \cdf{define-method-combination} определяет новые формы сочетаний
методов. Он предоставляет механизм для изменения создания рабочего
метода. Процедура по-умолчанию создания рабочего метода описана в
разделе~\ref{Determining-the-Effective-Method-SECTION} 
Существует две формы \cdf{define-method-combination}. Краткая форма содержит
простую функциональность. Длинная форма более мощна и подробна. Длинная форма
похожа на \cdf{defmacro} в том, что тело является выражением. которое вычисляет
Lisp'овую форму. Макрос предоставляет механизм для реализации произвольного 
функционала в сочетании методов и для произвольной обработки квалификаторов
методов. Синтаксис и использование обеих форм макроса
\cdf{define-method-combination} описаны в
разделе~\ref{Functions-in-the-Programmer-Interface-SECTION}.

\subsubsection{Системные типы сочетания методов}
\label{Built-in-Method-Combination-Types-SECTION}

CLOS предоставляет множество системных типов сочетания методов. Для того, чтобы
указать, что обобщённая функция использует один из этих типов, необходимо в
параметр \cd{:method-combination} для функции \cdf{defgeneric} или любой другой,
задающей параметры для обобщённой функции, указать имя типа сочетания методов.

Имена системных типов сочетания методов: \cdf{+}, \cdf{and}, \cdf{append},
\cdf{list}, \cdf{max}, \cdf{min}, \cdf{nconc}, \cdf{or}, \cdf{progn} и
\cdf{standard}. 

Семантика системного \cdf{standard} типа сочетания методов было описано в
разделе~\ref{Standard-Method-Combination-SECTION}. Другие системные типы
сочетания методов называются \emph{простыми системными типами сочетания
  методов}.

Простые системные типы сочетания методов работают так, как если бы были
определены в краткой форме \cdf{define-method-combination}. Они предоставляют
для методов две роли:

\begin{itemize}

\item \cd{:around} метод в качестве единственного квалификатора содержит символ
  \cd{:around}. Смысл \cd{:around} методов такой же как и в стандартном типе
  сочетания методов. В \cd{:around} методах поддерживается использование функций
  \cdf{call-next-method} и \cdf{next-method-p}.

\item Главный метод в качестве единственного квалификатора содержит такое же
  имя, что и само название типа сочетания методов. Например, системный тип
  сочетания методов \cd{and} распознаёт методы, у которых единственный
  квалификатор \cd{and}; эти методы являются главными. В главных методах не
  поддерживается использование функций \cdf{call-next-method} и
  \cdf{next-method-p}.

\end{itemize}

Семантика простых системных типов сочетания методов:

\begin{itemize}

\item 
Если существуют \cd{:around} методы, тогда вызывается наиболее специфичный
\cd{:around} метод. То что вернёт данный метод, вернётся и из обобщённой
функции.

\item Внутри тела \cd{:around} метода для вызова следующего метода может
  использоваться функция \cdf{call-next-method}. Если следующего метода при
  использовании этой функции не оказалось, вызывается обобщённая функция
  \cdf{no-next-method}. Для определения существует ли следующий метод можно
  использовать \cdf{next-method-p}. После возврата из следующего метода
  \cd{:around} метод может продолжить выполнения, возможно основываясь на
  полученных значениях.

\item Если \cd{:around} метод использует \cdf{call-next-method}, тогда вызывается
  следующий наиболее специфичный применимый \cd{:around} метод. Если больше
  \cd{:around} методов не осталось, или \cdf{call-next-method} была вызвана в
  последнем таком методе, тогда для возврата значений из обобщённой функции
  выполняется Lisp'овая форма, составленная из такого же имени, как и тип
  сочетания методов, и списка применимых главных методов. Допустим имя типа
  сочетания методов \emph{operator} и вызов обобщённой функции выглядит так:
\begin{lisp}
(\emph{generic-function} $a_1$ ... $a_{n}$)
\end{lisp}
Пусть $M_1,\ldots,M_{k}$ будут применимыми главными методами в таком же
порядке, тогда производная Lisp'овая форма будет выглядеть так:
\begin{lisp}
(\emph{operator} $\langle M_1\;a_1\ldots a_{n}\rangle$
... $\langle M_k\;a_1\ldots a_{n}\rangle$)
\end{lisp}
Если вычисляется выражение $\langle M_{i} \;a_1\ldots a\sub
{n}\rangle$, тогда метод $M_i$ будет применён к аргументам $a_1\ldots a_{n}$.
Например, если \emph{operator} равен \cdf{or}, выражение $\langle M\sub{i} \
a_1\ldots a_{n}\rangle$ будет вычислено, только если $\langle M_{j} \ a_1\ldots
a_{n}\rangle$, $1\leq j<i$, вернуло \cdf{nil}.

Порядок по-умолчанию для главных методов \cd{:most-specific-first}. Однако,
порядок может быть изменён указанием \cd{:most-specific-last} в качестве второго
аргумента для параметра \cd{:method-combination}.
\end{itemize}

Простые системный типы сочетания методов требуют только один квалификатор для
метода. В случаях, если существуют применимые методы без квалификаторов или с
неподдерживающимися квалификаторами, сигнализируется ошибка. Если существуют
применимые \cd{:around} методы, и не существует главных, также сигнализируется
ошибка.

\subsection{Метаобъекты}

Реализация объектной системы управляет классами, методами и обобщёнными
функциями. Метаобъектный протокол определяет множество обобщённых функций,
которые содержат методы для классов. Поведение данных обобщённых функций
определяет поведение объектной системы. Экземпляры классов, для которых
определены эти методы, называются \emph{метаобъектами}. Программирование на
уровне метаобъектного протокола включает определение новых классов для
метаобъектов вместе с методами для этих классов.

\subsubsection{Метаклассы}

\emph{Метакласс} объекта --- это класс класса данного объекта. Метакласс
устанавливает представление экземпляров от экземпляров этого метакласса и формы
наследования, используемые этими экземплярами для описаний слотов и наследования
методов. Механизм метаклассов может использоваться для оптимизации или
модификации объектной системы. Протокол для определения метаклассов в третьей
части CLOS спецификации: Метаобъектный протокол CLOS~\ref{METAOBJECT-PROTOCOL}.

\subsubsection{Стандартные метаклассы}

CLOS содержит ряд уже определённых метаклассов. В них входят классы
\cdf{standard-class}, \cdf{built-in-class} и \cdf{structure-class}:

\begin{itemize}

\item Класс \cd{standard-class} является классом по-умолчанию для классов,
  определённых с помощью \cdf{defclass}.

\item Класс \cdf{built-in-class} является классов, экземпляры которого являются
  классами с ограниченными возможностями, которые имеют специальное
  предназначение. Любой класс, который соответствует стандартному Common
  Lisp'овому типу может быть экземпляром класса \cdf{built-in-class}.
  Встроенные Common Lisp'овые спецификаторы типов, которые должны иметь
  соответствующие классы, перечислены в таблице~\ref{CLOS-PRECEDENCE-TABLE}.
  Будут ли реализованы данные классы как экземпляры класса \cdf{built-in-class}
  зависит от реализации.

\item Все классы определённые с помощью \cdf{defstruct} являются экземплярами \cdf{structure-class}.
\end{itemize}

\subsubsection{Стандартные метаобъекты}

Объектная система содержит стандартный набор метаобъектов, называемых
\emph{стандартные метаобъекты}. Они включают в себя класс \cdf{standard-object}
и экземпляры классов \cdf{standard-method}, \cdf{standard-generic-function} и
\cdf{method-combination}.

\begin{itemize}

\item 
Класс \cdf{standard-method} является классом по-умолчанию для методов,
определённых с помощью форм \cdf{defmethod}, \cdf{defgeneric}, 
\cdf{generic-function}.

\item 
Класс \cdf{standard-generic-function} является классом по-умолчанию для
обобщённых функций, определённых с помощью форм \cdf{defmethod},
\cdf{defgeneric}, \cdf{generic-function} %\cdf{generic-flet},
%\cdf{generic-labels}, \cdf{with-added-methods}, 
и \cdf{defclass}.

\item 
Класс с именем \cdf{standard-object} является экземпляром класса
\cdf{standard-class} и является суперклассом для любого класса, который является
экземпляром \cdf{standard-class}, за исключением самого себя.

\item 
Каждый объект сочетания методов является экземпляром подкласса класса
\cdf{method-combination}.
\end{itemize}

\subsection{Создание и инициализация объекта}
\label{Object-Creation-and-Initialization-SECTION}

Обобщённая функция \cdf{make-instance} создаёт и возвращает новый экземпляр
класса. Первый аргумент является классом или его именем, и остальные аргументы
формируют список \emph{инициализационных аргументов}.

Инициализация нового экземпляра состоит из нескольких раздельных шагов:
объединение явно указанных инициализационных аргументов со значениями по-умолчанию
для неуказанных аргументов, проверка корректности инициализационных аргументов,
выделение место для хранения экземпляра, заполнение слотов значениями
и выполнение пользовательских методов, позволяющих выполнить дополнительную
инициализацию. Каждый шаг \cdf{make-instance} реализуется
с помощью обобщённой функции, обеспечивая механизм для настройки этого шага. 
Кроме того, \cdf{make-instance} сама по себе является обобщённой функцией и, следовательно,
также может быть настроена.

Объектная система определяет системные главные методы для каждого шага, и таким
образом определяет хорошо описанное стандартное поведения для всего
инициализационного процесса. Стандартное поведение предоставляет четыре
простых механизма для управления инициализацией.

\begin{itemize}

\item Декларация символа для инициализационного аргумента для
  слота. Инициализационный аргумент декларируется с помощью параметра слота
  \cd{:initarg} в \cdf{defclass}. Это механизм для указания значения для слота в
  \cdf{make-instance}.

\item Указание формы значения по-умолчанию для инициализационного
  аргумента. Формы значения по-умолчанию для инициализационного аргумента
  определяются с помощью параметра класса \cd{:default-initargs} в
  \cdf{defclass}. Если инициализационный аргумент не предоставляется явно как
  аргумент для \cdf{make-instance}, вычисляется форма значения по-умолчанию в
  том же лексическом окружении, что и форма \cdf{defclass}, которая её содержит,
  и значение используется в качестве инициализационного аргумента.

\item Указание первоначального значения по-умолчанию для слота. Форма первоначального
  значения по-умолчанию для слота определяется с помощью параметра слота
  \cd{:initform} в \cdf{defclass}. Если с данным слотом не связан
  инициализационный аргумент ни в \cdf{make-instance}, ни в
  \cd{:default-initarg}, данная форма вычисляется в лексическом окружении
  \cdf{defclass}, и полученное значение сохраняется в слот. Форма \cd{:initform}
  локального слота может быть использована при создании экземпляра или при
  обновлении экземпляра класса для согласования с переопределённым
  классом. Форма \cd{:initform} для разделяемого слота может быть использована
  при определении или переопределении класса.

\item Определение методов \cdf{initialize-instance} и
  \cdf{shared-initialize}. Описанное выше поведение при заполнении слотов
  реализуется системными главным методом для \cdf{initialize-instance},
  который вызывает \cdf{shared-initialize}. Обобщённая функция
  \cdf{shared-initialize} реализует части инициализации, разделённой на четыре
  ситуации: при создании экземпляра, при переинициализации экземпляра, при
  обновлении экземпляра для согласования с переопределённым классом и при
  обновлении экземпляра для согласования с другим классом. Системный главный
  метод для \cdf{shared-initialize} напрямую реализует поведение заполнения
  слотов, описанное выше, и \cdf{initialize-instance} содержит вызов к
  \cdf{shared-initialize}.

\end{itemize}

\subsubsection{Инициализационные аргументы}

Инициализационный аргумент управляет созданием и инициализацией объекта. Обычно
для его имени удобно использовать ключевой символ, но может использоваться любой
символ, включая \cdf{nil}. Инициализационный аргумент может использоваться двумя
методами: для заполнения слота значением, или для предоставления аргумента в
инициализационном методе. Для обоих методов может использовать один
инициализационный аргумент.

\emph{Список инициализационных аргументов} --- это список чередующихся имён
инициализационных аргументов и их значений. Его структура идентична списку
свойств и также части списка аргументов для \cd{\&key} параметров. Как и в тех
списках, если инициализационный аргумент в списке встречается более чем один
раз, для значения используется наиболее левое вхождение, остальные
игнорируются. Аргументы для \cdf{make-instance} (после первого аргумента)
формируют список инициализационных аргументов. Проверка имён инициализационных
аргумент отключена, если в списке встречает пара \cd{:allow-other-keys} и
не-\cdf{nil}.

Инициализационный аргумент может быть связан со слотом. Если инициализационный
аргумент имеет значение в списке, это значение сохраняется в слоте вновь
создаваемого объекта, перезаписывая любый связанные со слотом формы
\cd{:initform}. Один инициализационный аргумент может задавать значения более
чем одному слоту. Инициализационный аргумент, который инициализирует разделяемый
слот, записывает значение в этот слот, заменяя любое предыдущее.

Инициализационный аргумент может быть связан с методом. Когда создаётся объект и
указан такой инициализационный аргумент, то обобщённые функции
\cdf{initialize-instance}, \cdf{shared-initialize} и \cdf{allocate-instance}
вызываются с этим аргументом в виде пары: ключевой параметр и его значение.
Если значение для инициализационного аргумента на было указано в списке,
лямбда-список метода используется значение по-умолчанию.

Инициализационные аргументы используются в четырёх случаях: при создании
экземпляра класса, при переинициализации экземпляра, при обновлении экземпляра
в соответствие с переопределённым классом, и при обновлении экземпляра в
соотвествие с определением другого класса.

Поскольку инициализационные аргументы используются для управления созданием и
инициализацией экземпляра того или иного класса, мы говорим, что
инициализационный аргумент --- это <<инициализационный аргумент для>> этого
класса.

\subsubsection{Декларация корректных инициализационных аргументов FIXME}
\label{Declaring-the-Validity-of-Initialization-Arguments-SECTION}

Инициализационные аргументы проверяются на корректность в каждой из четырёх
ситуаций их использования. Инициализационный аргумент может быть корректен в
одном случае и некорректен в другом. Например, системный главный метод для
\cdf{make-instance}, определённый для \cdf{standard-class}, проверяет
корректность инициализационных аргументов и сигнализирует ошибку, если
инициализационный аргумент указан и является некорректным в данной ситуации.

Существует два случая декларации корректного инициализационного аргумента.

\begin{itemize}

\item Инициализационные аргументы, которые заполняют слоты, являются
  корректными, если декларированы в параметры слота \cd{:initarg} в
  \cdf{defclass}. Таким образом множество корректных инициализационных
  аргументов, которые заполняют слоты, являются объединением всех корректных
  инициализационных аргументов для слотов данного класса и всех его
  суперклассов. Тогда инициализационные аргументы корректны во всех четырёх
  случаях использования.

\item Инициализационные аргументы, которые передают значения в методы являются
  корректными, если определены в этих методах. Имя каждого именованного
  параметра, указанное в лямбда-списке метода, становится инициализационным
  аргументом для всех классов, для которых данный метод применим. Таким образом
  наследование методов управляет множеством корректных инициализационных
  аргументов, которые передают значения в методы. Обобщённая функция для таких
  методов:

\begin{itemize}

\item Создание экземпляра класса: \cdf{allocate-instance},
  \cdf{initialize-instance} и \cdf{shared-initialize}. Инициализационные
  аргументы декларированные этими методами являются корректными при создании
  экземпляра класса.

\item Переинициализация экземпляра: функции \cdf{reinitialize-instance} и
  \cdf{shared-initialize}. Инициализационные
  аргументы декларированные этими методами являются корректными при
  переинициализации экземпляра класса.

\item Обновление экземпляра в соответствие с переопределённым классом: 
  \cdf{update-instance-for-redefined-class} и 
  \cdf{shared-initialize}. Инициализационные
  аргументы декларированные этими методами являются корректными при
  обновление экземпляра в соответствие с переопределённым классом.

\item Обновление экземпляра в соответствие с другим классом: 
  \cdf{update-instance-for-different-class} и 
  \cdf{shared-initialize}. Инициализационные
  аргументы декларированные этими методами являются корректными при
  обновление экземпляра в соответствие с другим классом.
\end{itemize}
\end{itemize}

Корректные инициализационные аргументы это те, которые устанавливают значения в
слоты или те, что передают значения в методы вместе с предопределённым
аргументом \cd{:allow-other-keys}. Значение по-умолчанию для
\cdf{:allow-other-keys} равно \cdf{nil}. Значение \cd{:allow-other-keys} здесь
такое же, как и в случае использования в обычной функции.

\subsubsection{Значения по-умолчанию для инициализационных аргументов}
\label{DEFAULTING-INITIALIZATION-ARGUMENTS}

Форма значения по-умолчанию для инициализационного аргумента может быть указана
с помощью параметра класса \cd{:default-initargs}. Если инициализационный
аргумент задекларирован в некотором классе, его значение по-умолчанию может быть
обозначено в другом классе. В этом случае \cd{:default-initargs} используется
для установки значения по-умолчанию для унаследованного инициализационного
аргумента.

Параметр \cd{:default-initargs} используется только для указания значений
по-умолчанию. Он не декларирует символ в качестве корректного имени
инициализационного аргумента. Кроме того, параметр \cd{:default-initargs}
используется только для указания значений по-умолчанию при создании экземпляра
объекта.

Аргумент к параметру класса \cd{:default-initargs} является списком чередующихся
имён инициализационных аргументов и форм. Каждая форма является значением
по-умолчанию для соответствующего инициализационного аргумента. Форма значения
по-умолчанию инициализационного аргумента используется и вычисляется только,
если этот аргумент не встречается в \cdf{make-instance} и значение по-умолчанию
не переопределено в более специфичном классе. Форма значения по-умолчанию
вычисляется в лексическом окружении \cdf{defclass}, в котором она была
указана. Результат вычисления используется для установки в инициализационный
аргумент.

Инициализационные аргументы, указанные в \cdf{make-instance}, объединяются с
аргументами, которые имеют значения по-умолчанию, и получается \emph{список
  инициализационных аргументов со значениями по-умолчанию}. Этот список является
списком чередующихся имён инициализационных аргументов и значений. Вначале идут
пары со значениями переданными в функцию, затем --- со значениями
по-умолчанию. Значения по-умолчанию упорядочены в соотвествие со списком
приоритетности классов, в которых они были определены.

Цели параметров \cd{:default-initargs} и \cd{:initform} различаются. Параметр
класса \cd{:default-initargs} позволяет пользователю указывать
формы значения по-умолчанию для инициализационного аргумента без знания о том:
для слота ли значение, или для метода. Если инициализационный аргумент не был
указан в вызове \cdf{make-instance}, то используется его значение по-умолчанию и
ситуация становится такой, как будто аргумент таки был указан. В отличие от
этого, параметр слота \cd{:initform} позволяет пользователю задать для слота
значение по-умолчанию. Форма \cd{:initform} используется только в случаях когда
не было указано инициализационного аргумента в \cdf{make-instance} и для
него в \cd{:default-initargs} не было указано значение по-умолчанию.

Порядок вычисления форм значений по-умолчанию для инициализационных аргумент и
порядок вычисления форм \cd{:initform} не определены. Если порядок вычисления
важен, используйте методы \cdf{initialize-instance} или \cdf{shared-initialize}.

\subsubsection{Правила для инициализационных аргументов}
\label{Rules-for-Initialization-Arguments-SECTION}

Параметр слота \cd{:initarg} для одного может быть указан более одного раза.
В таком случае срабатывают следующие правила:

\begin{itemize}
\item Данный инициализационный аргумент может использоваться для инициализации
  более чем одно слота, если в параметре слота \cd{:initarg} указаны одинаковые
  аргументы.

\item Данное имя инициализационного аргумента может встречаться в лямбда-списках
  более чем в одном инициализационном методе.

\item Данное имя инициализационного аргумент может встречаться и в параметре
  слота \cd{:initarg} и в лямбда-списке инициализационного метода.
\end{itemize}

Если в \cdf{make-instance} передано два или более инициализационных аргументов
для одного и того же слота, тогда из них используется только тот, который стоит
левее остальных, даже если имена аргументов отличаются.

Если два или более инициализационных аргументов задают значение
для одного и того же слота, и ни один из них не указан в \cdf{make-instance},
тогда из них используется только тот, который встречается в параметре самого
специфичного класса \cd{:default-initargs}. Если один параметр класса
\cd{:default-initargs} определяет два или более инициализационных аргументов для
одного и того же слота, используется значение наиболее левого из них, остальные
игнорируются.

Инициализационные аргумент, явно указанные в \cdf{make-instance}, стоят слева 
от аргументов со значениями по-умолчанию. Предположим классы $C_1$ и $C_2$
содержат значения по-умолчанию для инициализационных аргумент для различных
слотов, и предположим, что $C_1$ более специфичен, чем $C_2$. Тогда значения
по-умолчанию из $C_1$ в списке инициализационных аргументов будут стоять слева от
значений из $C_2$. Если один параметр класс \cd{:default-initargs} содержит
значения для нескольких различных слотов, в списке инициализационных аргументов
эти значения будут указаны в таком же порядке.

Если слот имеет и форму \cd{:initform}, и параметр слота \cd{:initarg} и
инициализационный аргумент имеет значение в \cd{:default-initargs} или в
\cdf{make-instance}, форма \cd{:initform} не используется и не вычисляется.

Пример вышеназванных правил:

\begin{lisp}
(defclass q () ((x :initarg a))) \\*
\\*
(defclass r (q) ((x :initarg b)) \\*
~~(:default-initargs a 1 b 2))
\end{lisp}

\begin{flushleft}
\begin{tabular*}{\textwidth}{@{}l@{\extracolsep{\fill}}ll@{}}
&\textrm{Инициализация}&\textrm{Содержимое} \\
\textrm{Форма}&\textrm{списка аргументов}&\textrm{слота} \\
\hlinesp
\cd{(make-instance 'r)}&\cd{(a 1 b 2)}&\cd{1}\\
\cd{(make-instance 'r 'a 3)}&\cd{(a 3 b 2)}&\cd{3}\\
\cd{(make-instance 'r 'b 4)}&\cd{(b 4 a 1)}&\cd{4}\\
\cd{(make-instance 'r 'a 1 'a 2)}&\cd{(a 1 a 2 b 2)}&\cd{1} \\
\hline
\end{tabular*}
\end{flushleft}

\subsubsection{shared-initialize}
\label{Shared-Initialize-SECTION}

При создании, переинициализации, при обновлении до изменённого класса,
обновлении до другого класса для заполнения слотов экземпляра класса с помощью
инициализационных аргументов и форм \cdf{:initform} используется обобщённая
функция \cdf{shared-initialize}. Она использует стандартный тип сочетания
методов. Она принимает следующие аргументы: экземпляр для инициализации,
спецификация набора слотов, доступных в данном экземпляре, и любое количество
инициализационных аргументов. Аргументы после первых двух должны формировать
список инициализационных аргументов.

Второй аргумент для \cdf{shared-initialize} может быть одним из:

\begin{itemize}
\item Он может быть списком имён слотов.

\item Он может быть символом \cdf{nil}, что означает пустой список имён слотов.

\item Он может быть символом \cdf{t}, который означает список всех слотов.
\end{itemize}

В системе установлен главный метод для \cdf{shared-initialize}, у которого
первый специализатор параметра является классом \cdf{standard-object}. Вне
зависимости от того, разделяемый ли слот, или локальный, данный
метод ведёт себя следующим образом:

\begin{itemize}
\item Если инициализационный аргумент в списке указывает значение для такого
  слота, тогда значение сохраняется в слоте, даже если значение уже было до
  запуска метода в нем сохранено. Данный слот не зависит от того, какие слоты
  были указаны во втором аргументе \cdf{shared-initialize}.

\item Любые слоты, указанные во втором аргументе, и которые до сих пор не были связаны
с какими-либо значениями, инициализируются в соответствие с их формами
\cd{:initform}. Для любых таких слотов, которые имеют форму \cd{:initform},
эта форма выполняется в таком же лексическом окружении, что и выполнялась формы
\cdf{defclass}, и её значение сохраняется в слоте. Например, если \cd{:before}
метод сохраняет значение в слот, форма \cd{:initform} использоваться не
будет. Если второй аргумент это имя, которое не указывает ни на один слот в
экземпляре, результат непредсказуем.

\item А также правила, упомянутые в разделе~\ref{Rules-for-Initialization-Arguments-SECTION}.
\end{itemize}

Обобщённая функция \cdf{shared-initialize} вызывается из системных главных
методов для обобщённых функций 
\cdf{initialize-instance},
\cdf{reinitialize-instance}, 
\cdf{update-instance-for-different-class} и 
\cdf{update-instance-for-redefined-class}. 
Таким образом для указания действий, которые должны быть выполнены во всех этих
контекстах, можно написать методы для \cdf{shared-initialize}.

\subsubsection{initialize-instance}

Обобщённая функция \cdf{initialize-instance} вызывается из \cdf{make-instance}
для инициализации вновь создаваемого экземпляра класса. Она используется
стандартный тип сочетания методов. Для \cdf{initialize-instance} могут быть
определены методы для выполнения какого-либо инициализационного алгоритма.

\cdf{initialize-instance} вызывается в процессе инициализации после выполнения
следующих действий.

\begin{itemize} 

\item Вычисляется список инициализационных аргументов со значениями
  по-умолчанию.

\item Проверяется его корректность. Если хоть один аргумент в списке
  некорректен, сигнализируется ошибка.

\item Создаётся новый экземпляр со слотами несвязанными со значениями.

\end{itemize}

Вызывается обобщённая функция \cdf{initialize-instance} с параметрами: новый
экземпляр, инициализационные аргументы. В системе для \cdf{initialize-instance}
установлен главный метод, специализатором параметра которого является класс
\cdf{standard-object}. Данный метод для заполнения слотов значениями в
соответствие с инициализационными аргументами или формами \cd{:initform} вызывает
обобщённую функцию \cdf{shared-initialize}. Обобщённая функция
\cdf{shared-initialize} вызывается со следующими аргументами: экземпляр, \cdf{t}
и инициализационные аргументы.

Следует отметить, что \cdf{initialize-instance} в вызов \cdf{shared-initialize}
предоставляет список инициализационных аргументов, таким образом первый шаг,
выполняемый системным главным методом для \cdf{shared-initialize} учитывает и
аргументы \cdf{make-instance} и список инициализационных аргументов.

Для указания действий при инициализации экземпляра могут быть определены методы
для \cdf{initialize-instance}. Если для \cdf{initialize-instance} указаны только
\cd{:after} методы, они будут вызваны после системного метода и таким образом не
будут влиять на поведение по-умолчанию.

Объектная система предоставляет две функции, которые весьма полезны в телах
методов \cdf{initialize-instance}. Функция \cdf{slot-boundp} возвращает булево
значение, которое показывает, имеет ли указанный слот значение. Это позволяет
писать \cd{:after} методы для \cdf{initialize-instance}, которые инициализируют
слоты, только если они ещё не были инициализированы.

\subsubsection{Определения make-instance and initialize-instance}

Обобщённая функция \cdf{make-instance} ведёт себя так, как если была определена
следующим образом (за исключением возможных оптимизаций):

\begin{lisp}
(defmethod make-instance ((class standard-class) \&rest initargs) \\*
~~(setq initargs (default-initargs class initargs)) \\*
~~... \\*
~~(let ((instance (apply \#'allocate-instance class initargs))) \\*
~~~~(apply \#'initialize-instance instance initargs) \\*
~~~~instance)) \\
\\
(defmethod make-instance ((class-name symbol) \&rest initargs) \\*
~~(apply \#'make-instance (find-class class-name) initargs))
\end{lisp}

%This is the code:
%(defmethod make-instance ((class standard-class) &rest initargs)
%  (setq initargs (default-initargs class initargs))
%  (let* ((proto (class-prototype class))
%         (methods 
%           (append
%	      (compute-applicable-methods #'allocate-instance `(,class))
%	      (compute-applicable-methods #'initialize-instance `(,proto))
%	      (compute-applicable-methods #'shared-initialize `(,proto nil)))))
%	 (unless
%	   (subsetp
%	     (let ((keys '()))
%	       (do ((plist initargs (cddr plist)))
%		   ((null plist) keys)
%	 	 (push (car plist) keys)))
%	     (union 
%	       (class-slot-initargs class)
%	       (reduce #'union (mapcar #'function-keywords methods))))
%	   (error ...)))
%  (let ((instance (apply #'allocate-instance class initargs)))
%    (apply #'initialize-instance instance initargs)
%    instance))

Пропущенный код в определении \cdf{make-instance} проверяет переданные
инициализационные аргументы на корректность. Эта проверка должна быть выполнена
с помощью обобщённых функция \cdf{class-prototype},
\cdf{compute-applicable-methods}, \cdf{function-keywords} и
\cdf{class-slot-initargs}. Смотрите третью часть спецификации для описания
проверки инициализационных аргументов.

Обобщённая функция ведёт себя так, как если бы была определена следующим образом
(за исключением возможных оптимизаций):

\begin{lisp}
(defmethod initialize-instance \\*
~~~~~~~~~~~((instance standard-object) \&rest initargs) \\*
~~(apply \#'shared-initialize instance t initargs)))
\end{lisp}

Эти процедуры могут быть настроены (модифицированы) и на уровне функций из
интерфейса к CLOS, и на метаобъектном уровне, или даже на всех двух уровнях.

Настройка на уровне CLOS включает использование параметров \cd{:initform},
\cd{:initarg} и \cd{:default-initargs} в \cdf{defclass}, а также определение
методов для \cdf{make-instance} и \cdf{initialize-instance}. Также возможно
определение методов для \cdf{shared-initialize}, которые будут вызваны
обобщёнными функциями \cdf{reinitialize-instance}, 
\cdf{update-instance-for-redefined-class}, 
\cdf{update-instance-for-different-class} и
\cdf{initialize-instance}. Метаобъектный уровень поддерживает дополнительные
настройки с помощью определения методов для \cdf{make-instance},
\cdf{default-initargs} и \cdf{allocate-instance}. 

Реализации могут оптимизировать \cdf{initialize-instance} и
\cdf{shared-instance}. Описание \cdf{shared-initialize} в
разделе~\ref{Functions-in-the-Programmer-Interface-SECTION} содержит возможные
оптимизации.

Из-за оптимизаций, проверка корректности инициализационных аргументов может не
использовать обобщённые функции \cdf{class-prototype},
\cd{compute-applicable-methods}, \cdf{function-keywords} и
\cdf{class-slot-initargs}  Кроме того, методы обобщённой функции
\cdf{default-initargs} и системные главные методы для \cdf{allocate-instance},
\cdf{initialize-instance} и \cdf{shared-initialize} могут вызываться не каждый
раз при выполнении \cdf{make-instance} или могут получать не всех аргументы,
которые хотят.

\subsection{Переопределение классов}
\label{Redefining-Classes-SECTION}

Класс, который является экземпляром \cdf{standard-class} может быть
переопределён, если новый экземпляр также принадлежит классу
\cdf{standard-class}. Переопределение класса --- это модификация существующего
объекта класса для соответствия с новым определением. Это не создание нового
объекта класса. Любые объекты методов созданные в соответствие с параметрами
\cd{:reader}, \cd{:writer} или \cd{:accessor} в старом определении класса
удаляются из соответствующих обобщённых функций.
А методы указанные в новом определении класса наоборот добавляются.

Когда переопределяется класс \emph{C}, изменения затрагивают его экземпляры, а
также экземпляры всех его подклассов. Время обновление такого экземпляра зависит
от реализации, но не позже, чем будет обращение к его слоту. Обновление
экземпляра не меняет его идентичности в соответствии с определением функции
\cdf{eq}.
Процесс обновления может только менять слоты отдельно взятого экземпляра, но не
создавать новые экземпляры. Потребление памяти при процессе обновления зависит
от реализации.

Следует отметить, что переопределение класса может приводить к добавлению или
удалению слотов. Если при переопределении класса произошло изменения набора
слотов для экземпляров, то последние будут обновлены. Если же локальные слоты
изменены не были, процесс обновления экземпляров зависит от реализации.

Значение слота, который и в старом, и в новом классах является разделяемым,
остаётся неизменным. Если он был несвязанным, он таким же и останется. Слот,
который в старом классе был локальным, а в новом стал разделяемым, будет заново
инициализирован. Вновь добавленные разделяемые слоты также будут
инициализированы.

Каждый вновь добавленный разделяемый слот будет иметь значение формы
\cd{:initform}, определённой в новом классе. Если такой формы не было, слот
остаётся несвязанным.

Если происходит переопределение класса и при этом изменяется набор локальных
слотов, то обновление всех экземпляров происходит в два шага. Процесс может быть
запущен явно с помощью обобщённой функции \cdf{make-instance-obsolete}. В
некоторых реализациях этот процесс может быть запущен и при других
обстоятельствах. Например, при изменении порядка слотов.

Первый шаг модифицирует структуру экземпляра, а именно, добавляет новые
локальные слоты и удаляет локальные слоты, которых нет в новом определении.
Второй шаг инициализирует вновь добавленные локальные слоты и выполняет другие
пользовательские действия. Эти шаги описаны в следующих разделах.

\subsubsection{Изменение структуры экземпляров классов}

Первый шаг изменяет структуру экземпляров переопределяемого класса для
согласования с новым определением. Добавляются локальные слоты, указанные в
новом классе, но отсутствующие или бывшие разделяемыми в определении
старого. Удаляются слоты (и локальные, и разделяемые), не существующие в
определении нового класса, но бывший в определении старого. Имена этих
добавленных и удалённых слотов передаются в
\cdf{update-instance-for-redefined-class} как написано в следующем разделе.

Значений локальных слотов, указанных и в новом, и в старом определениях,
остаются нетронутыми. Если слот был несвязанным, он таким и остаётся.

Значения слотов, которые в старом определении были разделяемыми, а в новом стали
локальными, остаются нетронутыми. Если такой слот был несвязанным, он таким и
остаётся.

\subsubsection{Инициализация вновь добавленных локальных слотов}
 
Второй шаг обновления инициализируется вновь добавленные слоты и выполняет
другие пользовательские действия. Данный шаг реализован обобщённой функцией 
\cdf{update-instance-for-redefined-class}, которая вызывается после того как
завершается первый шаг обновления или было произведено изменение структуры
класса.

Обобщённая функция \cdf{update-instance-for-redefined-class} принимает четыре
обязательных аргумента: обновляемый экземпляр после первого шага, список имён
локальных слотов, которые были добавлены, список имён локальный слотов, которые
были удалены, и список свойств, содержащий имена слотов и из значения, которые
были удалены и имели эти значения. В удалённые слоты включаются также те слоты,
которые в старом классе были локальными, а в новом --- разделяемыми.

Обобщённая функция \cdf{update-instance-for-redefined-class} также принимает
любое количество инициализационных аргументов. Когда система вызывает данную
функцию для обновления экземпляра, класс которого был переопределён, ни одного
такого аргумента не указывается.

В системе установлен главный метод для
\cdf{update-instance-for-redefined-class}, у которого специализатор параметра
является классом \cdf{standard-object}. Сначала
этот метод проверяет корректность инициализационных аргументов и сигнализирует
ошибку в случае неудачи. Смотрите
раздел~\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION}. 
Затем он вызывает обобщённую функцию \cdf{shared-initialize} со следующими
аргументами: экземпляр класса, список имён вновь добавленных слотов и принятые
инициализационные аргументы.

\subsubsection{Настройка переопределения класса}

Для указания действий, происходящих при обновлении экземпляра класса, могут быть
определены методы для \cdf{update-instance-for-redefined-class}. Если для
\cdf{update-instance-for-redefined-class} определены только \cd{:around} методы,
они будут запущены после системного главного метода и не будут влиять на
поведение по-умолчанию \cdf{update-instance-for-redefined-class}. Так как в 
\cdf{update-instance-for-different-class} системой не передаются инициализационные
аргументы, формы \cd{:initform} для слотов, которые были заполнены в \cd{:before}
методах, для \cdf{update-instance-for-redefined-class} вычисляться не будут.

Для настройки переопределения класса могут быть определены методы для
\cdf{shared-initialize} (смотрите раздел~\ref{Shared-Initialize-SECTION}).

\subsubsection{Расширения}

Существует для расширения для переопределения класса:

\begin{itemize}

\item Объектная система может быть расширена до того, чтобы разрешить новому
  классу быть экземпляром другого метакласса, не совпадающего со старым.

\item Объектная система может быть расширена до того, чтобы поддерживать процесс
  обновления, когда или старый или новый класс является экземпляром класса,
  отличающегося от \cdf{standard-class}, то есть экземпляром не системного класса.
\end{itemize}

\subsection{Изменение класса для некоторого экземпляра}
\label{Changing-the-Class-of-an-Instance-SECTION}

Функция \cdf{change-class} может использоваться для изменения класс некоторого
экземпляра с текущего $C_{from}$ на какой-либо другой $C_{to}$. Функция изменяет
структуру экземпляра для согласования с определением класса $C_{to}$.

Следует отметить, что изменение класса экземпляра может вызвать добавление или
удаление слотов.

При вызове \cdf{change-class} для некоторого экземпляра, происходят два шага
его обновления. Первый шаг модифицирует структуру экземпляра, а, именно,
добавляет новые локальные и/или удаляет старые локальные слоты, которые не были
определены в новом классе. Второй шаг инициализирует добавленные локальные слоты
и выполняет некоторые действия, определённые пользователем. Эти шаги описаны в
следующих разделах.

\subsubsection{Модификация структуры экземпляра}

Для того, согласовать экземпляр с классом $C_{to}$, добавляются локальные слоты,
указанные в классе $C_{to}$, но не указанные в $C_{from}$, и удаляются локальные
слоты не определённые в $C_{to}$, но определённые в $C_{from}$.

Значения локальных слотов указанные и в классе $C_{to}$ и в классе $C_{from}$
сохраняются как есть. Если такой локальный слот не связан с каким-либо значение,
он остаётся несвязанным.

Значения слотов, определённых в классе $C_{from}$ как разделяемые, и в классе
$C_{to}$ как локальные, остаются неизменными.

Данный первый шаг обновления экземпляра не затрагивает значения каких-либо
разделяемых слотов.

\subsubsection{Инициализация вновь добавленных локальных слотов}

Второй шаг обновления инициализируется вновь добавленные слоты и выполняет
другие пользовательские действия. Данный шаг реализован обобщённой функцией 
\cdf{update-instance-for-different-class}. Обобщённая функция
\cdf{update-instance-for-different-class} вызывается функцией
\cdf{change-class}, после того как завершается первый шаг обновления.

Обобщённая функция \cdf{update-instance-for-different-class} вызывается с двумя
аргументами, вычисленными в \cdf{change-class}. Первый передаваемый аргумент ---
копия обновляемого экземпляра, который принадлежит классу $C_{from}$. Данная
копия имеет динамическую продолжительность видимости внутри обобщённой функции
\cdf{change-class}. Второй аргумент --- обновляемый экземпляр класса $C_{t}$.

Обобщённая функция \cdf{update-instance-for-different-class} также принимает
любое количество инициализационных аргументов. При вызове из \cdf{change-class}
таких аргументов ни одного не указывается.

В системе установлен главный метод для
\cdf{update-instance-for-different-class}, у которого есть два специализатора
параметров, каждый из которых является классом \cdf{standard-object}. Сначала
этот метод проверяет корректность инициализационных аргументов и сигнализирует
ошибку в случае неудачи. Смотрите
раздел~\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION}. 
Затем он вызывает обобщённую функцию \cdf{shared-initialize} со следующими
аргументами: экземпляр класса, список имён вновь добавленных слотов и принятые
инициализационные аргументы.

\subsubsection{Настройка изменения класса экземпляра}

Для указания действий, происходящих при обновлении экземпляра класса, могут быть
определены методы для \cdf{update-instance-for-different-class}. Если для
\cdf{update-instance-for-different-class} определены только \cd{:around} методы,
они будут запущены после системного главного метода и не будут влиять на
поведение по-умолчанию \cdf{update-instance-for-different-class}. Так как
функция \cdf{change-class} не передаёт в
\cdf{update-instance-for-different-class} инициализационные
аргументы, формы \cd{:initform} для слотов, которые были заполнены в \cd{:before}
методах, для \cdf{update-instance-for-different-class} вычисляться не будут.

Для настройки переопределения класса могут быть определены методы для
\cdf{shared-initialize} (смотрите раздел~\ref{Shared-Initialize-SECTION}).

\subsection{Переинициализация экземпляра}
\label{Reinitializing-an-Instance-SECTION}

Для изменения значений слотов в соответствии с инициализационными аргументами
может использоваться обобщённая функция \cdf{reinitialize-instance}.

Процесс переинициализации изменяет значения некоторых слотов и выполняет
определённые пользователем действия.

Переинициализация не модифицирует структуру экземпляра класса, и не используется
какие-либо формы \cd{:initform} для инициализации слотов.

Обобщённая функция \cdf{reinitialize-instance} может быть вызвана напрямую. Она
принимает один обязательный аргумент, экземпляр класса. Она также принимает
любое количество инициализационных аргументов для их использования в методов
\cdf{reinitialize-instance} или для \cdf{shared-initialize}. Аргументы после
обязательного экземпляра класса, должны формировать инициализирующий список
аргументов.

В системе установлен главный метод для \cdf{reinitialize-instance}, у которого
специализатором параметра является \cdf{standard-object}. Сначала этот метод
проверяет корректность инициализационных аргументов и в случае некорректности
сигнализирует ошибку (смотрите
раздел~\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION}).
Затем он вызывает обобщённую функцию \cdf{shared-initialize} со следующими
аргументами: экземпляр класса, \cdf{nil}, и инициализационные аргументы.

\subsubsection{Настройка переинициализации}

Для указания действий при обновлении экземпляра класса могут быть определены
методы для обобщённой функции \cdf{reinitialize-instance}. Если определены
только \cd{:after} методы, они будут выполнены после установленного системой
главного метода и таким образом не будут изменять стандартного поведения
\cdf{reinitialize-instance}.

Для настройки переопределения класса могут быть определены методы для
\cdf{shared-initialize}. Смотрите раздел~\ref{Shared-Initialize-SECTION}.

\section{Функции для работы с CLOS}
\label{Functions-in-the-Programmer-Interface-SECTION}

Данный раздел описывает функции, макросы, специальные операторы и обобщённые
функции для работы с CLOS. Данный интерфейс охватывает функции и макросы,
которых достаточно для написания большинства объектно-ориентированных программ.

Описание каждой функции, макроса, специального оператора и обобщённой функции
включает предназначение, синтаксис, семантику аргументов, возвращаемые значения
и часто примеры и ссылки на связанные функции.

Описание синтаксиса для функции, макроса или специального оператора содержит
информацию о их параметрах.
Описание обобщённой функции включает описание методов, которые для этой функции
определены в CLOS. \emph{Сигнатура метода} используется для описания параметров
и их специализаторов для каждого метода.

Следующий пример показывает формат описания обобщённой функции с сигнатурой
 для главного метода.

\begin{defun}[Обобщённая функция][Главный метод]
f x y &optional z &key :k \\
f (x class) (y t) &optional z &key :k

Данное описание показывается, что обобщённая функция \cdf{f} имеет два
обязательных параметра: \emph{x} и \emph{y}. Кроме того присутствуют один
необязательный параметр \emph{z} и именованный параметр \cd{:k}.

Сигнатура метода показывает, что этот метод для обобщённой функции \cdf{f} имеет
два обязательных параметра, \emph{x}, который должен быть экземпляром класса
\cdf{class}, и \emph{y}, который может быть любым объектом. Кроме того присутствуют один
необязательный параметр \emph{z} и именованный параметр \cd{:k}. Сигнатура также
показывает, что этот метод \cdf{f} является главным и не имеет квалификаторов.

Описание синтаксиса для обобщённой функции описывает лямбда-список самой
функции, тогда как сигнатура метода описывает лямбда-списки определённых методов.
\end{defun}   %misplaced to make better break

Обобщённые функции, описанные в данной книге, являются стандартными. Все они
используют стандартный механизм сочетания методов.

Любая реализация CLOS может предоставлять дополнительные методы для описанных
здесь обобщённых функций.

Функции и макросы можно распределить по категориям так:
\begin{itemize}

\item 
\emph{Инструменты используемые для простого объектно-ориентированного
  программирования}

Эти инструменты позволяют определять новые классы, методы и обобщённые функции,
и создавать экземпляры классов. Также перечислены некоторые функции,
используемые внутри тел методов. Некоторые из ниже перечисленных макросов, имеют
соответствующие функции, которые выполняют ту же задачу но на более низком уровне
абстракции.
\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\cdf{call-next-method}&\cdf{initialize-instance}\\
\cdf{change-class}&\cdf{make-instance}\\
\cdf{defclass}&\cdf{next-method-p}\\
\cdf{defgeneric}&\cdf{slot-boundp}\\
\cdf{defmethod}&\cdf{slot-value}\\
%\cdf{generic-flet}
&\cdf{with-accessors}\\
\cdf{generic-function}&%\cdf{with-added-methods}
\\
%\cdf{generic-labels}
&\cdf{with-slots}
\end{tabular}
\end{flushleft}

\item 
\emph{Функции, лежащие под часто основными макросами}

\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\cdf{add-method}&\cdf{reinitialize-instance}\\
\cdf{class-name}&\cdf{remove-method}\\
\cdf{compute-applicable-methods}&\cdf{shared-initialize}\\
\cdf{ensure-generic-function}&\cdf{slot-exists-p}\\
\cdf{find-class}&\cdf{slot-makunbound}\\
\cdf{find-method}&\cdf{slot-missing}\\
\cdf{function-keywords}&\cdf{slot-unbound}\\
\cdf{make-instances-obsolete}&\cdf{update-instance-for-different-class}\\
\cdf{no-applicable-method}&\cdf{update-instance-for-redefined-class}\\
\cdf{no-next-method}&
\end{tabular}
\end{flushleft}

\item 
\emph{Инструменты для декларации сочетания методов}

\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\cdf{call-method}&\cdf{method-combination-error}\\
\cdf{define-method-combination}&\cdf{method-qualifiers}\\
\cdf{invalid-method-error}&
\end{tabular}
\end{flushleft}

\item 
\emph{Основные Common Lisp'овые функции}

\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\cdf{class-of}&\cdf{print-object}\\
\cdf{documentation}&\cdf{symbol-macrolet}
\end{tabular}
\end{flushleft}

\end{itemize}
\noindent
[At this point the original CLOS report contained a description of the
\Mchoice{ } and \Mind{} notation; that description is omitted here.
I have adopted the notation for use
throughout this book. It is described in
section~\ref{FUNCTION-HEADER-NOTATION-SECTION}.---GLS]

\begin{defun}[Обобщённая функция][Главный метод]
add-method generic-function method \\
add-method (generic-function standard-generic-function) (method method)

Обобщённая функция \cdf{add-method} добавляет метод в обобщённую функцию. Она
деструктивно модифицирует обобщённую функцию и возвращает её в качестве
результата.

Аргумент \emph{generic-function} является объектом обобщённой функции.

Аргумент \emph{method} является объектом метода. Лямбда-список функции метода
должен быть согласован с лямбда-списком обобщённой функции, иначе будет
сигнализирована ошибка.

Функция возвращает модифицированный объект обобщённой функции. Результата
функции \cdf{add-method} равен \cdf{eq} аргументу \emph{generic-function}.

Если заданный метод совпадает с уже существующим в данной обобщённой функции
методом в специализаторах параметров и квалификаторах, то он заменяется на
новый. Смотрите
раздел~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION} для
подробного описания механизма.

Если объект метода принадлежит другой обобщённой функции, сигнализируется
ошибка.

Смотрите
раздел~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}.

Смотрите \cdf{defmethod},
\cdf{defgeneric},
\cdf{find-method} и \cdf{remove-method}.
\end{defun}

\begin{defmac}
call-method method next-method-list

Макрос \cdf{call-method} используется в сочетании методов. Данный макрос
скрывает платформоспецифичные штучки о том, как происходят вызовы методов.
Он может быть использован только внутри формы метода, так как имя
\cdf{call-method} определено только в лексической области данной формы.

Макрос \cdf{call-method} вызывает указанный метод, передавая ему аргументы и
определения для \cdf{call-next-method} и для \cdf{next-method-p}. Аргументы те
же, что и переданные в метод содержащий вызов данного макроса. Определения
\cdf{call-next-method} и \cdf{next-method-p} опираются на список объектов
методов, переданный в качестве второго аргумента \cdf{call-method}.

Функция \cdf{call-next-method}, доступная для метода из первой подформы, 
вызовет первый метод из списка из второй подформы. Функция
\cdf{call-next-method}, доступная в этом методе, в свою очередь, вызовет второй
метод в списке из второй подформы, и так далее, пока список методов не
закончится.

Аргумент \emph{method} является объектом метода. Аргумент
\emph{next-method-list} является списком объектов методов.

Список, у которого первый элемент является символом \cdf{make-method}, и второй
элемент которого является Lisp'овой формой, может использоваться вместо объекта
метода на месте первой подформы макроса \cdf{call-method} или в качестве
элемента списка во второй подформе. Такой список \cd{(make-method lisp-form)}
задаёт объект метода, тело которого состоит из формы \emph{lisp-form}.

Результатом \cdf{call-method} является значение(я), возвращённые вызываемым
методом.

Смотрите \cdf{call-next-method}, \cdf{define-method-combination} и
\cdf{next-method-p}.
\end{defmac}

\begin{defun}[Функция]
call-next-method &rest args

Функция \cdf{call-next-method} может использоваться внутри тела метода для
вызова следующего метода.

Функция \cdf{call-next-method} возвращает значение(я), которые были возвращены
вызванным методом. Если следующего метода не оказалось, вызывается обобщённая
функция \cdf{no-next-method}.

Для определения того, какие методы могут вызывать \cdf{call-next-method}
используется тип сочетания методов. Стандартный тип сочетания методов
позволяет использовать \cdf{call-next-method} в главных и \cd{:around} методах.

Стандартный тип сочетания методов находит следующий метод в соответствие с
правилами:

\begin{itemize}

\item
Если \cdf{call-next-method} используется в \cd{:around} методе, следующим
методом является наиболее специфический метод, который может быть применён к
использованным аргументам.

\item 
Если \cd{:around} методов нет, или если \cdf{call-next-method} был вызван
  самым последним специфическим \cd{:around} методом, то вызываются другие
  методы, как показано ниже:

\begin{itemize}

\item Вызываются все \cd{:before} методы в порядке убывания
  специфичности. Функция \cdf{call-next-method} не может быть использована в
  \cd{:before} методах.

\item 
Вызывается наиболее специфический главный метод. Внутри тела главного
  метода может использоваться \cdf{call-next-method} для передачи управления
  следующему наиболее специфическому главному методу. Если была использована
  \cdf{call-next-method} и больше не осталось главных методов, вызывается
  Обобщённая функция \cdf{no-next-method}.

\item Все \cd{:after} методы вызываются в порядке возрастания
  специфичности. Функция \cdf{call-next-method} не может использоваться в
  \cd{:after} методах.
\end{itemize}
\end{itemize}

Часть описания \cdf{call-next-method} содержится в
разделах~\ref{Standard-Method-Combination-SECTION} 
и~\ref{Built-in-Method-Combination-Types-SECTION}. 

Когда \cdf{call-next-method} вызывается без аргументов, она передаёт аргументы
для текущего метода в следующий метод. Ни значения аргументов по-умолчанию, ни
использование \cdf{setq}, ни пересвязывания переменных с теми же именами, что и
параметры текущего метода не влияют на значения, передаваемые функцией
\cdf{call-next-method} в следующий метод.

Если \cdf{call-next-method} вызывается с аргументами, они передаются при вызове
в следующий метод. При указании аргументов для \cdf{call-next-method} должно
выполняться следующее правило, иначе будет сигнализирована ошибка: 
Упорядоченное множество методов, которые применимы к аргументам указанным в
\cdf{call-next-method} должно быть эквивалентно множеству аргументов, которые
применимы к оригинальным аргументам, указанным в текущий метод.
Допускаются оптимизации проверки данной ошибки, но они не должны
изменять семантики \cdf{call-next-method}.

Если \cdf{call-next-method} вызывается с аргументами, но необязательные
параметры не указываются, следующий метод будет вызван со значениями
по-умолчанию для данных аргументов.

Функция \cdf{call-next-method} возвращает значение(я), которые были возвращены
следующим методом.

После того, как \cdf{call-next-method} возвращает управление, можно проводить
дальнейшие вычисления.

Определение функции \cdf{call-next-method} имеет лексическую область видимости
(она определена только внутри тела метода) и неограниченную продолжительность видимости.

Для обобщённых функций, которые используют сочетания методов, определённые с
помощью формы \cdf{define-method-combination}, \cdf{call-next-method} может
использоваться только в \cd{:around} методах.

Для проверки, существует ли следующий метод, может использоваться функция
\cdf{next-method-p}.

Если \cdf{call-next-method} используется в методах, которые её не поддерживают,
сигнализируется ошибка.

Смотрите разделы~\ref{Method-Selection-and-Combination-SECTION}, 
\ref{Standard-Method-Combination-SECTION} и
\ref{Built-in-Method-Combination-Types-SECTION}.
Смотрите функции \cdf{define-method-combination},
\cdf{next-method-p}
и \cdf{no-next-method}.
\end{defun}


\begin{defun}[Обобщённая функция][Главный метод]
change-class instance new-class \\
change-class (instance standard-object) (new-class standard-class) \\
change-class (instance t) (new-class symbol)

Обобщённая функция \cdf{change-class} изменяет класс экземпляра \emph{instance}
на новый класс \emph{new-class}. Функция деструктивно модифицирует и возвращает
экземпляр.

Если в старом классе были какие-либо слоты с теми же именами, что и локальные
слоты в новом классе, тогда значения таких слотов остаются прежними. Это значит,
что если в слоте было значение, тогда значение, возвращаемое \cdf{slot-value}
после вызова \cdf{change-class}, будет равно \cdf{eql} значение, возвращаемому
\cdf{slot-value} перед вызовом \cdf{change-class}. Если слот не имел связывания,
то после изменения класса он также не будет иметь связывания. Другие слоты будут
инициализированы так, как описано в
разделе~\ref{Changing-the-Class-of-an-Instance-SECTION}.

Аргумент \emph{instance} является Lisp'овым объектом.

Аргумент \emph{new-class} является объектом класса или символом, указывающим на
класс.

Если применяется второй из перечисленных выше методов, то этот метод вызывает
\cdf{change-class} для экземпляра \emph{instance} и \cd{(find-class \emph{new-class})}.

В качестве результата возвращается модифицированный экземпляр. Результат
\cdf{change-class} равен \cdf{eq} аргументу \emph{instance}.

Например:

\begin{lisp}
(defclass position () ()) \\
\\
(defclass x-y-position (position) \\*
~~((x :initform 0 :initarg :x) \\*
~~~(y :initform 0 :initarg :y))) \\
\\
(defclass rho-theta-position (position) \\*
~~((rho :initform 0) \\*
~~~(theta :initform 0))) \\
\\
(defmethod update-instance-for-different-class :before \\*
~~~~~~~~~~~((old x-y-position)  \\*
~~~~~~~~~~~~(new rho-theta-position) \\*
~~~~~~~~~~~~\&key) \\
~~;; Copy the position information from old to new to make new \\*
~~;; be a rho-theta-position at the same position as old. \\*
~~(let ((x (slot-value old 'x)) \\*
~~~~~~~~(y (slot-value old 'y))) \\*
~~~~(setf (slot-value new 'rho) (sqrt (+ (* x x) (* y y))) \\*
~~~~~~~~~~(slot-value new 'theta) (atan y x))))
\end{lisp}
\begin{lisp}
;;; С помощью change-class экземпляр класса x-y-position \\*
;;; может быть изменён так, чтобы классом  \\*
;;; стал rho-theta-position \\
\\
(setq p1 (make-instance 'x-y-position :x 2 :y 0)) \\
\\
(change-class p1 'rho-theta-position) \\
\\
;;; Результатом является то, что экземпляр связанный \\*
;;; с символом p1 сейчас является экземпляром класса \\*
;;; rha-theta-position. \\*
;;; Метод update-instance-for-different-class выполнил \\*
;;; инициализацию слотов rho и theta, основываясь 
;;; на значениях слотов x и y, которые были в старом 
;;; экземпляре.
\end{lisp}

После завершения всех других операций, \cdf{change-class} вызывает обобщённую
функцию \cdf{update-instance-for-different-class}. Обобщённая функция
\cdf{update-instance-for-different-class} может быть использована для
присваивания значений слотам в трансформированном экземпляре класса.

Обобщённая функция \cdf{change-class} имеет несколько семантических
сложностей.
Первое, она выполняет деструктивную операцию, которая может быть вызвана внутри
метода для экземпляра, который использовался для выбора применяемого
метода. Если была произведено сочетание методов, то следующие методы могут
оказаться неприменимыми.
Второе, некоторые реализации могут использовать оптимизацию при
компилировании в доступах к слотам, и когда класс экземпляра изменяется, то этот
код <<может поломаться>>.
Вывод такое, что программист не должен использовать \cdf{change-class} внутри
методов, если любой метод для текущей обобщённой функции оперирует слотами этого
экземпляра. В противном случае результаты непредсказуемы.

Смотрите раздел~\ref{Changing-the-Class-of-an-Instance-SECTION}.

Смотрите \cdf{update-instance-for-different-class}.
\end{defun}

\begin{defun}[Обобщённая функция][Главный метод]
class-name class \\
class-name (class class)

Обобщённая функция \cdf{class-name} принимает объект класса и возвращает его
имя.

Аргумент \emph{class} является объектом класса.

Функция возвращает имя заданного класса.

Именем для анонимного класса является символ \cdf{nil}.

Если \emph{S} является таким символом, что \emph{S}~=\cd{(class-name \emph{C})}
и \emph{C}~=\cd{(find-class \emph{S})}, тогда \emph{S} является именем
собственным для \emph{C}. Смотрите раздел~\ref{Classes-SECTION}.
\end{defun}

\begin{defun}[Обобщённая функция][Главный метод]
(setf class-name) new-value class \\
(setf class-name) new-value (class class)

Обобщённая функция \cd{(setf class-name)} принимает объект класса и
устанавливает его имя.
Аргумент \emph{class} является объектом класса.
Аргумент \emph{new-value} является любым объектом.
\end{defun}

\begin{defun}[Функция]
class-of object

Функция \cdf{class-of} возвращает класс, к которому принадлежит экземпляр класса
\emph{object}.
Аргументом для \cdf{class-of} может быть любой Common Lisp'овый объект.
\end{defun}

\begin{defun}[Функция]
compute-applicable-methods generic-function function-arguments

Функция \cdf{compute-applicable-methods} принимает обобщённую функцию и
аргументы для неё и возвращает множество методов, которые применимы для данных
аргументов.

Методы сортируются в соответствии с precedence order.
Смотрите раздел~\ref{Method-Selection-and-Combination-SECTION}.

Аргумент \emph{generic-function} должен быть объектом обобщённой функции.
Аргумент \emph{function-arguments} является списком аргументов для обобщённой
функции.
Результатом является списком применимых методов в порядке приоритетности.
Смотрите раздел~\ref{Method-Selection-and-Combination-SECTION}.
\end{defun}

\begin{defmac}
defclass class-name ({superclass-name}*)
         ({slot-specifier}*) <?class-option>

\begin{tabbing}
\emph{class-name} ::= \emph{symbol} \\
\emph{superclass-name} ::= \emph{symbol}\\
%\cleartabs
\emph{slot-specifier} ::= \emph{slot-name} {\Mor} (\emph{slot-name}  $\lbrack\!\lbrack\downarrow\!slot-option\,\rbrack\!\rbrack$)\\
\emph{slot-name} ::= \emph{symbol}\\
\emph{slot-option} ::= \=\Mstar{{\cd{:reader} \emph{reader-function-name}}} \\
\Mor~\Mstar{{\cd{:writer} \emph{writer-function-name}}} \\
\Mor~\Mstar{{\cd{:accessor} \emph{reader-function-name}}} \\
\Mor~\Mgroup{\cd{:allocation} \emph{allocation-type}} \\
\Mor~\Mstar{{\cd{:initarg} \emph{initarg-name}}} \\
\Mor~\Mgroup{\cd{:initform} \emph{form}} \\
\Mor~\Mgroup{\cd{:type} \emph{type-specifier}} \\
\Mor~\Mgroup{\cd{:documentation} \emph{string}}
\end{tabbing}
\penalty-10000 %required
\begin{tabbing}
\emph{reader-function-name} ::= \emph{symbol}\\
\emph{writer-function-name} ::= \emph{function-name}\\
\emph{function-name} ::= \Mgroup{\emph{symbol} {\Mor} \cd{(setf \emph{symbol})}}\\
\emph{initarg-name} ::= \emph{symbol}\\
\emph{allocation-type} ::= \cd{:instance {\Mor} :class}\\
\emph{class-option} ::= \=\cd{(:default-initargs \emph{initarg-list})} \\
\Mor~\cd{(:documentation \emph{string})} \\
\Mor~\cd{(:metaclass \emph{class-name})}  \\
\emph{initarg-list} ::= \Mstar{\emph{initarg-name default-initial-value-form}}
\end{tabbing}
Макрос \cdf{defclass} определяет именованный класс. В качестве результата
он возвращает объект нового класса.

Синтаксис \cdf{defclass} содержит параметры для указания инициализационных
аргументов для слотов, для указания инициализационных значений по-умолчанию для
слотов и для указания автоматически сгенерировать обобщённые функции для чтения
и записи значений слотов. Функция для чтения или записи по-умолчанию не
создаются. Из генерация должна быть указана явно.

Определение нового класса также создаёт определение типа с таким же
именем. Предикат \cd{(typep \emph{object class-name})} возвращает истину, если
класс данного объекта \emph{object} является классом или подклассом
с именем \emph{class-name}. Объект класса может использоваться в качестве спецификаторы
типа. Таким образом \cd{(typep \emph{object class})} возвращает истину, если
\emph{object} является классом или подклассом \emph{class}.

Аргумент \emph{class-name} является не-\cdf{nil} символом. Он становится для
класса именем собственным. Если класс с таким же именем собственным уже
существует, и этот класс является экземпляром класса \cdf{standard-class}, и если
форма \cdf{defclass} определяет класс от класса \cdf{standard-class},
определение нового класса заменяет старый.

Каждый аргумент \emph{superclass-name} является не-\cdf{nil} символом, который
указывает прямые суперклассы для нового класса. Новый класс будет наследовать
слоты и методы от каждого их этих суперклассов, от их суперклассов и так
далее. Смотрите раздел~\ref{Inheritance-SECTION} для описания наследования
слотов и методов.

Каждый аргумент \emph{slot-specifier} является или просто именем слота, или
списком, который содержит имя слота и ноль и более его параметров.
Аргумент \emph{slot-name} является символом, который синтаксически корректен, то
есть мог бы использоваться для имён переменных. Если один и тот же слот был
указан дважды, будет сигнализирована ошибка.

В описании слота можно использовать следующие параметры:

\begin{itemize}

\item
Параметр слота \cd{:reader} указывает на то, что автоматически будет определён
неквалифицированный метод для обобщённой функции с именем
\emph{reader-function-name}. Метод будет использоваться для чтения значения
слота.
Аргумент \emph{read-function-name} является не-\cdf{nil} символом. Параметр
слота \cd{:reader} для одного слота может быть указан несколько раз.

\item 
Параметр слота \cdf{:writer} указывает на то, что автоматически будет определён
неквалифицированный метод для обобщённой функции с именем
\emph{writer-function-name}. Метод будет использоваться для записи значения
в слот.
Аргумент \emph{writer-function-name} является не-\cdf{nil} символом. Параметр
слота \cd{:writer} для одного слота может быть указан несколько раз.

\item 
Параметр слота \cdf{:accessor} указывает на то, что автоматически будут определены
два неквалифицированных метода для обобщённых функций с именами
\emph{reader-function-name} и \cd{(setf \emph{reader-function-name})}. Первый метод
будет использоваться для чтения значения слота, а второй в связке с \cdf{setf}
для модификации значения слота.
Аргумент \emph{reader-function-name} является не-\cdf{nil} символом. Параметр
слота \cd{:accessor} для одного слота может быть указан несколько раз.

\item 
Параметр слота \cd{:allocation} используется для указания того, где будет
хранятся значение данного слота. Хранение значения слота может быть осуществлено,
например, в каждом экземпляре класса или в самом классе. Значением аргумента
\emph{allocation-type} может быть или \cd{:instance}, или \cd{:class}. Параметр
слота \cd{:allocation} для одного слота может быть указан максимум один
раз. Если параметр \cd{:allocation} не указан, то это значит то же, что и
\cd{:allocation :instance}.

\begin{itemize}

\item 
Если \emph{allocation-type} равен \cd{:instance}, в каждом экземпляре класса
создаётся одноимённый слот.

\item 
Если \emph{allocation-type} равен \cd{:class}, в самом классе создаётся
разделяемый слот. Значение слота используется совместно всем экземплярами
данного класса. Если класс $C_1$ определяет такой разделяемый слот, любой
подкласс $C_2$ от $C_1$ будет также совместно использовать данный слот, пока
форма \cdf{defclass} для $C_2$ не определит слот с тем же именем, или у $C_2$
будет иметь суперкласс, который стоит перед $C_1$ в списке приоритетности
классов $C_2$ и который содержит одноимённый слот.
\end{itemize}

\item
Параметр слота \cd{:initform} используется для указания
инициализационного значения для слота по-умолчанию. Параметр слота
\cd{:initform} для одного слота может быть указан максимум один раз. Данная
форма вычисляется каждый раз, когда необходима инициализация слота.  Лексическое
окружение для вычисления данной формы совпадает с тем, в котором выполнялась
формы \cdf{defclass}. Следует отметить, что лексическое окружение ссылается и на
переменные, и на функции. Для локальных слотов, динамическое окружение совпадает
с тем, в котором вызывается функция \cdf{make-instance}. Для разделяемых слотов,
динамическое окружение совпадает с тем, в котором вычисляется форма
\cdf{defclass}. Смотрите
раздел~\ref{Object-Creation-and-Initialization-SECTION}.

Реализациям не разрешено дополнять синтаксис \cdf{defclass} так, чтобы
\cd{(\emph{slot-name} :initform \emph{form})} можно было записать сокращённо
\cd{(\emph{slot-name form})}.

\item 
Параметр слота \cd{:initarg} декларирует инициализационный аргумент
\emph{initarg-name} и указывает на то, что данный аргумент инициализирует данный
слот. Если инициализационный аргумент содержит некоторое значение в вызове
\cdf{initialize-instance}, это значение будет сохранено в данном слоте, и если
был указан параметр слота \cd{:initform}, то этот параметр [\cd{:initform}]
вычисляться не 
будет. Если ни один из инициализационных аргументов не имеет значения, слот
инициализируется в соответствие с параметром слота \cd{:initform}, если
последний был указан. Параметр слота \cd{:initarg} для одного слота может быть
использован более одного раза. Аргумент \emph{initarg-name} может быть любым
символом.

\item 
Параметр слота \cd{:type} указывает но то, что содержимое слота будет всегда
принадлежать указанному типу данных. Данный параметр также декларирует тип
результата для обобщённой функции чтения слота применительно к данному
класса. Результат попытки сохранить в слоте значение неподходящего типа
непредсказуем. Параметр слота \cd{:type} для одного слота может быть указан
максимум один раз. Подробное описание параметра слота \cd{:type} дано в
разделе~\ref{Inheritance-of-Slots-and-Slot-Options-SECTION}.

\item 
Параметр слота \cd{:documentation} указывает строку документации для данного
слота.
\end{itemize}

Каждый параметр класса относится к классу в целом или ко всем слотам. Доступны
следующие параметры:

\begin{itemize}

\item 
Параметр класса \cd{:default-initargs} с последующим списком альтернативных имён
инициализационных аргументов и их инициализационных значений по-умолчанию.
Если любой какой-либо аргументов из этого списка не будет указан в
аргументах \cdf{make-instance}, то будет вычислена форма инициализационного
значения по-умолчанию и эта пара: аргумент, значение, будет добавлена в список
инициализационных аргументов перед тем как будет создан экземпляр
класса. Смотрите
раздел~\ref{Object-Creation-and-Initialization-SECTION}. Инициализационное
значение по-умолчанию вычисляется каждый раз при обращении к нему. Лексическое
окружение для данной формы совпадает с тем, в котором выполнялась форма
\cdf{defclass}. Динамическое окружение для данной формы совпадает с тем, в
котором выполнялся вызов \cdf{make-instance}. Если имя инициализационного
аргумента в параметре класса \cd{:default-initargs} встречается более одно раза,
сигнализируется ошибка. Параметр класса \cd{:default-initargs} может быть
использован максимум один раз.

\item 
Параметр класса \cd{:documentation} определяет строку документации для данного
имени класса. Тип документации для данного символа будет \cdf{type}. Для
получения данной строки может использовать форму \cd{(documentation
  \emph{class-name} 'type)}. Параметр \cd{:documentation} может быть указан
максимум один раз.

\item 
Параметр класса \cd{:metaclass} используется для указания того, что экземпляры
данного класса имеют отличный от системного (\cdf{standard-class})
метакласс. Аргумент \emph{class-name} указывает на этот метакласс.
\end{itemize}

В качестве результата возвращается созданный объект класса.

Если класс с таким же именем собственным уже существует, и этот класс является
экземпляром \cdf{standard-class} и если форма \cdf{defclass} с определением
нового класса также использует \cdf{standard-class}, существующий класс
переопределяется, и экземпляры данного класса (и всех подклассов) обновляются до
нового определения класса во время следующего к ним обращения. Смотрите
раздел~\ref{Redefining-Classes-SECTION}.

Для стандартных классов применяются следующие правила:

\begin{itemize}

\item 
Необязательно определять все суперклассы класса прежде, чем будет вычислена для
данного класса форма \cdf{defclass}.

\item 
Все суперклассы класса должны быть определены прежде, чем будут создаваться
экземпляры данного класса.

\item 
Класс должен быть определён прежде, чем он будет использован в специализаторе
параметра в форме \cdf{defmethod}.
\end{itemize}

Объектная система может быть расширены для обработки ситуаций не описанные
данными правилами.

Некоторые параметры слота наследуются от суперклассов, и некоторые из них могут
быть затенены или изменены в текущем описании слота. Параметры класса, кроме
\cd{:default-initargs}, не наследуются. Для подробного описания того, как
наследуются слоты и их параметры, смотрите
раздел~\ref{Inheritance-of-Slots-and-Slot-Options-SECTION}. 

Реализация может добавлять свои параметры формы \cdf{defclass}.
Однако если реализация сталкивается с неподдерживаемым параметром, они должна
сигнализировать ошибку.

В описании слота можно использовать несколько раз параметры функции чтения,
записи, аксессора или инициализации. Однако другие параметры в описании слота
должны встречаться только один раз, иначе будет сигнализирована ошибка.

Если для слота не определены ни функции чтения, записи, ни аксессор, тогда к
нему можно получить доступ только с помощью функции \cdf{slot-value}.

Смотрите разделы \ref{Classes-SECTION},
\ref{Inheritance-SECTION},
\ref{Redefining-Classes-SECTION},
\ref{Determining-the-Class-Precedence-List-SECTION},
\ref{Object-Creation-and-Initialization-SECTION}.

Смотрите \cdf{slot-value},
\cdf{make-instance} и 
\cdf{initialize-instance}.
\end{defmac}

\begin{defmac}
defgeneric function-name lambda-list
           <?option | {method-description}*>

\begin{tabbing}
\emph{function-name} ::= \Mgroup{\emph{symbol} {\Mor} \cd{(setf \emph{symbol})}} \\*
\emph{lambda-list} ::= \cd{(}\=\Mstar{{var}}  \\*
\>\Mopt{\cd{\&optional} \Mstar{{var {\Mor} \cd{(\emph{var})}}}}  \\*
\>\Mopt{\cd{\&rest} \emph{var}} \\*
\>\Mopt{\cd{\&key} \Mstar{keyword-parameter} \Mopt{\cd{\&allow-other-keys}}}\cd{)}
\end{tabbing}
\begin{tabbing}
\emph{keyword-parameter} ::= \emph{var} {\Mor} \cd{(\Mgroup{var {\Mor} \cd{(\emph{keyword} \emph{var})}})} \\[2pt]
\emph{option} ::= \=\cd{(:argument-precedence-order \Mplus{parameter-name})} \\[2pt]
\Mor~\cd{(declare \Mplus{declaration})} \\
\Mor~\cd{(:documentation \emph{string})} \\
\Mor~\cd{(:method-combination \emph{symbol} \Mstar{{arg}})} \\
\Mor~\cd{(:generic-function-class \emph{class-name})} \\
\Mor~\cd{(:method-class \emph{class-name})} \\[2pt]
\emph{method-description} ::= \cd{(:method }\=\Mstar{{method-qualifier}} \\
\emph{specialized-lambda-list} \\
\Mchoice{{\Mstar{declaration} {\Mor} documentation}} \\
\Mstar{{form}}\cd{)}  \\[2pt]
\emph{method-qualifier} ::= \emph{non-nil-atom} \\[2pt]
\emph{specialized-lambda-list} ::= \\*
\cd{(}\=\Mstar{{var {\Mor} \cd{(}var parameter-specializer-name\/\cd{)}}}  \\
\Mopt{\cd{\&optional} \Mstar{{var {\Mor} \cd{(}var \Mopt{initform {\Mopt{supplied-p-parameter}}}\cd{)}}}}  \\
\Mopt{\cd{\&rest \emph{var}}} \\
\Mopt{\cd{\&key} \Mstar{specialized-keyword-parameter} \Mopt{\cd{\&allow-other-keys}}} \\
\Mopt{\cd{\&aux} \Mstar{{var {\Mor} \cd{(\emph{var} \Mopt{initform})}}}}\cd{)} \\[2pt]
\emph{specialized-keyword-parameter} ::= \\
\emph{var} {\Mor} \cd{(}\Mgroup{var {\Mor} \cd{(\emph{keyword} \emph{var}\cd{)}}}
       \Mopt{initform \Mopt{supplied-p-parameter}}\cd{)} \\[2pt]
\emph{parameter-specializer-name} ::= \emph{symbol} {\Mor} \cd{(eql \emph{eql-specializer-form})}
\end{tabbing}
Макрос \cdf{defgeneric} используется для определения функции или для указания
параметров и деклараций, которые относятся к обобщённой функции в целом.

Если \cd{(fboundp \emph{function-name})} является \cdf{nil}, тогда создаётся новая
обобщённая функция. Если \cd{(fdefinition \emph{function-specifier})} является
обобщённой функцией, тогда она модифицируется. Если \emph{function-name} задаёт
необобщённую функцию, макрос или специальный оператор, то сигнализируется ошибка.

Каждый \emph{method-description} определяет метод для обобщённой функции.
Лямбда-список каждого метода должен соответствовать лямбда-списку, заданному в
параметре \emph{lambda-list}. Если это условие не выполняется, сигнализируется
ошибка.
Смотрите
раздел~\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}
для определения соответствия лямбда-списков в данном контексте.

Макрос \cdf{defgeneric} в качестве результата возвращает объект обобщённой
функции.

Аргумент \emph{function-name} является не-\cdf{nil} символом или списком вида
\cd{(setf \emph{symbol})}.

Аргумент \emph{lambda-list} является обычным лямбда-списком со следующими
ограничениями:

\begin{itemize}

\item 
Нельзя использовать \cd{\&aux}.

\item 
Необязательные и именованные аргументы могут не иметь формы первоначальных значений
по-умолчанию и не использовать параметры supplied-p.
Обобщённая функция передаёт в метод все переданные ей значения аргументов и
ничего более. Значения по-умолчанию не поддерживаются.
Однако, обратите внимание, что необязательные и именованные аргументы в
определении метода могут использовать формы первоначальных значений по-умолчанию
и могут использовать supplied-p параметры.
\end{itemize}

Также предоставляются следующие параметры. Данные параметры могут использоваться
только один раз, иначе будет сигнализирована ошибка.
\begin{itemize}

\item 
Параметр \cd{:argument-precedence-order} используется для указания порядка, в
котором обязательные аргументы в вызове обобщённой функции будут проверятся для
выбора некоторого метода. Каждый обязательный аргумент, как указано в аргументе
\emph{lambda-list}, должен быть включён только единожды как
\emph{parameter-name}, чтобы был указан полный и недвусмысленный порядок
приоритетности. Если данное условие не выполняется, то сигнализируется ошибка.

\item 
Параметр \cdf{declare} используется для указания деклараций, которые относятся к
обобщённой функции. Разрешены следующий стандартные Common Lisp'овые декларации:

\begin{itemize}

\item 
Декларация \cdf{optimize} указывает, должен ли механизм выбора метода
быть оптимизирован для скорости или потребления памяти. Данная декларация не
влияет на методы. Для указания того, как оптимизируется метод, декларация
\cdf{optimize} должна использоваться прямо в форме \cdf{defmethod} или в
описании метода. Стандарт требует только два свойства оптимизации \cdf{speed} и
\cdf{space}, реализации могут предоставлять другие свойства. Простая реализация,
которая содержит только один механизм выбора методов и игнорируется
\cdf{optimize}, является корректной.
\end{itemize}

Декларации \cdf{special}, \cdf{ftype}, \cdf{function}, \cdf{inline}, 
\cdf{notinline} и \cdf{declaration} не разрешены.
Отдельные реализации могут поддерживать дополнительные декларации в параметре
\cdf{declare}. 
Если реализация указывает на то, что декларация не поддерживается и она не
была указана в прокламации \cdf{declaration} как нестандартная, реализация
должна выдать предупреждение.

\item
Аргумент \cd{:documentation} ассоциирует строку документации с данной обобщённой
функцией. Тип документации для этой строки \cdf{function}. Для получения этой
строки можно использовать \cd{(documentation \emph{function-name} 'function)}.

\item 
Параметр \cd{:generic-function-class} может использоваться для указания того,
что обобщённая функция имеет особенный, не стандартный
(\cdf{standard-generic-function}) класс.
Аргумент \emph{class-name} является именем класса, который может использоваться
для объектов обобщённых функций. Если \emph{function-name} указывает на уже
существующую обобщённую функцию, которая имеет другое значение данного
параметра, и класс новой функции совместим со старым, то для изменения класса
будет вызвана функция \cdf{change-class}, иначе будет сигнализирована ошибка.

\item 
Параметр \cd{:method-class} используется для указания того, что все методы
данной обобщённой функции имеют особенный, не стандартный
(\cdf{standard-method}) класс. Аргумент \emph{class-name} является именем
класса, который может выступать таковым для метода.

\item 
Параметр \cd{:method-combination} и последующий символ указывают на тип
сочетания методов. Аргументы (если есть), которые следуют за данным символом
зависят от данного типа сочетания методов. Следует отметить, что стандартный
тип сочетания методов не поддерживает каких-либо аргументов. Однако, все типы
сочетаний методов, определённые с помощью краткой формы
\cdf{define-method-combination} принимают необязательный аргумент с именем
\emph{order}, по-умолчанию равный \cd{:most-specific-first}, где значение
\cd{:most-specific-last} меняет порядок главных методов на противоположный, но
не касается вспомогательных методов.
\end{itemize}

Аргументы \emph{method-description} определяет методы, которые будут связаны с
данной обобщённой функцией. Аргументы \emph{method-qualifier} и
\emph{specialized-lambda-list} в описании метода значат то же, что и в
\cdf{defmethod}.

Аргументы \emph{form} определяют тело метода. Тело метода заключается в неявный
блок. Если \emph{function-name} является символом, данный блок будет с тем же
именем, что и обобщённая функция. Если \emph{function-name} является списком
формы \cd{(setf \emph{symbol})}, имя блока будет совпадать с \emph{symbol}.

Результатом является объект обобщённой функции.

Следствием макроса \cdf{defgeneric} является выполнение следующих трёх шагов:
первое, методы определённые с помощью предыдущей \cdf{defgeneric} удаляются;
второе, вызывается \cdf{ensure-generic-function}; и третье, методы, определённые
в данной форме \cdf{defgeneric} добавляются в обобщённую функцию.

Если ни одно описание метода не было указано и обобщённая функция до этого не
существовала, создаётся обобщённая функция без методов.

Аргумент \emph{lambda-list} формы \cdf{defgeneric} указывает форму
лямбда-списков для методов данной обобщённой функции. Все её методы должны иметь
лямбда-списки согласованные с данной формой. Если форма \cdf{defgeneric}
вычисляется и некоторые методы для этой обобщённой функции содержат не
согласующиеся с этим аргументом лямбда-списки, сигнализируется ошибка. Для
подробностей смотрите
раздел~\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}.

Реализации могут расширять \cdf{defgeneric} дополнительными параметрами.
Однако реализация должна сигнализировать ошибку при столкновении с
неподдерживаемым параметром.

Смотрите
раздел~\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}.

Смотрите \cdf{defmethod}, \cdf{ensure-generic-function} и
\cdf{generic-function}.
\end{defmac}

\begin{defmac}
define-method-combination name <?short-form-option> \\
define-method-combination name lambda-list
    ({method-group-specifier}*)
    [(\!:arguments! \!.! lambda-list)]
    [(\!:generic-function! generic-fn-symbol)]
    <{declaration}* | doc-string>
    {form}*

\begin{tabbing}
\emph{short-form-option} ::= \=\cd{:documentation \emph{string}} \\
\Mor~\cd{:identity-with-one-argument \emph{boolean}} \\
\Mor~\cd{:operator \emph{operator}}  \\
\emph{method-group-specifier} ::= \cd{(}\=\emph{variable}
    \Mgroup{\Mplus{{qualifier-pattern}} {\Mor} predicate} \\
\>\Mchoice{\Mind{long-form-option}}\cd{)} \\
\emph{long-form-option} ::= \=\cd{:description \emph{format-string}} \\
\Mor~\cd{:order \emph{order}} \\
\Mor~\cd{:required \emph{boolean}}
\end{tabbing}
Макрос \cdf{define-method-combination} используется для определения новых типов
сочетаний методов.

Макрос \cdf{define-method-combination} имеет две формы. Краткая форма
предоставляет упрощённую функциональность для частого и быстрого
использования. Длинная форма более мощная, но и более подробная. Макрос схож с
\cdf{defmacro} в том, что тело является выражением, обычно с использованием
обратной кавычки, которое вычисляется в Lisp'овую форму. Таким образом,
реализованы могут быть любые управляющие конструкции. Длинная форма также
позволяет произвольную обработку квалификаторов методов.

В обеих формах \emph{name} является символом. По соглашению, оно не может быть
ключевым символом или \cdf{nil}.

Если вторая подформа является не-\cdf{nil} символом или не представлена вовсе,
используется синтаксис краткой формы \cdf{define-method-combination}.
Когда используется краткая форме, \emph{name} определяется как тип сочетания
методов, который создаёт Lisp'овую форму \cd{(\emph{operator
method-call method-call $\ldots$ })}. \emph{operator} является символом, которые
может быть именем функции, макроса или специального оператора. \emph{operator}
может быть указан ключевым параметров, по-умолчанию он равен \emph{name}.

Ключевые параметры для краткой формы:

\begin{itemize}

\item 
Параметр \cd{:documentation} используется для документирования типа сочетания
методов. 

\item 
Параметр \cd{:identity-with-one-argument} включает оптимизацию, когда
\emph{boolean} является истиной (значение по-умолчанию ложь). Если существует
только один применимый метод, и он является главным, тогда метод расценивается
как рабочий, и \emph{operator} не вызывается.
Эта оптимизация исключает необходимость создания нового рабочего метода и
расхода ресурсов на вызов функции. Этот параметр спроектирован для использования
с такими операторами, как \cdf{progn}, \cdf{and}, \cdf{+} и
\cdf{max}.

\item 
Параметр \cd{:operator} указывает имя оператора. Аргумент \emph{operator}
является символом, которые может быть именем функции, макроса или специального
оператора. По соглашению, чаще всего символы \emph{name} и \emph{operator}
совпадают, но это не обязательно.
\end{itemize}

Ни одна из подформ не вычисляется.

Эти типы сочетания методов требуют только одного квалификатора для одного
метода. В случае наличия применимых методов без квалификаторов, или с
неподдерживаемыми данными типом сочетания квалификаторами, сигнализируется
ошибка.

Определённая таким образом процедура сочетания методов для методов определяет
две роли. Метод, у которого единственный квалификатор является таким же
символом, что и тип сочетания, считается главным. Как минимум один главный метод
должен быть применимым, иначе сигнализируется ошибка. Метод с единственным
квалификатором \cd{:around} является вспомогательным, и его поведение совпадает
с такими же методами в стандартном типе сочетания методов. Функция
\cdf{call-next-method} может быть вызвана только в \cd{:around} методах. Она не
может быть использована в главных методах, определённых краткой формой макроса
\cdf{define-method-combination}. 

Определённая таким образом процедура сочетания методов, принимает необязательный
аргумент с именем \emph{order}, который по-умолчанию равен
\cd{:most-specific-first}. Значение \cd{:most-specific-last} изменяет порядок
главный метод на обратный, порядок же вспомогательных методов остаётся прежним.

Краткая форма автоматически включает проверку ошибок и поддержку для
\cd{:around} методов.

Описание встроенных типов сочетания методов смотрите в
разделе~\ref{Built-in-Method-Combination-Types-SECTION}. 

Если вторая подформа является списком, используется синтаксис длинной формы
\cdf{define-method-combination}.

Аргумент \emph{lambda-list} является обычным лямбда-списком. Он принимает любые
аргументы, указанные после имени сочетания методов в параметре
\cd{:method-combination} в форме \cdf{defgeneric}.

Далее следует список спецификаторов группирования методов. Каждый спецификатор
или с помощью сравнения квалификаторов с некоторыми шаблонами, или проверкой
квалификаторов с помощью предиката выделяет подмножество применимых для
некоторой роли методов. Эти спецификаторы группирования методов определяют все
квалификаторы, которые могут использоваться для данного типа сочетания
методов. Если применимый метод не попадает ни в одну из групп, система
сигнализирует ошибку о том, что метод некорректен для использования с этим типом
сочетания.

Каждый спецификатор группирования методов указывает на переменную. В процессе
выполнения форм в теле \cdf{define-method-combination}, эта переменная
связывается со списком методов в данной группе. Методы в данном списке
отсортированы от наиболее специфичного к наименее.

Квалификационный шаблон является списком или символом \cdf{*}. Метод подходит под
шаблон, если список квалификаторов метода равен \cdf{equal} шаблону
 (за исключением того, что символ \cdf{*} указывает на любой
квалификатор). Таким образом квалификационный шаблон может быть одним из
следующих:
пустой список \cd{()}, который указывает на неквалифицированный метод;
символ \cdf{*}, который указывает на все методы;
Ъ список, который указывает на метод с таким же количеством таких же что и в нём
квалификаторов
или список с точкой, который заканчивается символом \cdf{*} (\cdf{*} указывает
на любое количество дополнительный квалификаторов).

Каждый применимый метод проверяется на соотвествие квалификационным шаблонам и
предикатам в порядке слева направо. Как только метод удовлетворяет
квалификационному шаблону или предикату, метод становится элементом
соответствующей группировки методов и больше ни на что не проверяется. Таким
образом, если метод может быть элементом более одной группы, он включается
только в первую группу. Если группировка методов содержит более одного
квалификационного шаблона, метод должен удовлетворить только одному шаблону.

В спецификаторе группирования методов вместо квалификационных шаблонов может
быть указано имя предиката. Предикат вызывается для каждого метода, который ещё
не входит ни в одну группу. Он вызывается с одним аргументом: списком
квалификаторов метода. Предикат должен вернуть истину, если метод принадлежит
некоторой группе методов. Предикат может быть отличён от квалификационного
шаблона, потому что это символ не может быть \cdf{nil} или \cdf{*}.

Если для данного типа сочетания методов у применимых методов квалификаторы не
являются корректными, вызывается функция \cdf{invalid-method-error}.

Спецификаторы группирования методов после квалификационных шаблонов или
предиката могут содержать ключевые параметры. Ключевые параметры могут быть
отличены от дополнительных квалификационных шаблонов, потому что не являются
списками или символом \cdf{*}. Ключевые параметры:

\begin{itemize}

\item 
Параметр \cd{:description} используется для указания описания роли методов в
группе. Инструменты программного окружения для вывода этого описания используют
\cd{(apply \#'format stream \emph{format-string} (method-qualifiers
  \emph{method}))}. Данный ключевой параметр позволяет определить описание
квалификатора метода в том же модуле, в котором определяется смысл этого
квалификатора. В большинстве случаев, \emph{format-string} не содержит каких-либо
директив, но в целом использовать директивы можно. Если \cd{:description} не
указан, генерируется описание по-умолчанию. При этом используются имя переменной
и квалификационные шаблоны и условие, принимаются ли в группу
неквалифицированные методы. Аргумент \emph{format-string} не вычисляется.

\item 
Параметр \cd{:order} указывает порядок методов. Аргумент \emph{order} является
формой, которая вычисляется в \cd{:most-specific-first} или
\cd{:most-specific-last}. Если форма вычисляется в любое другое значение,
сигнализируется ошибка. Данный ключевой параметр введён для удобства и не
предоставляет излишней функциональности.
Если \cd{:order} не указан, используется значение \cd{:most-specific-first}.

\item 
Параметр \cd{:required} указывает требуется ли в данной группе хотя бы один
метод. Если аргумент \emph{boolean} равен не-\cdf{nil} и группа методов пуста
(то есть, ни один применимый метод не подошёл к квалификационному шаблону или не
удовлетворил предикату), сигнализируется ошибка. Этот ключевой параметр введён
для удобства и не предоставляет излишней функциональности. Если \cd{:required} не
указан, используется значение \cdf{nil}. Аргумент \emph{boolean} не вычисляется.
\end{itemize}

Использование спецификаторов группирования методов предоставляет удобный
синтаксис для выбора методов, разделения их на возможные роли, и выполнения
необходимой проверки ошибок. Возможно выполнение дальнейшей фильтрации методов в
теле с помощью использования обычных операций обработки списком и функций
\cdf{method-qualifiers} и \cdf{invalid-method-error}. Возможно использования
\cdf{setq} для переменных, указанных в спецификаторах группирования методов и
связывание дополнительных переменных. Также возможно выполнение любых
форм. Можно использовать только одну группу методов с шаблоном \cdf{*}. В этом
случае переменная будет связана со списком всех применимых методов в порядке от
наиболее специфичного к наименее.

Тело из форм \emph{forms} выполняет вычисления и возвращает Lisp'овую форму,
которая определяет то, как сочетаются методы, то есть возвращает рабочий
метод. Рабочий метод используется макрос \cdf{call-method}. Определение этого
макроса имеет лексическую область видимости и доступно только внутри рабочего
метода.
Учитывая метод объекта в одном из списков, полученных с помощью спецификатора
группирования методов и список следующих методов, макрос \cdf{call-method} будет
вызывать метод так, что для вызова следующего метода будет доступна
\cdf{call-next-method}.

Когда рабочий метод не имеет никакого эффекта, кроме того как вызвать один
метод, некоторые реализации используют оптимизацию, которая использует 
единственный метод непосредственно в качестве рабочего метода, что позволяет
избежать необходимости создать новый рабочий метод. Эта оптимизация является
активным, если форма рабочего метода состоит полностью из вызова
макроса \cdf{call-method}, первая подформа которого является объектом метода
и вторая является подчинённой \cdf{nil}. Если требуется оптимизация каждое тело
\cdf{define-method-combination}
несёт ответственность за удаление 
избыточных вызовов \cdf{progn}, \cdf{and}, \cdf{multiple-value-prog1}, 
и тому подобных.

Список \cd{(:arguments . \emph{lambda-list})} может быть указан перед любой
декларацией или строкой документации. Эта форма полезна, когда
тип сочетания методов выполняет некоторое особенное поведение как часть
объединённого метода, и это поведение требует доступа к аргументам обобщённой функции.
Каждая переменная параметра, определённый в \emph{lambda-list},
связывается с формой, которая может быть вставлена в рабочий метод. Когда эта
форма вычисляется в процессе выполнения рабочего метода, её значение является
соответствующим аргументом к обобщённой функции. Если \emph{lambda-list} не
согласован с лямбда-списком обобщённой функции, для согласования будут вставлены
дополнительные игнорируемые параметры. Таким образом, \emph{lambda-list} может
получать меньше аргументов, чем ожидает обобщённая функция.

Ошибочные условия, обнаруженные в теле, должны быть опубликованы с
помощью \cdf{method-combination-error} или \cdf{method-combination-error}.
Эти функции добавляют любую необходимую контекстную информацию с сообщением об
ошибке и сигнализируют соответствующую ошибку.

Тело \emph{forms} вычисляется внутри связываний, созданных лямбда-списком и
спецификаторами группирования методов. Декларации в начале тела помещаются
напрямую внутрь связывании, созданных лямбда-списком, и вне связываний
переменных группирования методов. Таким образом переменные группирования методов
не могут быть задекларированы.

Внутри тела \emph{form}, \emph{generic-function-symbol} связан с объектом
обобщённой функции.

Если указан аргумент \emph{doc-string}, он содержит строку документации для типа
сочетания методов.

Из тела \emph{forms} или из функций, вызванных в этом теле, могут быть вызваны
функции \cdf{method-combination-error} и \cdf{invalid-method-error}. Действия
этих двух функций зависят от динамических переменных, которые были автоматически
связаны перед вызовом обобщённой функции \cdf{compute-effective-method}.

Результатом вычисления макроса \cdf{define-method-combination} является новый
объект сочетания методов.

Большинство примеров использования длинной формы \cdf{define-method-combination}
также иллюстрируют использования связанных функций, которые предоставлены как
часть функционала декларативного сочетания методов.

\begin{lisp}
;;; Примеры краткой формы define-method-combination \\
\\
(define-method-combination and :identity-with-one-argument t) \\
\\
(defmethod func and ((x class1) y) \\
~~...) \\
\\
;;; Эквивалент этого примера в длинной форме: \\*
\\*
(define-method-combination and \\*
~~~~~~~~(\&optional (order ':most-specific-first)) \\*
~~~~~~~~((around (:around)) \\*
~~~~~~~~~(primary (and) :order order :required t)) \\
~~(let ((form (if (rest primary) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(and ,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~primary)) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,(first primary) ())))) \\
~~~~(if around \\*
~~~~~~~~{\Xbq}(call-method ,(first around) \\*
~~~~~~~~~~~~~~~~~~~~~~(,{\Xatsign}(rest around) \\*
~~~~~~~~~~~~~~~~~~~~~~~(make-method form))) \\*
~~~~~~~~form))) \\
\\
\\
;;; Пример длинной формы define-method-combination \\*
\\*
;;; Способ сочетания методов по-умолчанию \\*
\\*
(define-method-combination standard () \\*
~~~~~~~~((around (:around)) \\*
~~~~~~~~~(before (:before)) \\*
~~~~~~~~~(primary () :required t) \\*
~~~~~~~~~(after (:after))) \\
~~(flet ((call-methods (methods) \\*
~~~~~~~~~~~(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~methods))) \\
~~~~(let ((form (if (or before after (rest primary)) \\*
~~~~~~~~~~~~~~~~~~~~{\Xbq}(multiple-value-prog1 \\*
~~~~~~~~~~~~~~~~~~~~~~~(progn ,{\Xatsign}(call-methods before) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(call-method ,(first primary) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~,(rest primary))) \\*
~~~~~~~~~~~~~~~~~~~~~~~,{\Xatsign}(call-methods (reverse after))) \\*
~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,(first primary) ())))) \\
~~~~~~(if around \\*
~~~~~~~~~~{\Xbq}(call-method ,(first around) \\*
~~~~~~~~~~~~~~~~~~~~~~~~(,{\Xatsign}(rest around) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~(make-method form))) \\*
~~~~~~~~~~form))))
\end{lisp}
\vskip 0pt plus 10pt
\hrule width 0pt\relax
\begin{lisp}
;;; Простой путь вызова нескольких методов, пока не вернётся не-nil \\*
\\*
(define-method-combination or () \\*
~~~~~~~~((methods (or))) \\*
~~{\Xbq}(or ,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~methods))) \\
\\
;;; Более полная версия предыдущего примера \\*
\\*
(define-method-combination or  \\*
~~~~~~~~(\&optional (order ':most-specific-first)) \\*
~~~~~~~~((around (:around)) \\*
~~~~~~~~~(primary (or))) \\
~~;; Process the order argument \\*
~~(case order \\*
~~~~(:most-specific-first) \\*
~~~~(:most-specific-last (setq primary (reverse primary))) \\*
~~~~(otherwise (method-combination-error \\*
~~~~~~~~~~~~~~~~~"{\Xtilde}S is an invalid order.{\Xtilde}{\Xatsign} \\*
~~~~~~~~~~~~~~~~~~:most-specific-first and :most-specific-last {\Xtilde} \\*
~~~~~~~~~~~~~~~~~~~~are the possible values." \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~order))) \\
~~;; Must have a primary method \\*
~~(unless primary \\*
~~~~(method-combination-error "A primary method is required.")) \\
~~;; Construct the form that calls the primary methods \\*
~~(let ((form (if (rest primary) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(or ,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~primary)) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,(first primary) ())))) \\
~~~~;; Wrap the around methods around that form \\*
~~~~(if around \\*
~~~~~~~~{\Xbq}(call-method ,(first around) \\*
~~~~~~~~~~~~~~~~~~~~~~(,{\Xatsign}(rest around) \\*
~~~~~~~~~~~~~~~~~~~~~~~(make-method form))) \\*
~~~~~~~~form)))
\end{lisp}
\vskip 0pt plus 10pt
\hrule width 0pt\relax
\begin{lisp}
;;; То же, с использованием ключевых параметров :order и :required \\*
(define-method-combination or  \\*
~~~~~~~~(\&optional (order ':most-specific-first)) \\*
~~~~~~~~((around (:around)) \\*
~~~~~~~~~(primary (or) :order order :required t)) \\
~~(let ((form (if (rest primary) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(or ,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~primary)) \\*
~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,(first primary) ())))) \\
~~~~(if around \\*
~~~~~~~~{\Xbq}(call-method ,(first around) \\*
~~~~~~~~~~~~~~~~~~~~~~(,{\Xatsign}(rest around) \\*
~~~~~~~~~~~~~~~~~~~~~~~(make-method form))) \\*
~~~~~~~~form))) \\
\\
;;; This short-form call is behaviorally identical to the preceding. \\*
(define-method-combination or :identity-with-one-argument t) \\
 \\
;;; Сортировка методов по положительному целому квалификатору; :around \\*
;;; метода для краткости примера отключены. \\*
\\*
(define-method-combination example-method-combination () \\*
~~~~~~~~((methods positive-integer-qualifier-p)) \\
~~{\Xbq}(progn ,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~~(stable-sort methods \#'< \\*
~~~~~~~~~~~~~~~~~~~~~~:key \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(first (method-qualifiers \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~method))))))) \\
\\
(defun positive-integer-qualifier-p (method-qualifiers) \\*
~~(and (= (length method-qualifiers) 1) \\*
~~~~~~~(typep (first method-qualifiers) '(integer 0 *)))) \\
\\
;;; Пример использования :arguments \\*
(define-method-combination progn-with-lock () \\*
~~~~~~~~((methods ())) \\*
~~~~~~~~(:arguments object) \\
~~{\Xbq}(unwind-protect \\*
~~~~~~~(progn (lock (object-lock ,object)) \\*
~~~~~~~~~~~~~~,{\Xatsign}(mapcar \#'(lambda (method) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~{\Xbq}(call-method ,method ())) \\*
~~~~~~~~~~~~~~~~~~~~~~~~methods)) \\*
~~~~~(unlock (object-lock ,object))))
\end{lisp}

Параметр \cd{:method-combination} \cdf{defgeneric} используется для указания
того, что обобщённая функция должна использовать специальный тип сочетания
методов. Аргумент в параметре \cd{:method-combination} является именем этого
типа сочетания методов.

Смотрите разделы~\ref{Method-Selection-and-Combination-SECTION} и
\ref{Built-in-Method-Combination-Types-SECTION}.

Смотрите \cdf{call-method},
\cdf{method-qualifiers},
\cdf{method-combination-error},
\cdf{invalid-method-error}
и \cdf{defgeneric}.
\end{defmac}

\begin{defmac}
defmethod function-name {method-qualifier}*
          specialized-lambda-list
          <{declaration}* | doc-string> {form}*

\begin{tabbing}
\emph{function-name} ::= \Mgroup{\emph{symbol} {\Mor} \cd{(setf \emph{symbol})}} \\*
\emph{method-qualifier} ::= \emph{non-nil-atom} \\*
\emph{parameter-specializer-name} ::= \emph{symbol} {\Mor} \cd{(eql \emph{eql-specializer-form})}
\end{tabbing}
Макрос \cdf{defmethod} определяет метод для обобщённой функции.

Если форма \cd{(fboundp \emph{function-name})} равна \cdf{nil}, создаётся
обобщённая функция со значениями по-умолчанию: для списка приоритетности
аргументов (каждый аргумент более специфический чем те, которые в списке стоят
справа от него), для класса обобщённой функции (класс
\cdf{standard-generic-function}), для класса метод (класс \cdf{standard-class})
и для типа сочетания методов (стандартный тип сочетания методов). Лямбда-список
обобщённой функция будет согласован с лямбда-списком определяемого метода. Если
форма \cdf{defmethod} содержит именованные параметры, лямбда-список обобщённой
функции будет содержать \cd{\&key} (но не сами именованные параметры). Если
\emph{function-name} указывает на необобщённую функцию, макрос или специальный
оператор, сигнализируется ошибка.

Если обобщённая функция \emph{function-name} уже существует (где
\emph{function-name} является символом или списком типа \cd{(setf
  \emph{symbol})}), лямбда-список метода должен быть согласован с её
лямбда-списком. Если это условие не выполняется, сигнализируется
ошибка. Для определения согласованности смотрите
раздел~\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION}.

Аргумент \emph{function-name} является не-\cdf{nil} символом или списком формы
\cd{(setf \emph{symbol})}. Он указывает на обобщённую функцию, для которой
определяется метод.

Каждый аргумент \emph{method-qualifier} является объектом, который используется
объектом сочетания методов для определения данного метода. Квалификатор метода
является не-\cdf{nil} атомом. Тип сочетания методов может
ограничивать допустимые значения квалификаторов. Стандартный тип сочетания
методов допускает неквалифицированные методы или методы, у которых назначено
исключительно \cd{:before}, \cd{:after} или \cd{:around}.

\emph{specialize-lambda-list} является обычным лямбда-списком за исключением
того, что имена обязательных параметров могут быть заменены специализированными
параметрами, а, именно, списком вида \cd{(\emph{variable-name
parameter-specializer-name})}. Специализированы могут быть только обязательные
параметры. Имя специализатора параметра является символом, указывающим на класс
или \cd{(eql \emph{eql-specializer-form})}. Специализатор параметра вида
\cd{(eql \emph{eql-specializer-form})} указывает на то, что соответствующий
аргумент должен быть равен \cdf{eql} объекту, который является значением
\emph{eql-specializer-form} для применяемого метода. Если для некоторого
обязательного параметра не указан специализатор, то в предполагается список вида
\cd{(\emph{variable-name \cdf{t}})}. Смотрите
раздел~\ref{Introduction-to-Methods-SECTION}. 

Аргументы \emph{form} задают тело метода.
Тело метода заключается в неявный блок. Если \emph{function-name} является
символом, этот блок будет иметь такое же имя, как и обобщённая функция. Если
\emph{function-name} является списком вида \cd{(setf \emph{symbol})}, имя блока
будет равно \emph{symbol}.

Результатом \cdf{defmethod} является объект метода.

Классом объекта метода, будет является класс, который указан в параметре
обобщённой функции, для которой создаётся данный метод.

Если обобщённая функция уже содержит метод, который согласуется с текущим в
специализаторах параметров и квалификаторах, \cdf{defmethod} заменяет
существующий метод новым. Для термина <<согласование>> в данном контексте
смотрите раздел~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}.

Специализаторы параметров описаны в разделе~\ref{Introduction-to-Methods-SECTION}.

Раскрытие макроса \cdf{defmethod} ссылается на каждый специализированный
параметр (смотрите спецификатор декларации \cdf{ignore}), включая параметры,
которые содержат явное имя специализатора \cdf{t}. Это означает, что
предупреждений компилятора не будет, если тело метода не ссылается на
специализированный параметр. Следует отметить, что параметр, который
специализирован классом \cdf{t}, в этом контексте не является синонимом для
неспециализированного параметра (который неявно специализируется к классу
\cdf{t}).

Смотрите разделы~\ref{Introduction-to-Methods-SECTION},
\ref{Congruent-Lambda-Lists-for-All-Methods-of-a-Generic-Function-SECTION} и
\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}. 
\end{defmac}


[At this point the original CLOS report \cite{SIGPLAN-CLOS,LASC-CLOS-PART-2}
contained a specification for \cdf{describe} as a generic function.
This specification is omitted here because X3J13 voted in March 1989 \issue{DESCRIBE-UNDERSPECIFIED}
not to make \cdf{describe} a generic function after all (see \cdf{describe-object}).---GLS]


\begin{defun}[Обобщённая функция][Главный метод]
documentation x &optional doc-type \\
documentation (method standard-method)  &optional doc-type \\
documentation (generic-function standard-generic-function) &optional doc-type \\
documentation (class standard-class)  &optional doc-type \\
documentation (method-combination method-combination) &optional doc-type \\
documentation (slot-description standard-slot-description) &optional doc-type \\
documentation (symbol symbol) &optional doc-type \\
documentation (list list) &optional doc-type

Обычная функция \cdf{documentation} (смотрите
раздел~\ref{DOCUMENTATION-SECTION}) была заменена обобщённой функцией.
Обобщённая функция \cdf{documentation} возвращает строку документации, связанную
с данным объектом. Если строка документации не доступна возвращает \cdf{nil}.

Первый аргумент функции может быть символом, именем функции в форме \cd{(setf
  \emph{symbol})}, объектом метода, объектом класса, объектом обобщённой
функции, объектом сочетания методов или объектом описания слота.
Необходимо ли указывать второй аргумент зависит от типа первого аргумента.

\begin{itemize}

\item
Второй аргумент должен быть указан, если первый аргумент является объектом
метода, объектом класса, объектом обобщённой функции, объектом сочетания
методов или объектом описания слота, иначе будет сигнализирована ошибка.

\item Второй аргумент должен быть указан, если первый аргумент является символом
  или списком вида \cd{(setf \emph{symbol})}.

\item 
Формы 
\begin{lisp}
(documentation \emph{symbol} 'function)
\end{lisp}
и 
\begin{lisp}
(documentation '(setf \emph{symbol}) 'function)
\end{lisp}
возвращают строку документации для функции, обобщённой функции, специального
оператора или макроса, которые указываются символом или списком.

\item 
Форма \cd{(documentation \emph{symbol} 'variable)} возвращает строку
документации специальной переменной или константы, которые указываются символом.

\item 
Форма \cd{(documentation \emph{symbol} 'structure)} возвращает строку
документации для структуры \cdf{defstruct}, которая указывается символом.

\item Форма \cd{(documentation \emph{symbol} 'type)} возвращает строку
  документации для объекта класса, который указывается символом, если такой
  класс имеется. Если класс не был найден, функция возвращает строку
  документации для спецификатора типа, который указывается символом.

\item 
Форма \cd{(documentation \emph{symbol} 'setf)} возвращает строку документации
для связанных с символом определений \cdf{defsetf} или \cdf{define-setf-method} .

\item 
Форма \cd{(documentation \emph{symbol} 'method-combination)} возвращает строку
документации для типа сочетания методов, который указывается символом.
\end{itemize}

Реализация может дополнять множество символов, использующихся во втором
аргументе. Если реализация не поддерживает символ, переданный во втором
аргументе, должна быть сигнализирована ошибка.

Функция возвращает связанную строку документации. Если такой строки нет,
возвращается \cdf{nil}.
\end{defun}


\begin{defun}[Обобщённая функция][Главный метод]
(setf documentation) new-value x &optional doc-type \\
(setf documentation) new-value (method standard-method) &optional doc-type \\
(setf documentation) new-value (generic-function standard-generic-function) &optional doc-type \\
(setf documentation) new-value (class standard-class) &optional doc-type \\
(setf documentation) new-value (method-combination method-combination) &optional doc-type \\
(setf documentation) new-value (slot-description standard-slot-description) &optional doc-type \\
(setf documentation) new-value (symbol symbol) &optional doc-type \\
(setf documentation) new-value (list list) &optional doc-type

Обобщённая функция \cd{(setf documentation)} используется для установки строк
документации.

Первый аргумент \cd{(setf documentation)} новая строка документации.

Второй аргумент \cdf{documentation} может быть символом, именем функции в виде
\cd{(setf \emph{symbol})}, объектом метода, объектом класса, объектом обобщённой
функции, объектом сочетания методов, объектом описания слота. Должен ли
третий необязательный аргумент быть указан зависит от типа второго аргумента.

Смотрите \cdf{documentation}.
\end{defun}


\begin{defun}[Функция]
ensure-generic-function function-name &key :lambda-list
:argument-precedence-order
:declare
:documentation
:generic-function-class
:method-combination
:method-class
:environment

\begin{tabbing}
\emph{function-name} ::= \Mgroup{\emph{symbol} {\Mor} \cd{(setf \emph{symbol})}}
\end{tabbing}
Функция \cdf{ensure-generic-function} используется для определения глобальной
 обобщённой функции без методов или для изменения параметров и деклараций,
 которые применяются для глобальной обобщённой функции в целом. 

Если \cd{(fboundp \emph{function-name})} равна \cdf{nil}, создаётся новая
обобщённая функция. Если \cd{(fdefinition \emph{function-name})} является
необобщённой функцией, макросом или специальным оператором, сигнализируется ошибка.

[X3J13 voted in March 1989 \issue{FUNCTION-NAME} to use \cdf{fdefinition}
in the previous paragraph, as shown, rather than \cdf{symbol-function},
as it appeared in the original report on CLOS~\cite{SIGPLAN-CLOS,LASC-CLOS-PART-2}.
The vote also changed all occurrences of \emph{function-specifier} in the
original report to \emph{function-name}; this change is reflected here.---GLS]

Если \emph{function-name} указывает на обобщённую функцию и значения:
\cd{:argument-precedence-order}, \cd{:declare}, \cd{:documentation},
\cd{:method-combination}, отличаются от старых значений функции, тогда она 
модифицируется.

Если \emph{function-name} указывает на обобщённую функцию и значение
\cd{:lambda-list} отличается от старого, но при этом согласуется со
лямбда-списками всех методов (или если методы отсутствуют), тогда
устанавливается новое значение, иначе сигнализируется ошибка.

Если \emph{function-name} указывает на обобщённую функцию и значение
\cd{:generic-function-class} отличается от старого и если новая обобщённая
функция совместима со старой, тогда вызывается \cdf{change-class} для изменения
её класса, иначе сигнализируется ошибка.

Если \emph{function-name} указывает на обобщённую функцию и значение
\cd{:method-class} отличается от старого, значение изменяется, но классы
существующих методов не изменяются.

Аргумент \emph{function-name} является символом или списком вида \cd{(setf
  \emph{symbol})}.

Именованные параметры соответствуют аргументам \emph{option} \cdf{defgeneric},
за исключением того, что аргумента \cd{:method-class} и
\cd{:generic-function-class} могут быть как объектами класса, так и его именами.

Аргумент \cd{:environment} такой же как аргумент \cd{\&environment} для функции
раскрытия макросов. Обычно он используется для различия между временем
компиляции и временем выполнения.

Аргумент \cd{:method-combination} является объектом сочетания методов.

В качестве результата возвращает объект обобщённой функции.

Смотрите \cdf{defgeneric}.
\end{defun}

\begin{defun}[Функция]
find-class symbol &optional errorp environment

Функция \cdf{find-class} возвращает объект класса, на который указывает
заданный символ в заданном окружении.

Первый аргумент функции является символом.

Если объект класса не найден и аргумент \emph{errorp} не задан или равен
не-\cdf{nil} значению, \cdf{find-class} сигнализирует ошибку.
Если объект класса не найден и аргумент \emph{errorp} равен \cdf{nil},
\cdf{find-class} возвращает \cdf{nil}. По-умолчанию аргумент \emph{errorp} равен
\cdf{t}.

Результатом \cdf{find-class} является объект класса, который связан с заданным
символом.

Связь объекта класса и символа может быть изменена с помощью \cdf{setf} в связке
с \cdf{find-class}. Если пользователь пытается изменить класс ассоциированный с
символом, который является спецификатором типа из главы~\ref{DTSPEC}, то
результат не определён.
Смотрите раздел~\ref{Integrating-Types-and-Classes-SECTION}.
\end{defun}


\begin{defun}[Обобщённая функция][Главный метод]
find-method generic-function method-qualifiers specializers &optional errorp \\
find-method (generic-function standard-generic-function)
   method-qualifiers specializers &optional errorp

Обобщённая функция \cdf{find-method} принимает обобщённую функцию и возвращает
объект метода, который согласуется с квалификаторами \emph{method-qualifiers} и
специализаторами параметров \emph{specializers}.
Смотрите раздел~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}
для определения в данном контексте понятия согласования.

Аргумент \emph{generic-function} должен быть обобщённой функцией.

Аргумент \emph{method-qualifiers} является списком квалификаторов
метода. Порядок квалификаторов важен.

Аргумент \emph{specializers} является списком специализаторов параметров. Он
должен содержать одинаковое количество обязательных аргументов, что и обобщённая
функция, иначе будет сигнализирована ошибка. Это означает, что для получения
метода по-умолчанию для данной обобщённой функции, должен быть указан список,
элементы которого являются классами с именем \cdf{t}.

Результатом \cdf{find-method} является объект метода, у которого заданные
квалификаторы и специализаторы параметров.

Смотрите раздел~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION}.
\end{defun}


\begin{defun}[Обобщённая функция][Главный метод]
function-keywords method \\
function-keywords (method standard-method)

Обобщённая функция \cdf{function-keywords} используется для получения
спецификаторов именованных параметров для заданного метода.

Аргумент \emph{method} должен быть объектом метода.

Обобщённая функция возвращает два значение:
список явно определённых именованных параметров, и булево значение, которое
обозначает содержит ли определение метода \cd{\&allow-other-keys}.
\end{defun}

\begin{defmac}
generic-function lambda-list <?option | {method-description}*>

\begin{tabbing}
\emph{option} ::= \cd{(:argument-precedence-order \Mplus{parameter-name})} \\
~~~ \Mor~\cd{(declare \Mplus{declaration})} \\
~~~ \Mor~\cd{(:documentation
  \emph{string})} \\
~~~ \Mor~\cd{(:method-combination \emph{symbol} \Mstar{{arg}})} \\
~~~ \Mor~\cd{(:generic-function-class \emph{class-name})} \\
~~~ \Mor~\cd{(:method-class \emph{class-name})} \\\\
 \emph{method-description} ::= \cd{(:method } \Mstar{{method-qualifier}}  \emph{specialized-lambda-list} 
\Mstar{{declaration\/ {\Mor} documentation}} 
\Mstar{{form}}\cd{)}
\end{tabbing}
Макрос \cdf{generic-function} создаёт анонимную обобщённую функцию. Обобщённая
функция создаётся с набором методов, заданных в части описания методов.

Аргументы \emph{option}, \emph{method-qualifier} и
\emph{specialized-lambda-lisp} значат то же, что и в \cdf{defgeneric}.

В качестве результата возвращается объект обобщённой функции.

Если часть описания методов не указана, то обобщённая функция создаётся без
методов.

Смотрите \cdf{defgeneric} и \cdf{defmethod}.
\end{defmac}


\begin{defun}[Обобщённая функция][Главный метод]
initialize-instance instance &rest initargs \\
initialize-instance (instance standard-object) &rest initargs

Обобщённая функция \cdf{initialize-instance} вызывается в функции
\cdf{make-instance} для инициализации создаваемого экземпляра
объекта. Обобщённая функция \cdf{initialize-instance} применяется к экземпляру
класса и инициализационным аргументам.

Системный главный метод \cdf{initialize-instance} инициализирует слоты
экземпляра объекта со значениями в соответствие с инициализационными аргументами и
формами слотов \cd{:initform}.
Он производит это с помощью вызова обобщённой функции \cdf{shared-initialize} со
следующими аргументами: экземпляр класса, \cdf{t} (это указывает на то, что все
слоты, для которых не указаны инициализационные аргументы, должны быть
инициализированы в соотвествие с их формами \cd{:initform} и инициализационные
аргументы.

Аргумент \emph{instance} является объектом, который будет инициализирован.

Аргумент \emph{initargs} состоит из чередующихся имён инициализационных аргументов и их
значений.

В качестве результата возвращается модифицированный экземпляр класса.

Программисты могут определять методы \cdf{initialize-instance} для указания
дополнительных действий при инициализации экземпляра класса. Если определены
только \cd{:after} методы, они будут вызваны после системного главного метода
инициализации и таким образом не будут изменять поведение по-умолчанию
\cdf{initialize-instance}.

Смотрите разделы~\ref{Object-Creation-and-Initialization-SECTION},
\ref{Rules-for-Initialization-Arguments-SECTION} и
\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION}.

Смотрите \cdf{shared-initialize},
\cdf{make-instance},
\cdf{slot-boundp}
и \cdf{slot-makunbound}.
\end{defun}

\begin{defun}[Функция]
invalid-method-error method format-string &rest args

Функция \cdf{invalid-method-error} используется для сигнализирования ошибки, в
тех случаях, когда у применяемого метода некорректные квалификаторы для типа
сочетания методов. Сообщение об ошибке составляется с помощью форматирующей
строки и любого количества аргументов к ней. Так как реализации может быть
необходимо добавить дополнительную контекстную информацию в сообщение об ошибке,
\cdf{invalid-method-error} должна вызываться только внутри динамической
продолжительности видимости функции сочетания методов.

Функция \cdf{invalid-method-error} вызывается автоматически, когда метод не
удовлетворяет всем шаблонам квалификаторов и предикату в форме
\cdf{define-method-combination}.
Функция сочетания методов, которая налагает дополнительные ограничения, должна
явно вызывать \cdf{invalid-method-error}, если столкнулась с методом, который
она не может принять.

Аргумент \emph{method} является объектом некорректного метода.

Аргумент \emph{format-string} является форматирующей строкой, которая может
передаваться в \cdf{format}, и \emph{args} является любыми аргументами,
необходимыми данной строке.

Возвращает ли \cdf{invalid-method-error} управление или завершается с помощью
\cdf{throw} зависит от реализации.

Смотрите \cdf{define-method-combination} .
\end{defun}

\begin{defun}[Обобщённая функция][Главный метод]
make-instance class &rest initargs \\
make-instance (class standard-class) &rest initargs \\
make-instance (class symbol) &rest initargs

Обобщённая функция \cdf{make-instance} создаёт новый экземпляр заданного класса.

Обобщённая функция \cdf{make-instance} может использоваться, как это описано в
разделе~\ref{Object-Creation-and-Initialization-SECTION}.

Аргумент \emph{class} является объектом класса или символом, который на него
указывает. Остальные аргументы формируют список из чередующихся имён
инициализационных аргументов и их значений.

Если из вышеуказанного списка выбран второй метод, то он вызывает
\cdf{make-instance} с аргументами \cd{(find-class \emph{class})} и
\emph{initargs}.

Инициализационные аргументы проверяются внутри \cdf{make-instance}. Смотрите
раздел~\ref{Object-Creation-and-Initialization-SECTION}.

В качестве результата возвращается созданный экземпляр класса.

Для определения новых методов для функции \cdf{make-instance} и соответственно
изменения протокола создания объектом может использоваться метаобъектный
протокол.

Смотрите раздел~\ref{Object-Creation-and-Initialization-SECTION}.

Смотрите \cdf{defclass}, \cdf{initialize-instance} и \cdf{class-of}.
\end{defun}

\begin{defun}[Обобщённая функция][Главный метод]
make-instances-obsolete class \\
make-instances-obsolete (class standard-class) \\
make-instances-obsolete (class symbol)

Обобщённая функция \cdf{make-instance-obsolete} вызывается системой
автоматически, когда используется \cdf{defclass} для переопределения
существующего стандартного класса и изменяется набор или порядок локальных
слотов. Также и пользователь может её вызывать явно.

Функция \cdf{make-instances-obsolete} начинает процесс процесс обновления
экземпляров класса. В процессе обновления будет вызвана обобщённая функция
\cdf{update-instance-for-redefined-class}.

Аргумент \emph{class} является объектом класса или символом, который на него
указывает. Экземпляры данного класса обозначаются как устаревшие.

Если из вышеуказанного списка выбран второй метод, то он вызывает
\cdf{make-instances-obsolete} с аргументом \cd{(find-class \emph{class})}.

Результатом является модифицированный класс. Результат
\cdf{make-instances-obsolete} равен \cdf{eq} аргументу \emph{class}.

Смотрите раздел~\ref{Redefinig-Classes-SECTION}.

Смотрите \cdf{update-instance-for-redefined-class}.
\end{defun}

\begin{defun}[Функция]
method-combination-error format-string &rest args

Функция \cdf{method-combination-error} используется для сигнализирования ошибки
в сочетании методов. Сообщение об ошибке составляется с помощью форматирующей
строки и любого количества аргументов к ней. Так как реализации может быть
необходимо добавить дополнительную контекстную информацию в сообщение об ошибке,
\cdf{method-error} должна вызываться только внутри динамической
продолжительности видимости функции сочетания методов.

Аргумент \emph{format-string} является форматирующей строкой, которая может
передаваться в \cdf{format}, и \emph{args} является любыми аргументами,
необходимыми данной строке.

Возвращает ли \cdf{method-combination-error} управление или завершается с
помощью \cdf{throw} зависит от реализации.

Смотрите \cdf{define-method-combination}.
\end{defun}

\begin{defun}[Обобщённая функция][Главный метод]
method-qualifiers method \\
method-qualifiers (method standard-method)

Обобщённая функция \cdf{method-qualifiers} возвращает список квалификаторов
заданного метода.

Аргумент \emph{method} является объектом метода.

В качестве результата возвращается список квалификаторов метода.

Например:
\begin{lisp}
(setq methods (remove-duplicates methods \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:from-end t \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:key \#'method-qualifiers \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:test \#'equal))
\end{lisp}

Смотрите \cdf{define-method-combination}.
\end{defun}

\begin{defun}[Функция]
next-method-p

Локально определённая функция \cdf{next-method-p} может использоваться внутри
тела метода для определения того, существует ли следующий метод.

Функция \cdf{next-method-p} не принимает аргументов.

Функция \cdf{next-method-p} возвращает или истину, или ложь.

Также как и \cdf{call-next-method}, функция \cdf{next-method-p} имеет
лексическую область видимости (определена только для тела метода) и
неограниченную продолжительность видимости.

Смотрите \cdf{call-next-method}.
\end{defun}

\begin{defun}[Обобщённая функция][Главный метод]
no-applicable-method generic-function &rest function-arguments \\
no-applicable-method (generic-function t) &rest function-arguments

Обобщённая функция \cdf{no-applicable-method} вызывается, когда обобщённая
функция класса \cdf{standard-generic-function} вызывается и не находит не одного
применимого метода. По-умолчанию главный метод сигнализирует ошибку.

Обобщённая функция \cdf{no-applicable-method} не предназначена для вызова
программистом. Программисты могут писать методы для неё.

Аргумент \emph{generic-function} является объектом обобщённой функции, в которой
не нашлось применимого метода.

Аргумент \emph{function-arguments} является списком аргументов, которые были
переданы в эту функцию.
\end{defun}

\begin{defun}[Обобщённая функция][Главный метод]
no-next-method generic-function method &rest args \\
no-next-method (generic-function standard-generic-function)
    (method standard-method) &rest args

Обобщённая функция \cdf{no-next-method} вызывается функцией
\cdf{call-next-method}, когда не было обнаружено последующих методов для
вызова. Системный метод для этой функции сигнализирует ошибку.

Обобщённая функция \cdf{no-next-method} не предназначена для вызова
программистом. Программисты могут писать методы для неё.

Аргумент \emph{generic-function} является объектом обобщённой функции, в которой
не нашлось последующего метода.

Аргумент \emph{method} является объектом метода, в котором
не нашлось последующего метода.

Аргумент \emph{args} является списком аргументов, которые были
переданы в функцию \cdf{call-next-method}.

Смотрите \cdf{call-next-method}.
\end{defun}


\begin{defun}[Обобщённая функция][Главный метод]
print-object object stream \\
print-object (object standard-object) stream

Обобщённая функция \cdf{print-object} выводит в поток текстовое представление
объекта. Функция \cdf{print-object} вызывается с помощью системы вывода. Она не
должна вызываться пользователем.

Каждая реализация должно предоставлять метод для класса \cdf{standard-object} и
методы для других классов. Пользователь может написать методы для
\cdf{print-object} для своих класса, если он не хочет наследовать системный
методы вывода.

Первый аргумент --- любой Lisp'овый объект. Второй аргумент является потоком, и
не может быть \cdf{t} или \cdf{nil}.

Функция \cdf{print-object} в качестве результата возвращает первый аргумент, а,
именно, объект.

Методы \cdf{print-object} должны подчиняться специальным переменным управления вывода
\cd{*print-\emph{xxx}*} для различных \emph{xxx}. Далее перечислены конкретные детали:

\begin{itemize}

\item 
Каждый метод должен реализовывать \cdf{*print-escape*}.

\item 
Переменная \cdf{*print-pretty*} может быть проигнорировать в всех методах,
кроме метода для списка.

\item 
Переменная \cdf{*print-circle*} обрабатывается системой вывода и может быть
проигнорирована методами.

\item 
Система вывода автоматически обрабатывает \cdf{*print-level*}, таким образом
методы работают только с одним уровнем, рекурсивно вызывая функцию \cdf{write}
(или эквивалентную), если необходимо вывести дополнительные уровни с объектами. 
Решение системы вывода содержит ли объект компоненты (и таким образом не должен
выводится при значении \cdf{*print-level*} меньшем чем глубина его вывода)
зависит от реализации. В некоторых реализациях метода объекта \cdf{print-object}
не вызывается, в некоторых вызывается и на основе вывода метода строится
предположение о структуре объекта.
\item 
Методы, которые могут выводить объекты бесконечной длины, должны подчиняться
\cdf{*print-length*}, но большинство методов, кроме того, что для списка, могут
игнорировать данную переменную.

\item 
Переменные \cdf{*print-base*}, \cdf{*print-radix*}, \cdf{*print-case*}, 
\cdf{*print-gensym*} и \cdf{*print-array*} применяются для конкретных типов и
должны обрабатываться соответствующими методами.

\item X3J13 voted in June 1989 \issue{DATA-IO} to add the following point.
   All methods for \cdf{print-object} must obey \cd{*print-readably*},
   which takes precedence over all other printer control variables.  This
   includes both user-defined methods and implementation-defined methods.
\end{itemize}

Если эти правила не соблюдаются, результат непредсказуем.

В целом, система вывода и методы \cdf{print-object} не должны пересвязывать
переменные, управляющие выводом, так как они обрабатываются рекурсивно вместе со
структурой объекта, но это зависит от реализации.

В некоторых реализациях аргумент потока, передаваемого в \cdf{print-object}, не
является оригинальным потоком, а специальным, который используется системой
вывода. Таким образом методы не должны зависеть от сущности этого потока.

Все существующие функции вывода (\cdf{write}, \cd{prin1}, 
\cdf{print}, \cdf{princ}, \cdf{pprint}, \cdf{write-to-string}, 
\cd{prin1-to-string}, \cdf{princ-to-string}, the \cd{{\Xtilde}S} and 
\cd{{\Xtilde}A} \cdf{format} operations, and the \cd{{\Xtilde}B}, \cd{{\Xtilde}D},
\cd{{\Xtilde}E}, \cd{{\Xtilde}F}, \cd{{\Xtilde}G}, \cd{{\Xtilde}\$}, 
\cd{{\Xtilde}O}, \cd{{\Xtilde}R}, and \cd{{\Xtilde}X} \cdf{format} операции,
когда они указаны для нечислового значения) должны использовать обобщённую
функцию \cdf{print-object}. Все реализации должны выводить объекты с помощью
методов \cdf{print-object}. Так как некоторые классы могут не иметь метода для
вывода, реализация может определить один метод по-умолчанию, который
унаследуется всеми системными классами.
\end{defun}

\begin{defun}[Обобщённая функция][Главный метод]
reinitialize-instance instance &rest initargs \\
reinitialize-instance (instance standard-object) &rest initargs

Обобщённая функция \cdf{reinitialize-instance} может использоваться для
изменения значений локальных слотов в соотвествие с инициализационными
аргументами. Эта обобщённая функция вызывается метаобъектным протоколом, однако
может быть вызвана также и пользователем.

Системный главный метод для \cdf{reinitialize-instance} проверяет корректность
инициализационных аргументов и сигнализирует ошибку, в случае некорректности
какого-либо из них. Затем метод вызывает обобщённую функцию
\cdf{shared-instance} со следующими аргументами: экземпляр, \cdf{nil} (который
означает, что ни один слот не должен быть инициализирован в соответствие с формами
\cd{:initform}) и полученные инициализационные аргументы.

Аргумент \emph{instance} является объектом, который инициализируется.

Аргумент \emph{initargs} состоит из чередующихся имён инициализационных
аргументов и их значений.

В качестве результата возвращается модифицированный экземпляр объекта.

Инициализационные аргументы декларируются в параметре \cd{:initarg} в
\cdf{defclass} или в определении метода для \cdf{reinitialize-instance} или
\cdf{shared-initialize}. Имя параметра для каждого спецификаторы именованного
параметра в лямбда-списке любого метода для \cdf{reinitialize-instance} или
\cdf{shared-initialize} является корректным именем инициализационного аргумента
для всех классов, для которых применим данный метод.

Смотрите разделы~\ref{Reinitializing-an-Instance-SECTION},
\ref{Rules-for-Initialization-Arguments-SECTION},
\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION}.

Смотрите \cdf{initialize-instance}, \cdf{slot-boundp},
\cdf{update-instance-for-redefined-class},
\cdf{update-instance-for-different-class},
\cdf{slot-makunbound} и \cdf{shared-initialize}.
\end{defun}


\begin{defun}[Обобщённая функция][Главный метод]
remove-method generic-function method \\
remove-method (generic-function standard-generic-function) method

Обобщённая функция \cdf{remove-method} удаляет метод из обобщённой
функции. Функция деструктивно модифицирует указанную обобщённую функцию и
возвращает её в качестве результата.

Аргумент \emph{generic-function} является объектом обобщённой функции.

Аргумент \emph{method} является объектом метода. Функция \cdf{remove-method} не
сигнализирует ошибку, если метод не принадлежит обобщённой функции.

Результатом является объект обобщённой функции. Результат \cdf{remove-method}
равен \cdf{eq} аргументу \emph{generic-function}.

Смотрите \cdf{find-method}.
\end{defun}

\begin{defun}[Обобщённая функция][Главный метод]
shared-initialize instance slot-names &rest initargs \\
shared-initialize (instance standard-object) slot-names &rest initargs

Обобщённая функция \cdf{shared-initialize} используется для заполнения слотов
экземпляра класса с помощью инициализационных аргументов и форм
\cd{:initform}. Она вызывается при создании экземпляра, при переинициализации
экземпляра, при обновлении экземпляра до переопределённого класса, при
обновлении экземпляра до другого класса. Обобщённая функция
\cdf{shared-initialize} вызывается системными главными методами
\cdf{initialize-instance}, \cdf{reinitialize-instance},
\cdf{update-instance-for-redefined-class} и
\cdf{update-instance-for-different-class}.

Обобщённая функция \cdf{shared-initialize} принимает следующие аргументы:
экземпляр класса для инициализации, спецификацию множества имён слотов,
доступных в данном экземпляре, и любое количество инициализационных
аргументов. Аргументы после первых двух, должны формировать список
инициализационных аргументов. Системный главный метод \cdf{shared-initialize}
инициализирует слоты значениями в соотвествие с инициализационными аргументами и
указанными формами \cd{:initform}. Второй аргумент указывает, какие слоты должны
быть инициализированы в соотвествие с их формами \cd{:initform}, если для них не
были инициализационные аргументы.

Системный главный метод ведёт себя так, как сказано ниже вне зависимости от
того, является ли слот локальным или разделяемым:

\begin{itemize}

\item Если инициализационный аргумент в списке указывает значение для такого
  слота, тогда значение сохраняется в слоте, даже если значение уже было до
  запуска метода в нем сохранено.

\item Любые слоты, указанные во втором аргументе, и которые до сих пор не были связаны
с какими-либо значениями, инициализируются в соответствие с их формами
\cd{:initform}. Для любых таких слотов, которые имеют форму \cd{:initform},
эта форма выполняется в таком же лексическом окружении, что и выполнялась формы
\cdf{defclass}, и её значение сохраняется в слоте. Например, если \cd{:before}
метод сохраняет значение в слот, форма \cd{:initform} использоваться не будет.

\item А также правила, упомянутые в разделе~\ref{Rules-for-Initialization-Arguments-SECTION}.
\end{itemize}

Аргумент \emph{instance} является объектом, для которого производится инициализация.

Аргумент \emph{slot-name} указывает слоты, которые будут инициализированы в
соотвествие с их формами \cd{:initform}, если не были указаны инициализационные
аргументы. Он может передаваться в трёх разных формах:

\begin{itemize}

\item Он может быть списком имён слотов.

\item Он может быть символом \cdf{nil}, что означает пустой список имён слотов.

\item Он может быть символом \cdf{t}, который означает список всех слотов.
\end{itemize}

Аргумент \emph{initargs} состоит из чередующихся имён инициализационных
аргументов и их значений.

В качестве результата возвращается модифицированный экземпляр объекта.

Инициализационные аргументы корректны, если были указаны в параметре
\cd{:initarg} \cdf{defclass}, или в методе для функции \cdf{shared-initialize}. 

Implementations are permitted to optimize \cd{:initform} forms that 
neither produce nor depend on side effects by evaluating these forms
and storing them into slots before running any 
\cdf{initialize-instance} methods, rather than by handling them in the
primary \cdf{initialize-instance} method.  (This optimization might
be implemented by having the \cdf{allocate-instance} method copy a
prototype instance.)

Implementations are permitted to optimize default initial value forms
for initialization arguments associated with slots by not actually
creating the complete initialization argument list when the only method
that would receive the complete list is the method on 
\cdf{standard-object}.  In this case, default initial value forms can be 
treated like \cd{:initform} forms.  This optimization has no visible
effects other than a performance improvement.

Смотрите разделы~\ref{Object-Creation-and-Initialization-SECTION},
\ref{Rules-for-Initialization-Arguments-SECTION},
\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION}.

Смотрите \cdf{initialize-instance},
\cdf{reinitialize-instance},
\cdf{update-instance-for-redefined-class},
\cdf{update-instance-for-different-class},
\cdf{slot-boundp} и \cdf{slot-makunbound}.
\end{defun}


\begin{defun}[Функция]
slot-boundp instance slot-name

Функция \cdf{slot-boundp} проверяет связан ли данный слот в экземпляре
класса с каким-либо значением.

Аргумент \emph{instance} является любым объектом. Аргумент \emph{slot-name}
являются символом.

Эта функция позволяет записывать \cd{:after} методы для
\cdf{initialize-instance} для инициализации только тех слотов, которые ещё не
были связаны.

Если указанного слота в данном экземпляре не существует, вызывается
\cdf{slot-missing} как показано ниже:
\begin{lisp}
(slot-missing (class-of \emph{instance}) \\
~~~~~~~~~~~~~~\emph{instance} \\
~~~~~~~~~~~~~~\emph{slot-name} \\
~~~~~~~~~~~~~~'slot-makunbound)
\end{lisp}

Функция \cdf{slot-boundp} реализована с помощью \cdf{slot-boundp-using-class}

Смотрите \cdf{slot-missing}.
\end{defun}


\begin{defun}[Функция]
slot-exists-p object slot-name

Функция \cdf{slot-exists-p} проверяет имеется ли данный слот в экземпляре
класса.

Аргумент \emph{object} является любым объектом. Аргумент \emph{slot-name}
являются символом.

Функция \cdf{slot-exists-p} возвращает истину или ложь.

Функция \cdf{slot-exists-p} реализована с помощью \cdf{slot-exists-p-using-class}
\end{defun}


\begin{defun}[Функция]
slot-makunbound instance slot-name

Функция \cdf{slot-makunbound} устанавливает слот экземпляра \emph{instance} в
несвязанное состояние.

Аргументами \cdf{slot-makunbound} являются: экземпляр и имя слота.

В качестве результата возвращает экземпляр класса.

Если указанного слота в данном экземпляре не существует, вызывается
\cdf{slot-missing} как показано ниже:
\begin{lisp}
(slot-missing (class-of \emph{instance}) \\
~~~~~~~~~~~~~~\emph{instance} \\
~~~~~~~~~~~~~~\emph{slot-name} \\
~~~~~~~~~~~~~~'slot-makunbound)
\end{lisp}

Функция \cdf{slot-makunbound} реализована с помощью
\cdf{slot-makunbound-using-class}.
Смотрите \cdf{slot-missing}.
\end{defun}

\begin{defun}[Обобщённая функция][Главный метод]
slot-missing class object slot-name operation &optional new-value \\
slot-missing (class t) object slot-name operation &optional new-value

Обобщённая функция \cdf{slot-missing} вызывается, когда происходит попытка
доступа к слоту экземпляра класса, метакласс которого равен
\cdf{standard-class}, и этот слот отсутствует в данном экземпляре.
Метод по-умолчанию сигнализирует ошибку.

Обобщённая функция \cdf{slot-missing} не предназначения для вызова самим
программистом. Программист может написать метод для неё. 

Аргументами \cdf{slot-missing} являются: класс экземпляра, к слоту которого
происходил доступ, сам экземпляр и имя слота и символ, который означает операцию
при котором произошёл вызов \cdf{slot-missing}. Необязательный аргумент
\cdf{slot-missing} используется тогда, когда операцией являлась попытка
установки значения в слот.

Аргументами \cdf{slot-missing} являются: класс экземпляра, к слоту которого
происходил доступ, сам экземпляр и имя слота.

Обобщённая функция \cdf{slot-missing} может быть вызвана в процессе вычисления
\cdf{slot-value}, \cd{(setf slot-value)}, \cdf{slot-boundp} и
\cdf{slot-makunbound}. Для каждой из этих операций для
аргумента \emph{operation} соответствуют символы \cdf{slot-value}, \cdf{setf},
\cdf{slot-boundp} и \cdf{slot-makunbound}.

Набор аргументов (в том числе класса экземпляра) облегчает
определении методов метакласса для \cdf{slot-missing}.
\end{defun}


\begin{defun}[Обобщённая функция][Главный метод]
slot-unbound class instance slot-name \\
slot-unbound (class t) instance slot-name

Обобщённая функция \cdf{slot-unbound} вызывается, когда происходит попытка
чтения несвязанного слота экземпляра класса, метакласс которого равен
\cdf{standard-class}.
Метод по-умолчанию сигнализирует ошибку.

Обобщённая функция \cdf{slot-unbound} не предназначения для вызова самим
программистом. Программист может написать метод для неё. Функция
\cdf{slot-unbound} вызывается только функцией \cdf{slot-value-using-class} и
соответственно неявно функцией \cdf{slot-value}.

Аргументами \cdf{slot-unbound} являются: класс экземпляра, к слоту которого
происходил доступ, сам экземпляр и имя слота.

Если метод, написанный для \cdf{slot-unbound}, возвращает значения, эти значения
возвращается в качестве значения вызова оригинальной функции.

Несвязанный слот может получится, если не было формы для параметра слота
\cd{:initform} и этот слот не был позже установлен, или был вызов
\cdf{slot-makunbound} с этим слотом.

Смотрите \cdf{slot-makunbound}.
\end{defun}


\begin{defun}[Функция]
slot-value object slot-name

Функция \cdf{slot-value} возвращает значение, содержащееся в слоте с именем
\emph{slot-name} в объекте \emph{object}. Если слота с данным именем не
существует, вызывается \cdf{slot-missing}. Если слот не связан с каким-либо
значением, вызывается \cdf{slot-unbound}.

Для изменения значения слота можно использовать \cdf{setf} в связке с
\cdf{slot-value}.

При попытке прочтения слота, которого не существует в данном экземпляре класса,
вызывается функция \cdf{slot-missing} как показано ниже:
\begin{lisp}
(slot-missing (class-of \emph{instance}) \\
~~~~~~~~~~~~~~\emph{instance} \\
~~~~~~~~~~~~~~\emph{slot-name} \\
~~~~~~~~~~~~~~'slot-value)
\end{lisp}

При попытке записи в слот, которого не существует в данном экземпляре класса,
вызывается функция \cdf{slot-missing} как показано ниже:
\begin{lisp}
(slot-missing (class-of \emph{instance}) \\
~~~~~~~~~~~~~~\emph{instance} \\
~~~~~~~~~~~~~~\emph{slot-name} \\
~~~~~~~~~~~~~~'setf \\
~~~~~~~~~~~~~~\emph{new-value})
\end{lisp}

Функция \cdf{slot-value} реализована с использованием
\cdf{slot-value-using-class}.

Реализация может оптимизировать \cdf{slot-value} с помощью in-line компиляции.

Смотрите \cdf{slot-missing} и \cdf{slot-unbound}.
\end{defun}

[At this point the original CLOS report \cite{SIGPLAN-CLOS,LASC-CLOS-PART-2}
contained a specification for \cdf{symbol-macrolet}.
This specification is omitted here.  Instead, a description
of \cdf{symbol-macrolet} appears with those of related constructs in chapter~\ref{CONTRL}.---GLS]

\begin{defun}[Обобщённая функция][Главный метод]
update-instance-for-different-class previous current &rest initargs \\
update-instance-for-different-class (previous standard-object)
     (current standard-object) &rest initargs

Обобщённая функция \cdf{update-instance-for-different-class} не должна
вызываться программистом. Однако программисты могут писать для неё методы. Эта
функция вызывается только из функции \cdf{change-class}.

Системный главный метод \cdf{update-instance-for-different-class} проверяет
корректность инициализационных аргументов и в случае неуспеха сигнализирует
ошибку. Затем этот метод инициализирует слоты значениями в соотвествие с
инициализационными аргументами, а вновь добавленные слоты значениями в
соотвествие с их формами \cd{:initform}. Это происходит в вызове функции
\cdf{shared-initialize} со следующими аргументами: экземпляр, список имён вновь
добавленных слотов, и полученные инициализационные аргументы. Вновь добавленные
слоты --- это локальные слоты, для которых не существовали одноимённые слоты в
старом предыдущем классе.

Для указания дополнительных действии при обновлении экземпляра класса можно
создать методы для \cdf{update-instance-for-different-class}. Если определены
только \cd{:after} методы, то они запускаются после системного главного метода и
таким образом не воздействует на поведение системы по-умолчанию.

Аргументы для \cdf{update-instance-for-different-class} вычисляются в
\cdf{change-class}. Когда для экземпляра вызывается \cdf{change-class},
создаётся копия этого экземпляра. Она временно содержит старые значения
слотов. Эти аргументы имеют динамическую продолжительность видимости внутри
\cdf{change-class}. Если после выхода из
\cdf{update-instance-for-different-class} на них остались ссылки, результат
непредсказуем. Второй аргумент для
\cdf{update-instance-for-different-class}, \emph{current}, является
модифицируемым оригинальным экземпляром.

Использование \emph{previous} заключается в получении старых значений слотов с
помощью \cdf{slot-value}, или \cdf{with-slots} или обобщённой функции чтения,
или для запуска других методов которые применимы для экземпляров оригинального
класса.

Аргумент \emph{initargs} состоит из чередующихся имён инициализационных
аргументов и их значений.

Значение \cdf{update-instance-for-different-class} в \cdf{change-class}
игнорируется.

Смотрите пример для функции \cdf{change-class}.

Инициализационные аргументы корректны, если были указаны в параметре
\cd{:initarg} или в методах для \cdf{update-instance-for-different-class} или
\cdf{shared-initialize}. 

Для инициализации слота по-особому могут быть определены методы для
\cdf{update-instance-for-different-class}. Поведение функции \cdf{change-class}
по-умолчанию описано в разделе~\ref{Changing-the-Class-of-an-Instance-SECTION}.

Смотрите разделы~\ref{Changing-the-Class-of-an-Instance-SECTION},
\ref{Rules-for-Initialization-Arguments-SECTION} и
\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION}.

Смотрите \cdf{change-class} и \cdf{shared-initialize}.
\end{defun}

\begin{defun}[Обобщённая функция][Главный метод]
update-instance-for-redefined-class instance added-slots
    discarded-slots property-list &rest initargs \\
update-instance-for-redefined-class (instance standard-object) added-slots
    discarded-slots property-list &rest initargs

Обобщённая функция \cdf{update-instance-for-redefined-class} не должна
вызываться программистом. Однако программисты могут писать для неё методы. Эта
функция вызывается системой при использовании \cdf{make-instance-obsolete}.

Системный главный метод \cdf{update-instance-for-redefined-class} проверяет
корректность инициализационных аргументов и в случае неуспеха сигнализирует
ошибку. Затем этот метод инициализирует слоты значениями в соотвествие с
инициализационными аргументами, а вновь добавленные слоты значениями в
соотвествие с их формами \cd{:initform}. Это происходит в вызове функции
\cdf{shared-initialize} со следующими аргументами: экземпляр, список имён вновь
добавленных слотов, и полученные инициализационные аргументы. Вновь добавленные
слоты --- это локальные слоты, для которых не существовали одноимённые слоты в
старом предыдущем классе.

При вызове \cdf{make-instance-obsolete} или при переопределении класса и
обновлении экземпляра, создаётся список свойств, который содержит имена слотов и
значения всех удалённых слотов из оригинального экземпляра. Структура экземпляра
трансформируется то, чтобы удовлетворять новому определению класса. Аргумент
\cdf{update-instance-for-redefined-class}: трансформированный экземпляр, список
имён новых слотов, список имён старых слотов, список свойств, содержащий имена и
значения старых слотов. В данных список также включается слоты, которые были
локальными и стали разделяемыми.

Аргумент \emph{initargs} состоит из чередующихся имён инициализационных
аргументов и их значений.

Значение, возвращаемое из \cdf{update-instance-for-redefined-class} игнорируется.

Инициализационные аргументы корректны, если были указаны в параметре
\cd{:initarg} или в методах для \cdf{update-instance-for-redefined-class} или
\cdf{shared-initialize}.

Смотрите разделы~\ref{Redefining-Classes-SECTION},
\ref{Rules-for-Initialization-Arguments-SECTION} и
\ref{Declaring-the-Validity-of-Initialization-Arguments-SECTION}.

Смотрите \cdf{shared-initialize} и \cdf{make-instance-obsolete}.

\begin{lisp}
(defclass position () ()) \\
\\
(defclass x-y-position (position) \\*
~~((x :initform 0 :accessor position-x) \\*
~~~(y :initform 0 :accessor position-y))) \\
\\
;;; Оказывается полярные координаты используются чаще декартовых \\*
;;; координат, так что представление меняется, и добавляются  \\*
;;; некоторые новые методы доступа. \\
\\
(defmethod update-instance-for-redefined-class :before \\*
~~~~~~~~~~~((pos x-y-position) added deleted plist \&key) \\*
~~;; Transform the x-y coordinates to polar coordinates \\*
~~;; and store into the new slots. \\*
~~(let ((x (getf plist 'x)) \\*
~~~~~~~~(y (getf plist 'y))) \\*
~~~~(setf (position-rho pos) (sqrt (+ (* x x) (* y y))) \\*
~~~~~~~~~~(position-theta pos) (atan y x)))) \\
\\
(defclass x-y-position (position) \\*
~~~~((rho :initform 0 :accessor position-rho) \\*
~~~~~(theta :initform 0 :accessor position-theta)))
\end{lisp}
\vskip 0pt plus 10pt
\hrule width 0pt\relax
\begin{lisp}
;;; Все экземпляры старого класса x-y-position будут обновлены \\*
;;; автоматически. \\
\\
;;; Новое представление имеет вид и вкус старого. \\
\\
(defmethod position-x ((pos x-y-position)) \\*
~~~(with-slots (rho theta) pos (* rho (cos theta)))) \\
\\
(defmethod (setf position-x) (new-x (pos x-y-position)) \\*
~~~(with-slots (rho theta) pos \\*
~~~~~(let ((y (position-y pos))) \\*
~~~~~~~(setq rho (sqrt (+ (* new-x new-x) (* y y))) \\*
~~~~~~~~~~~~~theta (atan y new-x)) \\*
~~~~~~~new-x))) \\
\\
(defmethod position-y ((pos x-y-position)) \\*
~~~(with-slots (rho theta) pos (* rho (sin theta))))
\end{lisp}
\begin{lisp}
(defmethod (setf position-y) (new-y (pos x-y-position)) \\*
~~~(with-slots (rho theta) pos \\*
~~~~~(let ((x (position-x pos))) \\*
~~~~~~~(setq rho (sqrt (+ (* x x) (* new-y new-y))) \\*
~~~~~~~~~~~~~theta (atan new-y x)) \\*
~~~~~~~new-y)))
\end{lisp}
\end{defun}

\begin{defmac}
with-accessors ({slot-entry}*) instance-form
     {declaration}* {form}*

Макрос \cdf{with-accessors} создаёт лексическое окружение, в котором указанные
слоты доступны с помощью аксессоров, как если бы они были переменными. Для
доступа к указанному слоту макрос \cdf{with-accessors} вызывает соответствующий
аксессор. Для установки значения в слот может
использоваться и \cdf{setf}, и \cdf{setq}.

Результатом является то, что вернут формы указанные в аргументе \emph{form}.

Например:

\begin{lisp}
(with-accessors ((x position-x) (y position-y)) p1 \\*
~~(setq x y))
\end{lisp}

Выражение \cdf{with-accessors} в форме:
\begin{lisp}
(with-accessors (\textrm{$slot_1$} ... \textrm{$slot_{n}$}) \emph{instance} \\*
~~$declaration_1$ ... $declaration_{m}$) \\*
~~$form_1$ ... $form_{k}$)
\end{lisp}
раскрывается в эквивалентное выражение
\begin{lisp}
(let ((\emph{in} \emph{instance})) \\
~~(symbol-macrolet ((\textrm{$variable_1$} (\textrm{$accessor_1$} \emph{in})) \\*
~~~~~~~~~~~~~~~~~~~~... \\*
~~~~~~~~~~~~~~~~~~~~(\textrm{$variable_{n}$} (\textrm{$accessor_{n}$} \emph{in}))) \\*
~~~~$declaration_1$ ... $declaration_{m}$) \\*
~~~~$form_1$ ... $form_{k}$)
\end{lisp}

[X3J13 voted in March 1989
\issue{SYMBOL-MACROLET-SEMANTICS}
to modify the definition of \cdf{symbol-macrolet} substantially
and also voted
\issue{SYMBOL-MACROLET-DECLARE} to allow declarations before the body
of \cdf{symbol-macrolet} but with peculiar treatment of \cdf{special}
and type declarations.  The syntactic changes are reflected in this definition
of \cdf{with-accessors}.---GLS]

Смотрите \cdf{with-slots} и \cdf{symbol-macrolet}.
\end{defmac}


\begin{defmac}
with-slots ({slot-entry}*) instance-form {declaration}* {form}*

\begin{tabbing}
\emph{slot-entry} ::= \emph{slot-name} {\Mor} \cd{(\emph{variable-name} \emph{slot-name})}
\end{tabbing}
Макрос \cdf{with-slots} создаёт лексический контекст для ссылки на заданные
слоты как если бы они были переменными. Внутри такого контекста значение слота
может быть получено просто указанием имени слота, как если бы это была
лексически связанная переменная. Для установки значения в слот может
использоваться и \cdf{setf}, и \cdf{setq}.

Макрос \cdf{with-slots} транслирует вхождения имени слота как переменной в вызов
\cdf{slot-value}.

Результатом является то, что вернут формы указанные в аргументе \emph{form}.

Например:

\begin{lisp}
(with-slots (x y) position-1 \\*
~~(sqrt (+ (* x x) (* y y)))) \\
\\
(with-slots ((x1 x) (y1 y)) position-1 \\*
~~(with-slots ((x2 x) (y2 y)) position-2 \\*
~~~~(psetf x1 x2 \\*
~~~~~~~~~~~y1 y2)))) \\
\\
(with-slots (x y) position \\*
~~(setq x (1+ x) \\*
~~~~~~~~y (1+ y)))
\end{lisp}

Выражение \cdf{with-slots} в форме:
\begin{lisp}
(with-slots ($slot\mhyphen entry_{1}$ ... $slot\mhyphen entry_{n}$) \emph{instance} \\*
~~$declaration_1$ ... $declaration_{m}$) \\*
~~$form_1$ ... $form_{k}$)
\end{lisp}
раскрывается в эквивалентный код
\begin{lisp}
(let ((\emph{in} \emph{instance})) \\
~~(symbol-macrolet ($Q_1$ ... $Q_{n}$) \\*
~~~~$declaration_1$ ... $declaration_{m}$) \\*
~~~~$form_1$ ... $form_{k}$)
\end{lisp}
где ${Q}_{j}$ является
\begin{lisp}
($slot\mhyphen entry_{j}$ (slot-value \emph{in} '$slot\mhyphen entry_{j}$))
\end{lisp}
если $slot\mhyphen entry_{j}$ является символом, или ${Q}_{j}$ является
\begin{lisp}
($variable\mhyphen name_{j}$ (slot-value \emph{in} '$slot\mhyphen name_{j}$))
\end{lisp}
если ${slot\mhyphen entry}_{j}$ принадлежит форме \cd{($variable\mhyphen
  name_{j}$ $slot\mhyphen name_{j}$)}.

[X3J13 voted in March 1989
\issue{SYMBOL-MACROLET-SEMANTICS}
to modify the definition of \cdf{symbol-macrolet} substantially
and also voted
\issue{SYMBOL-MACROLET-DECLARE} to allow declarations before the body
of \cdf{symbol-macrolet} but with peculiar treatment of \cdf{special}
and type declarations.  The syntactic changes are reflected in this definition
of \cdf{with-slots}.---GLS]

Смотрите \cdf{with-accessors} и \cdf{symbol-macrolet}.
\end{defmac}
\fi
% \endgroup