amop.tex

\clearpage\def\pagestatus{FINAL PROOF}

\chapter{Metaobject Protocol}
\label{METAOBJECT-PROTOCOL}

Book: Art Of Metaobject Protocol

Chapters 5,6

Authors: Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow

\href{http://www.alu.org/mop/index.html}{http://www.alu.org/mop/index.html}

\section{Concepts}

\subsection{Introduction}
\subsection{Введение}


The CLOS Specification~\ref{CLOS} describes the standard Programmer Interface for the
Common Lisp Object System (CLOS). This document extends that specification by
defining a metaobject protocol for CLOS---that is, a description of CLOS itself
as an extensible CLOS program. In this description, the fundamental elements of
CLOS programs (classes, slot definitions, generic functions, methods,
specializers and method combinations) are represented by first-class
objects. The behavior of CLOS is provided by these objects, or, more precisely,
by methods specialized to the classes of these objects.

Because these objects represent pieces of CLOS programs, and because their
behavior provides the behavior of the CLOS language itself, they are considered
meta-level objects or metaobjects. The protocol followed by the metaobjects to
provide the behavior of CLOS is called the CLOS Metaobject Protocol (MOP). 

CLOS спецификация~\ref{CLOS} описывает API для Common Lisp'овой объектной
системы. Данная глава дополняет эту спецификацию описанием метаобъектного
протокола для CLOS --- то. В этом описании, базовые элементы CLOS'а (классы,
определения слотов, обобщённые функции, методы, специализаторы и комбинации
методов) представлены в качестве представлены как объекты первого
класса. Поведение CLOS'а регулируется этими объектами, или, если быть точнее,
методами, специализированным для объектов этих классов.

Так как эти объекты представляют части CLOS программы, и так как их поведение
задаёт поведение языка CLOS, они рассматриваются как объекты метауровня или
метаобъекты. Протокол определения методов для метаобъектов называется
Метаобъектным Протоколом CLOS (на английском MOP).

\subsubsection{Metaobjects}

\subsubsection{Метаобъекты}

For each kind of program element there is a corresponding basic metaobject
class. These are the classes: \cdf{class}, \cdf{slot-definition},
\cdf{generic-function}, \cdf{method} 
and \cdf{method-combination}. A metaobject class is a subclass of exactly one of these
classes. The results are undefined if an attempt is made to define a class that
is a subclass of more than one basic metaobject class. A metaobject is an
instance of a metaobject class. 

Для каждого элемента CLOS программы существует соответствующий базовый
метаобъектный класс. Все классы: \cdf{class}, \cdf{slot-definition},
\cdf{generic-function}, \cdf{method} 
и \cdf{method-combination}. Метаобъектный класс является подклассом только
одного из вышеперечисленных. При попытке определить класс, которые наследует
более одного базового метакласса поведение непресказуемо. Метаобъект является
экземпляром метакласса.

Each metaobject represents one program element. Associated with each metaobject
is the information required to serve its role. This includes information that
might be provided directly in a user interface macro such as \cdf{defclass} or
\cdf{defmethod}. It also includes information computed indirectly from other
metaobjects such as that computed from class inheritance or the full set of
methods associated with a generic function. 

Каждый метаобъект представляет один элемент CLOS программы. С каждым
метаобъектом связана информация, которая необходима для выполнения им своей
роли. Она включает информацию, которая может быть предоставлена напрямую в
пользовательский макрос, такой, например, как \cdf{defclass} или
\cdf{defmethod}. Она также включает информацию, вычисляемую ненапрямую от других
метаобъектов, так, например, вычисление информации из иерархии классов или
полного множества методов связанных с обобщённой функцией.

Much of the information associated with a metaobject is in the form of
connections to other metaobjects. This interconnection means that the role of a
metaobject is always based on that of other metaobjects. As an introduction to
this interconnected structure, this section presents a partial enumeration of
the kinds of information associated with each kind of metaobject. More detailed
information is presented later. 

Много информации связанной с метаобъектом находится в виде виде связи с другими
метаобъектами. Такая взаимосвязь означает, что роль метаобъекта всегда основана
на других метаобъектах. В качестве введения структуру данных взаимосвязей,
данный раздел предоставляет частичное перечисление типов информации связанной с
каждым типов метаобъектов. Более подробная информация будет предоставлена позже.

\subsubsection{Classes}

\subsubsection{Классы}

A \emph{class metaobject} determines the structure and the default behavior of its
instances. The following information is associated with class metaobjects: 

\emph{Классовые метаобъекты} определяют структуру и поведение по-умолчанию для
их экземпляров. С классовыми метаобъектами связана следующая информация:

  \begin{itemize}
  \item 
    The name, if there is one, is available as an object.

  \item 
    Имя, если оно существует, доступно как объект.

  \item 
    The direct subclasses, direct superclasses and class precedence list are
    available as lists of class metaobjects. 

  \item 
    Прямые подклассы, прямые суперклассы и список предшествования классов
    доступны как списки классовых метаобъектов.

  \item 
    The slots defined directly in the class are available as a list of direct
    slot definition metaobjects. The slots which are accessible in instances of
    the class are available as a list of effective slot definition metaobjects.

  \item
    Слоты прямо определённые в классе доступны как список прямых слотовых
    метаобъектов. Слоты, которые доступны в экземплярах класса доступны как
    список действительных слотовых метаобъектов. FIXME

  \item 
    The documentation is available as a string or \cdf{nil}.

  \item 
    Документация доступна как строка или \cdf{nil}.

  \item 
    The methods which use the class as a specializer, and the generic functions
    associated with those methods are available as lists of method and generic
    function metaobjects respectively. 

  \item 
    Методы, которые используют класс в качестве специализатора, и обобщённые
    функции, связанные с этими методами, доступны как списки методовых или
    функциональных метаобъектов соответственно.
  \end{itemize}

\subsubsection{Slot Definitions}

\subsubsection{Определения слотов}

A \emph{slot definition metaobject} contains information about the definition of a
slot. There are two kinds of slot definition metaobjects. A direct slot
definition metaobject is used to represent the direct definition of a slot in a
class. This corresponds roughly to the slot specifiers found in \cdf{defclass}
forms. An effective slot definition metaobject is used to represent information,
including inherited information, about a slot which is accessible in instances
of a particular class. 

\emph{Слотовый метаобъект} содержит информацию об определении слота. Существуют
два вида этих метаобъектов. Прямой слотовой метаобъект используется для
представления определённых слотов напрямую в классе. Он приблизительно отвечает
за спецификаторы слотов, указанные в формах \cdf{defclass}. Метаобъект
действующего слота отображает информацию, которая включает информацию об
унаследованных свойствах слота, о слотах, которые доступны в экземплярах
отдельно взятого класса.

Associated with each class metaobject is a list of direct slot definition
metaobjects representing the slots defined directly in the class. Also
associated with each class metaobject is a list of effective slot definition
metaobjects representing the set of slots accessible in instances of that
class. 

The following information is associated with both direct and effective slot
definitions metaobjects: 

  \begin{itemize}
  \item 
    The name, allocation, and type are available as forms that could appear in a
    \cdf{defclass} form.

  \item 
    The initialization form, if there is one, is available as a form that could
    appear in a \cdf{defclass} form. The initialization form together with its lexical
    environment is available as a function of no arguments which, when called,
    returns the result of evaluating the initialization form in its lexical
    environment. This is called the \emph{initfunction} of the slot.

  \item 
    The slot filling initialization arguments are available as a list of
    symbols. 

  \item 
    The documentation is available as a string or \cdf{nil}.

  \end{itemize}


Certain other information is only associated with direct slot definition
metaobjects. This information applies only to the direct definition of the slot
in the class (it is not inherited). 


  \begin{itemize}
  \item 
    The function names of those generic functions for which there are
    automatically generated reader and writer methods. This information is
    available as lists of function names. Any accessors specified in the
    \cdf{defclass} form are broken down into their equivalent readers and writers in
    the direct slot definition.
  \end{itemize}


Information, including inherited information, which applies to the definition of
a slot in a particular class in which it is accessible is associated only with
effective slot definition metaobjects. 


  \begin{itemize}
  \item 
    For certain slots, the location of the slot in instances of the class is
    available.
  \end{itemize}


\subsubsection{Generic Functions}

A \emph{generic function metaobject} contains information about a generic function over
and above the information associated with each of the generic function's
methods. 


  \begin{itemize}
  \item 
    The name is available as a function name.

  \item 
    The methods associated with the generic function are available as a list of
    method metaobjects. 

  \item 
    The default class for this generic function's method metaobjects is
    available as a class metaobject. 

  \item 
    The lambda list is available as a list.

  \item 
    The method combination is available as a method combination metaobject. 

  \item 
    The documentation is available as a string or \cdf{nil}.

  \item 
    The argument precedence order is available as a permutation of those symbols
    from the lambda list which name the required arguments of the generic
    function. 

  \item 
    The declarations are available as a list of declarations.

    \textbf{Terminology Note:} There is some ambiguity in Common Lisp about the
      terms used to identify the various parts of \cdf{declare} special operators. In this
      document, the term \emph{declaration} is used to refer to an object that could be
      an argument to a \cdf{declare} special operator. For example, in the special form
      \cd{(declare (special *g1*))}, the list \cd{(special *g1*)} is a declaration.
  \end{itemize}


\subsubsection{Methods}

A \emph{method metaobject} contains information about a specific method.


  \begin{itemize}
  \item 
    The qualifiers are available as a list of of non-null atoms.

  \item 
    The lambda list is available as a list.

  \item 
    The specializers are available as a list of specializer metaobjects. 

  \item 
    The function is available as a function. This function can be applied to
    arguments and a list of next methods using \emph{apply} or \emph{funcall}. 

  \item 
    When the method is associated with a generic function, that generic function
    metaobject is available. A method can be associated with at most one generic
    function at a time.

  \item 
    The documentation is available as a string or \cdf{nil}.
  \end{itemize}


\subsubsection{Specializers}

A \emph{specializer metaobject} represents the specializers of a method. Class
metaobjects are themselves specializer metaobjects. A special kind of
specializer metaobject is used for \emph{eql} specializers.

\subsubsection{Method Combinations}

A \emph{method combination metaobject} represents the information about the method
combination being used by a generic function. 

\textbf{Note:} This document does not specify the structure of method
combination metaobjects.  

\subsection{Inheritance Structure of Metaobject Classes}

The inheritance structure of the specified metaobject classes is shown in the
table~\ref{MOP-CLASSES}.

\begin{table}[t]
\caption{Direct superclass relationships among the specified metaobject classes}
\label{MOP-CLASSES}
\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\textbf{Metaobject Class}&\textbf{Direct Superclasses} \\
\hlinesp
standard-object&(t)\\
funcallable-standard-object&(standard-object function)\\
*metaobject&(standard-object)\\
*generic-function&(metaobject funcallable-standard-object)\\
standard-generic-function&(generic-function)\\
*method&(metaobject)\\
standard-method&(method)\\
*standard-accessor-method&(standard-method)\\
standard-reader-method&(standard-accessor-method)\\
standard-writer-method&(standard-accessor-method)\\
*method-combination&(metaobject)\\
*slot-definition&(metaobject)\\
*direct-slot-definition&(slot-definition)\\
*effective-slot-definition&(slot-definition)\\
*standard-slot-definition&(slot-definition)\\
standard-direct-slot-definition&(standard-slot-definition direct-slot-definition)\\
standard-effective-slot-definition&(standard-slot-definition effective-slot-definition)\\
*specializer&(metaobject)\\
eql-specializer&(specializer)\\
*class&(specializer)\\
built-in-class&(class)\\
forward-referenced-class&(class)\\
standard-class&(class)\\
funcallable-standard-class&(class)
\end{tabular}
\end{flushleft}

The class of every class shown is \cdf{standard-class} except for the class
\cdf{t} which is 
an instance of the class \cdf{built-in-class} and the classes
\cdf{generic-function} and 
\cdf{standard-generic-function} which are instances of the class
\cdf{funcallable-standard-class}.

[Each class marked with a ``*'' is an abstract class and is not intended to be
instantiated. The results are undefined if an attempt is made to make an
instance of one of these classes with \cdf{make-instance}.]
\end{table}

The classes \cdf{standard-class}, \cdf{standard-direct-slot-definition},
\cdf{standard-effective-slot-definition}, \cdf{standard-method},
\cdf{standard-reader-method}, 
\cdf{standard-writer-method} and \cdf{standard-generic-function} are called
\emph{standard 
  metaobject classes}. For each kind of metaobject, this is the class the user
interface macros presented in the CLOS Specification use by default. These are
also the classes on which user specializations are normally based.

The classes \cdf{built-in-class}, \cdf{funcallable-standard-class} and
\cdf{forward-referenced-class} are special-purpose class metaobject classes. Built-in
classes are instances of the class \cdf{built-in-class}. The class
\cdf{funcallable-standard-class} provides a special kind of instances described in the
section~\ref{FUNCALLABLE-INSTANCES}. When the definition of a class
references another class which has not yet been defined, an instance of
\cdf{forward-referenced-class} is used as a stand-in until the class is actually
defined. 

The class \cdf{standard-object} is the \emph{default direct superclass} of the class
\cdf{standard-class}. When an instance of the class \cdf{standard-class} is
created, and no 
direct superclasses are explicitly specified, it defaults to the class
\cdf{standard-object}. In this way, any behavior associated with the class
\cdf{standard-object} will be inherited, directly or indirectly, by all
instances of
the class \cdf{standard-class}. A subclass of \cdf{standard-class} may have a
different 
class as its default direct superclass, but that class must be a subclass of the
class \cdf{standard-object}. 

The same is true for \cdf{funcallable-standard-class} and
\cdf{funcallable-standard-object}. 

The class \cdf{specializer} captures only the most basic behavior of method
specializers, and is not itself intended to be instantiated. The class \cdf{class} is
a direct subclass of \cdf{specializer} reflecting the property that classes by
themselves can be used as method specializers. The class \cdf{eql-specializer} is used
for \cdf{eql} specializers. 

\subsubsection{Implementation and User Specialization}
\label{IMPLEMENTATION-AND-USER-SPECIALIZATION}

The purpose of the Metaobject Protocol is to provide users with a powerful
mechanism for extending and customizing the basic behavior of the Common Lisp
Object System. As an object-oriented description of the basic CLOS behavior, the
Metaobject Protocol makes it possible to create these extensions by defining
specialized subclasses of existing metaobject classes. 

The Metaobject Protocol provides this capability without interfering with the
implementor's ability to develop high-performance implementations. This balance
between user extensibility and implementor freedom is mediated by placing
explicit restrictions on each. Some of these restrictions are general---they
apply to the entire class graph and the applicability of all methods. These are
presented in this section. 

The following additional terminology is used to present these restrictions:


  \begin{itemize}
  \item 
    Metaobjects are divided into three categories. Those defined in this
    document are called \emph{specified}; those defined by an implementation but not
    mentioned in this document are called \emph{implementation-specific}; and those
    defined by a portable program are called \emph{portable}. 

  \item 
    A class $I$ is \emph{interposed} between two other classes $C_1$ and $C_2$ if and only if
    there is some path, following direct superclasses, from the class $C_1$ to the
    class $C_2$ which includes $I$. 
  \item 
    A method is \emph{specialized} to a class if and only if that class is in the list
    of specializers associated with the method; and the method is in the list of
    methods associated with some generic function. 
  \item 
    In a given implementation, a specified method is said to have been promoted
    if and only if the specializers of the method, $S_1 \ldots S_n$, are defined in
    this specification as the classes $C_1 \ldots C_n$, but in the implementation, one
    or more of the specializers $S_i$, is a superclass of the class given in the
    specification $C_i$. 
  \item 
    For a given generic function and set of arguments, a method $M_2$ extends a
    method $M_1$ if and only if: 

    \begin{itemize}
    \item 
        (i) $M_1$ and $M_2$ are both associated with the given generic function, 
      \item 
        (ii) $M_1$ and $M_2$ are both applicable to the given arguments, 
      \item 
        (iii) the specializers and qualifiers of the methods are such that when
        the generic function is called, $M_2$ is executed before $M_1$, 
      \item 
        (iv) $M_1$ will be executed if and only if \cdf{call-next-method} is invoked from
        within the body of $M_2$ and 
      \item 
        (v)\cdf{call-next-method} is invoked from within the body of $M_2$, thereby
        causing $M_1$ to be executed. 
      \end{itemize}

    \item 
    For a given generic function and set of arguments, a method $M_2$ overrides a
    method $M_1$ if and only if conditions i through iv above hold and 

    \begin{itemize}
    \item 
      (v') \cdf{call-next-method} is not invoked from within the body of $M_2$, thereby
      preventing $M_1$ from being executed. 
    \end{itemize}
  \end{itemize}


\subsubsection{Restrictions on Implementations}

Implementations are allowed latitude to modify the structure of specified
classes and methods. This includes: the interposition of implementation-specific
classes; the promotion of specified methods; and the consolidation of two or
more specified methods into a single method specialized to interposed classes. 

Any such modifications are permitted only so long as for any portable class Cp
that is a subclass of one or more specified classes $C_0 \ldots C_i$, the following
conditions are met: 


  \begin{itemize}
  \item 
    In the actual class precedence list of $C_p$, the classes $C_0 \ldots C_i$ must appear
    in the same order as they would have if no implementation-specific
    modifications had been made. 
  \item 
    The method applicability of any specified generic function must be the same
    in terms of behavior as it would have been had no implementation-specific
    changes been made. This includes specified generic functions that have had
    portable methods added. In this context, the expression ``the same in terms
    of behavior'' means that methods with the same behavior as those specified
    are applicable, and in the same order. 
  \item 
    No portable class $C_p$ may inherit, by virtue of being a direct or indirect
    subclass of a specified class, any slot for which the name is a symbol
    accessible in the \cdf{common-lisp-user} package or exported by any package
    defined in the ANSI Common Lisp standard. 
  \item 
    Implementations are free to define implementation-specific before- and
    after-methods on specified generic functions. Implementations are also free
    to define implementation-specific around-methods with extending behavior. 
  \end{itemize}


\subsubsection{Restrictions on Portable Programs}

Portable programs are allowed to define subclasses of specified classes, and are
permitted to define methods on specified generic functions, with the following
restrictions. The results are undefined if any of these restrictions is
violated. 


  \begin{itemize}
  \item Portable programs must not redefine any specified classes, generic
    functions, methods or method combinations. Any method defined by a portable
    program on a specified generic function must have at least one specializer
    that is neither a specified class nor an \cdf{eql} specializer whose
    associated value is an instance of a specified class.

  \item Portable programs may define methods that extend specified methods
    unless the description of the specified method explicitly prohibits
    this. Unless there is a specific statement to the contrary, these extending
    methods must return whatever value was returned by the call to
    \cdf{call-next-method}.

  \item Portable programs may define methods that override specified methods
    only when the description of the specified method explicitly allows
    this. Typically, when a method is allowed to be overridden, a small number
    of related methods will need to be overridden as well.

  \item An example of this is the specified methods on the generic functions
    \cdf{add-dependent}, \cdf{remove-dependent} and
    \cdf{map-dependents}. Overriding a specified
    method on one of these generic functions requires that the corresponding
    method on the other two generic functions be overridden as well.

  \item Portable methods on specified generic functions specialized to portable
    metaobject classes must be defined before any instances of those classes (or
    any subclasses) are created, either directly or indirectly by a call to
    \cdf{make-instance}. Methods can be defined after instances are created by
    \cdf{allocate-instance} however. Portable metaobject classes cannot be
    redefined.

    \textbf{Implementation Note:} The purpose of this last restriction is to
    permit implementations to provide performance optimizations by analyzing, at
    the time the first instance of a metaobject class is initialized, what
    portable methods will be applicable to it. This can make it possible to
    optimize calls to those specified generic functions which would have no
    applicable portable methods. 

    \textbf{Note:} The specification technology used in this document needs
    further development. The concepts of object-oriented protocols and subclass
    specialization are intuitively familiar to programmers of object-oriented
    systems; the protocols presented here fit quite naturally into this
    framework. Nonetheless, in preparing this document, we have found it
    difficult to give specification-quality descriptions of the protocols in a
    way that makes it clear what extensions users can and cannot
    write. Object-oriented protocol specification is inherently about specifying
    leeway, and this seems difficult using current technology. 
  \end{itemize}


\subsection{Processing of the User Interface Macros}

A list in which the first element is one of the symbols \cdf{defclass}, \cdf{defmethod},
\cdf{defgeneric}, or \cdf{define-method-combination}, and which has proper syntax for that
macro is called a \emph{user interface macro form}. This document provides an extended
specification of the \cdf{defclass}, \cdf{defmethod} and \cdf{defgeneric} macros. 

The user interface macros \cdf{defclass}, \cdf{defgeneric} and \cdf{defmethod} can be used not
only to define metaobjects that are instances of the corresponding standard
metaobject class, but also to define metaobjects that are instances of
appropriate portable metaobject classes. To make it possible for portable
metaobject classes to properly process the information appearing in the macro
form, this document provides a limited specification of the processing of these
macro forms. 

User interface macro forms can be \emph{evaluated} or \emph{compiled} and later
\emph{executed}. The 
effect of evaluating or executing a user interface macro form is specified in
terms of calls to specified functions and generic functions which provide the
actual behavior of the macro. The arguments received by these functions and
generic functions are derived in a specified way from the macro form. 

Converting a user interface macro form into the arguments to the appropriate
functions and generic functions has two major aspects: the conversion of the
macro argument syntax into a form more suitable for later processing, and the
processing of macro arguments which are forms to be evaluated (including method
bodies). 

In the syntax of the \cdf{defclass} macro, the \emph{initform} and
\emph{default-initarg-initial-value-form} arguments are forms which will be evaluated
one or more times after the macro form is evaluated or executed. Special
processing must be done on these arguments to ensure that the lexical scope of
the forms is captured properly. This is done by building a function of zero
arguments which, when called, returns the result of evaluating the form in the
proper lexical environment. 

In the syntax of the \cdf{defmethod} macro the \emph{form*} argument is a list of forms that
comprise the body of the method definition. This list of forms must be processed
specially to capture the lexical scope of the macro form. In addition, the
lexical functions available only in the body of methods must be introduced. To
allow this and any other special processing (such as slot access optimization),
a specializable protocol is used for processing the body of methods. This is
discussed in the section~\ref{PROCESSING-METHOD-BODIES}.

\subsubsection{Compile-file Processing of the User Interface Macros}

It is common practice for Common Lisp compilers, while processing a file or set
of files, to maintain information about the definitions that have been compiled
so far. Among other things, this makes it possible to ensure that a global macro
definition (\cdf{defmacro} form) which appears in a file will affect uses of the
macro 
later in that file. This information about the state of the compilation is
called the \emph{compile-file environment}. 

When compiling files containing CLOS definitions, it is useful to maintain
certain additional information in the compile-file environment. This can make it
possible to issue various kinds of warnings (e.g., lambda list congruence) and
to do various performance optimizations that would not otherwise be possible. 

At this time, there is such significant variance in the way existing Common Lisp
implementations handle compile-file environments that it would be premature to
specify this mechanism. Consequently, this document specifies only the behavior
of evaluating or executing user interface macro forms. What functions and
generic functions are called during compile-file processing of a user interface
macro form is not specified. Implementations are free to define and document
their own behavior. Users may need to check implementation-specific behavior
before attempting to compile certain portable programs.

\subsubsection{The \cdf{defclass} Macro}

A \cdf{defclass} form with standard slot and class options and an expansion of it that
would result in the proper call to \cdf{ensure-class}.

\begin{lisp}
(defclass plane (moving-object graphics-object)\\*
~~~~~((altitude :initform 0 :accessor plane-altitude)\\*
~~~~~~(speed))\\*
~~(:default-initargs :engine *jet*))\\*
\\
(ensure-class\\*
~~'plane\\*
~~':direct-superclasses\\*
~~'(moving-object graphics-object)\\*
~~':direct-slots (list (list ':name 'altitude\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ':initform '0\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ':initfunction \#'(lambda () 0)\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ':readers '(plane-altitude)\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ':writers '((setf plane-altitude)))\\*
~~~~~~~~~~~~~~~~~~~~~~ (list ':name 'speed))\\*
~~':direct-default-initargs (list (list ':engine '*jet* \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\#'(lambda () *jet*))))\\*
\end{lisp}

A \cdf{defclass} form with non-standard class and slot options, and an
  expansion of it which results in the proper call to \cdf{ensure-class}.

Note that the order of the slot options has not affected the order of the
properties in the canonicalized slot specification, but has affected the order
of the elements in the lists which are the values of those properties. 

\begin{lisp}
(defclass sst (plane)\\*
~~~~ ((mach mag-step 2\\*
~~~~~~~~~~~~locator sst-mach\\*
~~~~~~~~~~~~locator mach-location\\*
~~~~~~~~~~~~:reader mach-speed\\*
~~~~~~~~~~~~:reader mach))\\*
~~(:metaclass faster-class)\\*
~~(another-option foo bar))\\*
\\
(ensure-class 'sst\\*
~~':direct-superclasses\\*
~~'(plane)\\*
~~':direct-slots (list (list ':name 'mach\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ':readers '(mach-speed mach)\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 'mag-step '2\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 'locator '(sst-mach mach-location)))\\*
~~':metaclass 'faster-class\\*
~~'another-option '(foo bar))\\*
\end{lisp}

The evaluation or execution of a \cdf{defclass} form results in a call to the
ensure-class function. The arguments received by \cdf{ensure-class} are derived from
the \cdf{defclass} form in a defined way. The exact macro-expansion of the \cdf{defclass}
form is not defined, only the relationship between the arguments to the \cdf{defclass}
macro and the arguments received by the \cdf{ensure-class} function. Examples of
typical \cdf{defclass} forms and sample expansions are shown in precedence examples.


  \begin{itemize}
  \item 
    The \emph{name} argument to \cdf{defclass} becomes the value of the first argument to
    \cdf{ensure-class}. This is the only positional argument accepted by \cdf{ensure-class};
    all other arguments are keyword arguments. 
  \item 
    The \emph{direct-superclasses} argument to \cdf{defclass} becomes the value of the
    \cd{:direct-superclasses} keyword argument to \cdf{ensure-class}. 
  \item 
    The \emph{direct slots} argument to \cdf{defclass} becomes the value of the :direct-slots
    keyword argument to \cdf{ensure-class}. Special processing of this value is done
    to regularize the form of each slot specification and to properly capture
    the lexical scope of the initialization forms. This is done by converting
    each slot specification to a property list called a \emph{canonicalized slot
      specification}. The resulting list of canonicalized slot specifications is
    the value of the \cd{:direct-slots} keyword argument. 

    Canonicalized slot specifications are later used as the keyword arguments to
    a generic function which will, in turn, pass them to \cdf{make-instance} for use
    as a set of initialization arguments. Each canonicalized slot specification
    is formed from the corresponding slot specification as follows:

    \begin{itemize}
    \item 
        The name of the slot is the value of the \cd{:name} property. This property
        appears in every canonicalized slot specification. 
      \item 
        When the \cd{:initform} slot option is present in the slot specification,
        then both the \cd{:initform} and \cd{:initfunction} properties are
        present in the 
        canonicalized slot specification. The value of the \cd{:initform} property is
        the initialization form. The value of the \cd{:initfunction} property is a
        function of zero arguments which, when called, returns the result of
        evaluating the initialization form in its proper lexical environment. 
      \item 
        If the \cd{:initform} slot option is not present in the slot specification,
        then either the \cd{:initfunction} property will not appear, or its value
        will be false. In such cases, the value of the \cd{:initform} property, or
        whether it appears, is unspecified. 
      \item 
        The value of the \cd{:initargs} property is a list of the values of each
        \cd{:initarg} slot option. If there are no \cd{:initarg} slot options, then either
        the \cd{:initargs} property will not appear or its value will be the empty
        list. 
      \item 
        The value of the \cd{:readers} property is a list of the values of each
        \cd{:reader} and \cd{:accessor} slot option. If there are no
        \cd{:reader} or \cd{:accessor} 
        slot options, then either the \cd{:readers} property will not appear or its
        value will be the empty list. 
      \item 
        The value of the \cd{:writers} property is a list of the values specified by
        each \cd{:writer} and \cd{:accessor} slot option. The value specified by
        a \cd{:writer} 
        slot option is just the value of the slot option. The value specified by
        an \cd{:accessor} slot option is a two element list: the first element is the
        symbol setf, the second element is the value of the slot option. If
        there are no \cd{:writer} or \cd{:accessor} slot options, then either
        the \cd{:writers} 
        property will not appear or its value will be the empty list. 
      \item 
        The value of the \cd{:documentation} property is the value of the
        \cd{:documentation} slot option. If there is no \cd{:documentation} slot option,
        then either the \cd{:documentation} property will not appear or its value
        will be false. 
      \item 
        All other slot options appear as the values of properties with the same
        name as the slot option. Note that this includes not only the remaining
        standard slot options (\cd{:allocation} and \cd{:type}), but also any other
        options and values appearing in the slot specification. If one of these
        slot options appears more than once, the value of the property will be a
        list of the specified values. 
      \item 
        An implementation is free to add additional properties to the
        canonicalized slot specification provided these are not symbols
        accessible in the common-lisp-user package, or exported by any package
        defined in the ANSI Common Lisp standard.  
      \end{itemize}

    Returning to the correspondence between arguments to the \cdf{defclass} macro and
    the arguments received by the \cdf{ensure-class} function: 

    \item 
    The \emph{default initargs} class option, if it is present in the \cdf{defclass} form,
    becomes the value of the \cd{:direct-default-initargs} keyword argument to
    \cdf{ensure-class}. Special processing of this value is done to properly capture
    the lexical scope of the default value forms. This is done by converting
    each default initarg in the class option into a canonicalized default
    initarg. The resulting list of canonicalized default initargs is the value
    of the \cd{:direct-default-initargs} keyword argument to \cdf{ensure-class}. 

    A canonicalized default initarg is a list of three elements. The first
    element is the name; the second is the actual form itself; and the third is
    a function of zero arguments which, when called, returns the result of
    evaluating the default value form in its proper lexical environment. 

  \item 
    The \emph{metaclass} class option, if it is present in the \cdf{defclass} form, becomes
    the value of the \cd{:metaclass} keyword argument to \cdf{ensure-class}. 

  \item 
    The \emph{documentation} class option, if it is present in the \cdf{defclass} form,
    becomes the value of the \cd{:documentation} keyword argument to \cdf{ensure-class}. 

  \item 
    Any other class options become the value of keyword arguments with the same
    name. The value of the keyword argument is the tail of the class option. An
    error is signaled if any class option appears more than once in the \cdf{defclass}
    form. 
  \end{itemize}


In the call to \cdf{ensure-class}, every element of its arguments appears in the same
left-to-right order as the corresponding element of the \cdf{defclass} form, except
that the order of the properties of canonicalized slot specifications is
unspecified. The values of properties in canonicalized slot specifications do
follow this ordering requirement. Other ordering relationships in the keyword
arguments to \cdf{ensure-class} are unspecified. 

The result of the call to \cdf{ensure-class} is returned as the result of evaluating
or executing the \cdf{defclass} form. 

\subsubsection{The \cdf{defmethod} Macro}

The evaluation or execution of a \cdf{defmethod} form requires first that the body of
the method be converted to a method function. This process is described in the
next section. The result of this process is a method function and a set of
additional initialization arguments to be used when creating the new
method. Given these two values, the evaluation or execution of a \cdf{defmethod} form
proceeds in three steps. 

The first step ensures the existence of a generic function with the specified
name. This is done by calling the function ensure-generic-function. The first
argument in this call is the generic function name specified in the \cdf{defmethod}
form. 

The second step is the creation of the new method metaobject by calling
make-instance. The class of the new method metaobject is determined by calling
\cdf{generic-function-method-class} on the result of the call to
\cdf{ensure-generic-function} from the first step. 

The initialization arguments received by the call to \cdf{make-instance} are as
follows: 


  \begin{itemize}
  \item 
    The value of the \cd{:qualifiers} initialization argument is a list of the
    qualifiers which appeared in the \cdf{defmethod} form. No special processing is
    done on these values. The order of the elements of this list is the same as
    in the \cdf{defmethod} form. 

  \item 
    The value of the \cd{:lambda-list} initialization argument is the unspecialized
    lambda list from the \cdf{defmethod} form. 
  \item 
    The value of the \cd{:specializers} initialization argument is a list of the
    specializers for the method. For specializers which are classes, the
    specializer is the class metaobject itself. In the case of \cdf{eql} specializers,
    it will be an \cdf{eql-specializer} metaobject obtained by calling
    \cdf{intern-eql-specializer} on the result of evaluating the \cdf{eql} specializer form
    in the lexical environment of the \cdf{defmethod} form. 
  \item 
    The value of the \cd{:function} initialization argument is the method function. 
  \item 
    The value of the \cd{:declarations} initialization argument is a list of the
    declarations from the \cdf{defmethod} form. If there are no declarations in the
    macro form, this initialization argument either doesn't appear, or appears
    with a value of the empty list. 
  \item 
    The value of the \cd{:documentation} initialization argument is the documentation
    string from the \cdf{defmethod} form. If there is no documentation string in the
    macro form this initialization argument either doesn't appear, or appears
    with a value of false. 
  \item 
    Any other initialization argument produced in conjunction with the method
    function are also included. 
  \item 
    The implementation is free to include additional initialization arguments
    provided these are not symbols accessible in the \cdf{common-lisp-user}
    package, 
    or exported by any package defined in the ANSI Common Lisp standard. 
  \end{itemize}

In the third step, \cdf{add-method} is called to add the newly created method to the
set of methods associated with the generic function metaobject. 

The result of the call to \cdf{add-method} is returned as the result of evaluating or
executing the \cdf{defmethod} form. 

An example \cdf{defmethod} form and one possible correct expansion.
In the expansion, method-lambda is the result of calling \cdf{make-method-lambda} as
described in the section~\ref{PROCESSING-METHOD-BODIES}. The initargs appearing
after :function are assumed to be additional initargs returned from the call to
\cdf{make-method-lambda}. 

\begin{figure}
\caption{Example 3}
\label{example-3}
\begin{lisp}
(defmethod move :before ((p position) (l (eql 0))\\*
~~~~~~~~~~~~~~~~~~~~~~~~~\&optional (visiblyp t)\\*
~~~~~~~~~~~~~~~~~~~~~~~~~\&key color)\\*
~~(set-to-origin p)\\*
~~(when visiblyp (show-move p 0 color)))\\*
\\
(let ((\#:g001 (ensure-generic-function 'move)))\\*
~~(add-method \#:g001\\*
~~~~(make-instance (generic-function-method-class \#:g001)\\*
~~~~~~~~~~~~~~~~~~~':qualifiers '(:before)\\*
~~~~~~~~~~~~~~~~~~~':specializers (list (find-class 'position)\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(intern-eql-specializer 0))\\*
~~~~~~~~~~~~~~~~~~~':lambda-list '(p l \&optional (visiblyp t)\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\&key color)\\*
~~~~~~~~~~~~~~~~~~~':function (function~~method-lambda)\\*
~~~~~~~~~~~~~~~~~~~'additional-initarg-1 't\\*
~~~~~~~~~~~~~~~~~~~'additional-initarg-2 '39)))\\*
\end{lisp}
\end{figure}

An example showing a typical \cdf{defmethod} form and a sample expansion is
shown in~\ref{example-3}. The processing of the method body for this method is shown in~\ref{example-4}.

\subsubsection{Processing Method Bodies}
\label{PROCESSING-METHOD-BODIES}

Before a method can be created, the list of forms comprising the method body
must be converted to a method function. This conversion is a two step process.

\textbf{Note:} The body of methods can also appear in the \cd{:initial-methods}
option of \cdf{defgeneric} forms. Initial methods are not considered by any of the
protocols specified in this document.

During macro-expansion of the \cdf{defmethod} macro shown in~\ref{example-3}, code
similar to this would be run to produce the method lambda and additional
initargs.  In this example, \emph{environment} is the macroexpansion environment
of the \cdf{defmethod} macro form.

\begin{figure}
\caption{Example 4}
\label{example-4}
\begin{lisp}
(let ((gf (ensure-generic-function 'move)))\\*
~~(make-method-lambda\\*
~~~~gf\\*
~~~~(class-prototype (generic-function-method-class gf))\\*
~~~~'(lambda (p l \&optional (visiblyp t) \&key color)\\*
~~~~~~ (set-to-origin p)\\*
~~~~~~ (when visiblyp (show-move p 0 color)))\\*
~~ environment))\\*
\end{lisp}
\end{figure} 

The first step occurs during macro-expansion of the macro form. In this step,
the method lambda list, declarations and body are converted to a lambda
expression called a \emph{method lambda}. This conversion is based on information
associated with the generic function definition in effect at the time the macro
form is expanded. 

The generic function definition is obtained by calling
\cdf{ensure-generic-function} with a first argument of the generic function name
specified in the macro form. The \cd{:lambda-list} keyword argument is not
passed in this call.

Given the generic function, production of the method lambda proceeds by calling
make-method-lambda. The first argument in this call is the generic function
obtained as described above. The second argument is the result of calling
\cdf{class-prototype} on the result of calling
\cdf{generic-function-method-class} on the generic function. The third argument
is a lambda expression formed from the method lambda list, declarations and
body. The fourth argument is the macro-expansion environment of the macro form;
this is the value of the \cd{\&environment} argument to the \cdf{defmethod}
macro.

The generic function \cdf{make-method-lambda} returns two values. The first is
the method lambda itself. The second is a list of initialization arguments and
values. These are included in the initialization arguments when the method is
created.

In the second step, the method lambda is converted to a function which properly
captures the lexical scope of the macro form. This is done by having the method
lambda appear in the macro-expansion as the argument of the function special
form. During the subsequent evaluation of the macro-expansion, the result of the
function special operator is the method function.

\subsubsection{The \cdf{defgeneric} Macro}

The evaluation or execution of a \cdf{defgeneric} form results in a call to the
\cdf{ensure-generic-function} function. The arguments received by
\cdf{ensure-generic-function} are derived from the \cdf{defgeneric} form in a defined
way. As with \cdf{defclass} and \cdf{defmethod}, the exact macro-expansion of the \cdf{defgeneric}
form is not defined, only the relationship between the arguments to the macro
and the arguments received by \cdf{ensure-generic-function}.


  \begin{itemize}
  \item The \emph{function-name} argument to \cdf{defgeneric} becomes the first
    argument to ensure-generic-function. This is the only positional argument
    accepted by ensure-generic-function; all other arguments are keyword
    arguments.

  \item The \emph{lambda-list} argument to \cdf{defgeneric} becomes the value of
    the :lambda-list keyword argument to ensure-generic-function.

  \item For each of the options \cd{:argument-precedence-order},
    \cd{:documentation}, \cd{:generic-function-class} and \cd{:method-class},
    the value of the option becomes the value of the keyword argument with the
    same name. If the option does not appear in the macro form, the keyword
    argument does not appear in the resulting call to ensure-generic-function.

  \item For the option declare, the list of declarations becomes the value of
    the \cd{:declarations} keyword argument. If the declare option does not
    appear in the macro form, the \cd{:declarations} keyword argument does not
    appear in the call to ensure-generic-function.

  \item The handling of the \cd{:method-combination} option is not specified.
  \end{itemize}


The result of the call to \cdf{ensure-generic-function} is returned as the result of
evaluating or executing the \cdf{defgeneric} form.

\subsection{Subprotocols}

This section provides an overview of the Metaobject Protocols. The detailed
behavior of each function, generic function and macro in the Metaobject Protocol
is presented in the Generic Functions and Methods Dictionary. The remainder of
this chapter is intended to emphasize connections among the parts of the
Metaobject Protocol, and to provide some examples of the kinds of
specializations and extensions the protocols are designed to support.

\subsubsection{Metaobject Initialization Protocols}

Like other objects, metaobjects can be created by calling \cdf{make-instance}. The
initialization arguments passed to \cdf{make-instance} are used to initialize the
metaobject in the usual way. The set of legal initialization arguments, and
their interpretation, depends on the kind of metaobject being
created. Implementations and portable programs are free to extend the set of
legal initialization arguments. Detailed information about the initialization of
each kind of metaobject are provided in Generic Functions and Methods
Dictionary; this section provides an overview and examples of this behavior. 

\textbf{Initialization of Class Metaobjects}

Class metaobjects created with \cdf{make-instance} are usually \emph{anonymous}; that is,
they have no proper name. An anonymous class metaobject can be given a proper
name using \cdf{{setf find-class}} and \cdf{{setf class-name}}. 

When a class metaobject is created with \cdf{make-instance}, it is initialized in the
usual way. The initialization arguments passed to \cdf{make-instance} are use to
establish the definition of the class. Each initialization argument is checked
for errors and associated with the class metaobject. The initialization
arguments correspond roughly to the arguments accepted by the \cdf{defclass} macro,
and more closely to the arguments accepted by the \cdf{ensure-class} function. 

Some class metaobject classes allow their instances to be redefined. When
permissible, this is done by calling \cdf{reinitialize-instance}. This is
discussed in the next section.

An example of creating an anonymous class directly using \cdf{make-instance} follows:

\begin{lisp}
(flet ((zero () 0)\\*
~~~~~~ (propellor () *propellor*))\\*
~~(make-instance 'standard-class\\*
~~~~:name '(my-class foo)\\*
~~~~:direct-superclasses (list (find-class 'plane)\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~another-anonymous-class)\\*
~~~~:direct-slots `((:name x\\*
~~~~~~~~~~~~~~~~~~~~ :initform 0\\*
~~~~~~~~~~~~~~~~~~~~ :initfunction ,\#'zero\\*
~~~~~~~~~~~~~~~~~~~~ :initargs (:x)\\*
~~~~~~~~~~~~~~~~~~~~ :readers (position-x)\\*
~~~~~~~~~~~~~~~~~~~~ :writers ((setf position-x)))\\*
~~~~~~~~~~~~~~~~~~~~(:name y\\*
~~~~~~~~~~~~~~~~~~~~ :initform 0\\*
~~~~~~~~~~~~~~~~~~~~ :initfunction ,\#'zero\\*
~~~~~~~~~~~~~~~~~~~~ :initargs (:y)\\*
~~~~~~~~~~~~~~~~~~~~ :readers (position-y)\\*
~~~~~~~~~~~~~~~~~~~~ :writers ((setf position-y))))\\*
~~~~:direct-default-initargs `((:engine *propellor* ,\#'propellor))))\\*
\end{lisp}
  
\textbf{Reinitialization of Class Metaobjects}

Some class metaobject classes allow their instances to be reinitialized. This is
done by calling \cdf{reinitialize-instance}. The initialization arguments have the
same interpretation as in class initialization. 

If the class metaobject was finalized before the call to \cdf{reinitialize-instance},
\cdf{finalize-inheritance} will be called again once all the initialization arguments
have been processed and associated with the class metaobject. In addition, once
finalization is complete, any dependents of the class metaobject will be updated
by calling \cdf{update-dependent}. 

\textbf{Initialization of Generic Function and Method Metaobjects}

An example of creating a generic function and a method metaobject, and then
adding the method to the generic function is shown below. This example is
comparable to the method definition shown in~\ref{example-3}.

\begin{lisp}
(let* ((gf (make-instance 'standard-generic-function\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~:lambda-list '(p l \&optional visiblyp \&key)))\\*
~~~~~~ (method-class (generic-function-method-class gf)))\\*
~~(multiple-value-bind (lambda initargs)\\*
~~~~~~ (make-method-lambda\\*
~~~~~~~~ gf\\*
~~~~~~~~ (class-prototype method-class)\\*
~~~~~~~~ '(lambda (p l \&optional (visiblyp t) \&key color)\\*
~~~~~~~~~~~~(set-to-origin p)\\*
~~~~~~~~~~~~(when visiblyp (show-move p 0 color)))\\*
~~~~~~~~ nil)\\*
~~~~(add-method gf\\*
~~~~~~~~~~~~~~~~(apply \#'make-instance method-class\\*
~~~~~~~~~~~~~~~~~~~~~~ :function (compile nil lambda)\\*
~~~~~~~~~~~~~~~~~~~~~~ :specializers (list (find-class 'position)\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (intern-eql-specializer 0))\\*
~~~~~~~~~~~~~~~~~~~~~~ :qualifiers ()\\*
~~~~~~~~~~~~~~~~~~~~~~ :lambda-list '(p l \&optional (visiblyp t)\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\&key color)\\*
~~~~~~~~~~~~~~~~~~~~~~ initargs))))\\*
\end{lisp}
                     
\subsubsection{Class Finalization Protocol}
\label{CLASS-FINALIZATION-PROTOCOL}

Class \emph{finalization} is the process of computing the information a class inherits
from its superclasses and preparing to actually allocate instances of the
class. The class finalization process includes computing the class's class
precedence list, the full set of slots accessible in instances of the class and
the full set of default initialization arguments for the class. These values are
associated with the class metaobject and can be accessed by calling the
appropriate reader. In addition, the class finalization process makes decisions
about how instances of the class will be implemented. 

To support forward-referenced superclasses, and to account for the fact that not
all classes are actually instantiated, class finalization is not done as part of
the initialization of the class metaobject. Instead, finalization is done as a
separate protocol, invoked by calling the generic function
\cdf{finalize-inheritance}. The exact point at which \cdf{finalize-inheritance}
is called depends on the class of the class metaobject; for standard-class it is
called sometime after all the classes superclasses are defined, but no later
than when the first instance of the class is allocated (by
\cdf{allocate-instance}).

The first step of class finalization is computing the class precedence
list. Doing this first allows subsequent steps to access the class precedence
list. This step is performed by calling the generic function
\cdf{compute-class-precedence-list}. The value returned from this call is associated
with the class metaobject and can be accessed by calling the
\cdf{class-precedence-list} generic function. 

The second step is computing the full set of slots that will be accessible in
instances of the class. This step is performed by calling the generic function
compute-slots. The result of this call is a list of effective slot definition
metaobjects. This value is associated with the class metaobject and can be
accessed by calling the \cdf{class-slots} generic function. 

The behavior of \cdf{compute-slots} is itself layered, consisting of calls to
\cdf{effective-slot-definition-class} and \cdf{compute-effective-slot-definition}. 

The final step of class finalization is computing the full set of initialization
arguments for the class. This is done by calling the generic function
\cdf{compute-default-initargs}. The value returned by this generic function is
associated with the class metaobject and can be accessed by calling
\cdf{class-default-initargs}. 

If the class was previously finalized, \cdf{finalize-inheritance} may call
\cdf{make-instances-obsolete}. The circumstances under which this happens are describe
in the section~\ref{Redefining-Classes-SECTION} of the CLOS specification.

Forward-referenced classes, which provide a temporary definition for a class
which has been referenced but not yet defined, can never be finalized. An error
is signalled if \cdf{finalize-inheritance} is called on a forward-referenced class. 

\subsubsection{Instance Structure Protocol}
\label{INSTANCE-STRUCTURE-PROTOCOL}

The instance structure protocol is responsible for implementing the behavior of
the slot access functions like slot-value and (setf slot-value). 

For each CLOS slot access function other than slot-exists-p, there is a
corresponding generic function which actually provides the behavior of the
function. When called, the slot access function finds the pertinent effective
slot definition metaobject, calls the corresponding generic function and returns
its result. The arguments passed on to the generic function include one
additional value, the class of the \emph{object} argument, which always immediately
precedes the \emph{object} argument 

The correspondences between slot access function and underlying slot access
generic function are as follows: 

\begin{tabular}{|@{}l|l@{}|}
\textbf{Slot Access Function}&\textbf{Corresponding Slot Access Generic Function}\\
slot-boundp&slot-boundp-using-class\\
slot-makunbound&slot-makunbound-using-class\\
slot-value&slot-value-using-class\\
(setf slot-value)&(setf slot-value-using-class)\\
\end{tabular}

At the lowest level, the instance structure protocol provides only limited
mechanisms for portable programs to control the implementation of instances and
to directly access the storage associated with instances without going through
the indirection of slot access. This is done to allow portable programs to
perform certain commonly requested slot access optimizations. 

In particular, portable programs can control the implementation of, and obtain
direct access to, slots with allocation \cd{:instance} and type \cdf{t}. These are called
directly accessible slots. 

The relevant specified around-method on \cdf{compute-slots} determines the
implementation of instances by deciding how each slot in the instance will be
stored. For each directly accessible slot, this method allocates a location and
associates it with the effective slot definition metaobject. The location can be
accessed by calling the slot-definition-location generic function. Locations are
non-negative integers. For a given class, the locations increase consecutively,
in the order that the directly accessible slots appear in the list of effective
slots. (Note that here, the next paragraph, and the specification of this
around-method are the only places where the value returned by \cdf{compute-slots} is
described as a list rather than a set.) 

Given the location of a directly accessible slot, the value of that slot in an
instance can be accessed with the appropriate accessor. For \cdf{standard-class}, this
accessor is the function \cdf{standard-instance-access}. For
\cdf{funcallable-standard-class}, this accessor is the function
\cdf{funcallable-standard-instance-access}. In each case, the arguments to the
accessor are the instance and the slot location, in that order. See the
definition of each accessor in Chapter for additional restrictions on the use of
these function. 

Portable programs are permitted to affect and rely on the allocation of
locations only in the following limited way: By first defining a portable
primary method on \cdf{compute-slots} which orders the returned value in a predictable
way, and then relying on the defined behavior of the specified around-method to
assign locations to all directly accessible slots. Portable programs may
compile-in calls to low-level accessors which take advantage of the resulting
predictable allocation of slot locations. 

The following example shows the use of this mechanism to implement a new class
metaobject class, \cdf{ordered-class} and class option \cd{:slot-order}. This option
provides control over the allocation of slot locations. In this simple example
implementation, the \cd{:slot-order} option is not inherited by subclasses; it
controls only instances of the class itself. 

\begin{lisp}
(defclass ordered-class (standard-class)\\*
~~~~ ((slot-order :initform ()\\*
~~~~~~~~~~~~~~~~~~:initarg :slot-order\\*
~~~~~~~~~~~~~~~~~~:reader class-slot-order)))\\*
\\
(defmethod \cdf{compute-slots} ((class ordered-class)) \\*
~~(let ((order (class-slot-order class)))\\*
~~~~(sort (copy-list (\cdf{call-next-method}))\\*
~~~~~~~~~~\#'(lambda (a b) (< (position (slot-definition-name a) order) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (position (slot-definition-name b) order))))))\\*
\end{lisp}

Following is the source code the user of this extension would write. Note that
because the code above doesn't implement inheritance of the \cdf{:slot-order} option,
the function \cd{distance} must not be called on instances of subclasses of \cdf{point}; it
can only be called on instances of \cdf{point} itself.

\begin{lisp}
(defclass point ()\\*
~~~~ ((x :initform 0)\\*
~~~~~~(y :initform 0))\\*
~~(:metaclass ordered-class)\\*
~~(:slot-order x y))\\*
\\
(defun distance (point)\\*
~~(sqrt (/ (+ (expt (standard-instance-access point 0) 2)\\*
~~~~~~~~~~ (expt (standard-instance-access point 1) 2)) 2.0)))\\*
\end{lisp}

In more realistic uses of this mechanism, the calls to the low-level instance
structure accessors would not actually appear textually in the source program,
but rather would be generated by a meta-level analysis program run during the
process of compiling the source program. 

\subsubsection{Funcallable Instances}
\label{FUNCALLABLE-INSTANCES}

Instances of classes which are themselves instances of
\cdf{funcallable-standard-class} or one of its subclasses are called funcallable
instances. Funcallable instances can only be created by \cdf{allocate-instance}
(funcallable-standard-class). 

Like standard instances, funcallable instances have slots with the normal
behavior. They differ from standard instances in that they can be used as
functions as well; that is, they can be passed to funcall and apply, and they
can be stored as the definition of a function name. Associated with each
funcallable instance is the function which it runs when it is called. This
function can be changed with \cdf{set-funcallable-instance-function}. 

The following simple example shows the use of funcallable instances to create a
simple, \cdf{defstruct}-like facility. (Funcallable instances are useful when a
program needs to construct and maintain a set of functions and information about
those functions. They make it possible to maintain both as the same object
rather than two separate objects linked, for example, by hash tables.) 

\begin{lisp}
(defclass constructor ()\\*
~~~~ ((name :initarg :name :accessor constructor-name)\\*
~~~~~~(fields :initarg :fields :accessor constructor-fields))\\*
~~(:metaclass funcallable-standard-class))\\*
\\
(defmethod initialize-instance :after ((c constructor) \&key)\\*
~~(with-slots (name fields) c \\*
~~~~(set-funcallable-instance-function \\*
~~~~~~c \\*
~~~~~~\#'(lambda ()\\*
~~~~~~~~~~(let ((new (make-array (1+ (length fields)))))\\*
~~~~~~~~~~~~(setf (aref new 0) name) new)))))\\*
\\
(setq c1 (make-instance 'constructor :name 'position :fields '(x y)))\\*
\#<CONSTRUCTOR 262437>\\*
\\
(setq p1 (funcall c1))\\*
\#<ARRAY 3 263674>\\*
\end{lisp}

\subsubsection{Generic Function Invocation Protocol}

Associated with each generic function is its discriminating function. Each time
the generic function is called, the discriminating function is called to provide
the behavior of the generic function. The discriminating function receives the
full set of arguments received by the generic function. It must lookup and
execute the appropriate methods, and return the appropriate values. 

The discriminating function is computed by the highest layer of the generic
function invocation protocol, \cdf{compute-discriminating-function}. Whenever a
generic function metaobject is initialized, reinitialized, or a method is added
or removed, the discriminating function is recomputed. The new discriminating
function is then stored with \cdf{set-funcallable-instance-function}. 

Discriminating functions call \cdf{compute-applicable-methods} and
\cdf{compute-applicable-methods-using-classes} to compute the methods applicable to
the generic functions arguments. Applicable methods are combined by
\cdf{compute-effective-method} to produce an \emph{effective} method. Provisions are made to
allow memoization of the method applicability and effective methods
computations. (See the description of \cdf{compute-discriminating-function} for
details.) 

The body of method definitions are processed by \cdf{make-method-lambda}. The
result of this generic function is a lambda expression which is processed by
either \cdf{compile} or the file compiler to produce a \emph{method
  function}. The arguments received by the method function are controlled by the
call-method forms appearing in the effective methods. By default, method
functions accept two arguments: a list of arguments to the generic function, and
a list of next methods. The list of next methods corresponds to the next methods
argument to \cdf{call-method}. If \cdf{call-method} appears with additional arguments,
these will be passed to the method functions as well; in these cases,
\cdf{make-method-lambda} must have created the method lambdas to expect
additional arguments.

\subsubsection{Dependent Maintenance Protocol}
\label{DEPENDENT-MAINTENANCE-PROTOCOL}

It is convenient for portable metaobjects to be able to memoize information
about other metaobjects, portable or otherwise. Because class and generic
function metaobjects can be reinitialized, and generic function metaobjects can
be modified by adding and removing methods, a means must be provided to update
this memoized information. 

The dependent maintenance protocol supports this by providing a way to register
an object which should be notified whenever a class or generic function is
modified. An object which has been registered this way is called a dependent of
the class or generic function metaobject. The dependents of class and generic
function metaobjects are maintained with \cdf{add-dependent} and
\cdf{remove-dependent}. The dependents of a class or generic function metaobject
can be accessed with \cdf{map-dependents}. Dependents are notified about a
modification by calling \cdf{update-dependent}. (See the specification of
\cdf{update-dependent} for detailed description of the circumstances under which
it is called.)

To prevent conflicts between two portable programs, or between portable programs
and the implementation, portable code must not register metaobjects themselves
as dependents. Instead, portable programs which need to record a metaobject as a
dependent, should encapsulate that metaobject in some other kind of object, and
record that object as the dependent. The results are undefined if this
restriction is violated. 

This example shows a general facility for encapsulating metaobjects before
recording them as dependents. The facility defines a basic kind of encapsulating
object: an updater. Specializations of the basic class can be defined with
appropriate special updating behavior. In this way, information about the
updating required is associated with each updater rather than with the
metaobject being updated. 

Updaters are used to encapsulate any metaobject which requires updating when a
given class or generic function is modified. The function \cdf{record-updater} is
called to both create an updater and add it to the dependents of the class or
generic function. Methods on the generic function \cdf{update-dependent}, specialized
to the specific class of updater do the appropriate update work. 

\begin{lisp}
(defclass updater ()\\*
~~~~ ((dependent :initarg :dependent :reader dependent)))\\*
\\
(defun record-updater (class dependee dependent \&rest initargs)\\*
~~(let ((updater (apply \#'make-instance class :dependent dependent initargs)))\\*
~~~~(\cdf{add-dependent} dependee updater) updater))
\end{lisp}
  
A flush-cache-updater simply flushes the cache of the dependent when it is updated.

\begin{lisp}
(defclass flush-cache-updater (updater) ()) \\*
\\
(defmethod \cdf{update-dependent} (dependee (updater flush-cache-updater) \&rest
args) \\*
~~(declare (ignore args)) \\*
~~(flush-cache (dependent updater)))
\end{lisp}

\section{Generic Functions and Methods Dictionary}

This chapter describes each of the functions and generic functions that make up
the CLOS Metaobject Protocol. The descriptions appear in alphabetical order with
the exception that all the reader generic functions for each kind of metaobject
are grouped together. So, for example, \cdf{method-function} would be found with
\cdf{method-qualifiers} and other method metaobject readers under
section~\ref{READERS-FOR-METHOD-METAOBJECTS}.

The description of functions follows the same form as used in the CLOS
specification. The description of generic functions is similar to that in the
CLOS specification, but some minor changes have been made in the way methods are
presented. 

The following is an example of the format for the syntax description of a
generic function:

\begin{defun}[Generic Function]
gf1 x y &optional z &key k

This description indicates that gf1 is a generic function with two required
parameters, x and y, an optional parameter z and a keyword parameter k. 

The description of a generic function includes a description of its
behavior. This provides the general behavior, or protocol of the generic
function. All methods defined on the generic function, both portable and
specified, must have behavior consistent with this description. 

Every generic function described in this section is an instance of the class
standard-generic-function and uses standard method combination. 

The description of a generic function also includes descriptions of the
specified methods for that generic function. In the description of these
methods, a method signature is used to describe the parameters and parameter
specializers of each method. The following is an example of the format for a
method signature: 

\begin{defun}[Primary Method]
gf1 (x class) y &optional z &key k

This signature indicates that this primary method on the generic function gf1
has two required parameters, named x and y. In addition, there is an optional
parameter z and a keyword parameter k. This signature also indicates that the
method's parameter specializers are the classes named class and t. 

The description of each method includes a description of the behavior particular
to that method.
\end{defun}

An abbreviated syntax is used when referring to a method defined elsewhere in
the document. This abbreviated syntax includes the name of the generic function,
the qualifiers, and the parameter specializers. A reference to the method with
the signature shown above is written as: \cd{gf1 (class t)}.
\end{defun}

\begin{defun}[Generic Function]
add-dependent metaobject dependent

\textbf{Arguments:}

The \emph{metaobject} argument is a class or generic function metaobject.

The \emph{dependent} argument is an object.

\textbf{Values:}

The value returned by this generic function is unspecified.

\textbf{Purpose:}

This generic function adds \emph{dependent} to the dependents of \emph{metaobject}. If
\emph{dependent} is already in the set of dependents it is not added again (no error is
signaled).

The generic function \cdf{map-dependents} can be called to access the set of
dependents of a class or generic function. The generic function \cdf{remove-dependent}
can be called to remove an object from the set of dependents of a class or
generic function. The effect of calling \cdf{add-dependent} or \cdf{remove-dependent} while
a call to \cdf{map-dependents} on the same class or generic function is in progress is
unspecified. 

The situations in which \cdf{add-dependent} is called are not specified.

\textbf{Methods:}

\begin{defun}[Primary Method]
add-dependent (class standard-class) dependent

No behavior is specified for this method beyond that which is specified for the
generic function.

This method cannot be overridden unless the following methods are overridden as
well:

\begin{tabbing}
    \cdf{remove-dependent} (standard-class t) \\*
    \cdf{map-dependents} (standard-class t) 
\end{tabbing}
\end{defun}
  
\begin{defun}[Primary Method]
add-dependent (class funcallable-standard-class) dependent

No behavior is specified for this method beyond that which is specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

\begin{tabbing}
    \cdf{remove-dependent} (funcallable-standard-class t)\\*
    \cdf{map-dependents} (funcallable-standard-class t) 
\end{tabbing}
\end{defun}

\begin{defun}[Primary Method]
add-dependent (generic-function standard-generic-function) dependent

No behavior is specified for this method beyond that which is specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

\begin{tabbing}
    \cdf{remove-dependent} (standard-generic-function t) \\*
    \cdf{map-dependents} (standard-generic-function t) 
\end{tabbing}
\end{defun}

\textbf{Notes:}

See the section~\ref{DEPENDENT-MAINTENANCE-PROTOCOL} for remarks about the use of
this facility.
\end{defun}

\begin{defun}[Generic Function]
add-direct-method specializer method

\textbf{Arguments:}

The \emph{specializer} argument is a specializer metaobject.

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

\textbf{Values:}

The value returned by this generic function is unspecified.

\textbf{Purpose:}

This generic function is called to maintain a set of backpointers from a
specializer to the set of methods specialized to it. If \emph{method} is already in the
set, it is not added again (no error is signaled).

This set can be accessed as a list by calling the generic function
\cdf{specializer-direct-methods}. Methods are removed from the set by
\cdf{remove-direct-method}.

The generic function \cdf{add-direct-method} is called by \cdf{add-method} whenever a method
is added to a generic function. It is called once for each of the specializers
of the method. Note that in cases where a specializer appears more than once in
the specializers of a method, this generic function will be called more than
once with the same specializer as argument. 

The results are undefined if the \emph{specializer} argument is not one of the
specializers of the \emph{method} argument.

\textbf{Methods:}

\begin{defun}[Primary Method]
add-direct-method (specializer class) (method method)

This method implements the behavior of the generic function for class
specializers. No behavior is specified for this method beyond that which is
specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

\begin{tabbing}
    \cdf{remove-direct-method} (class method)\\*
    \cdf{specializer-direct-generic-functions} (class)\\*
    \cdf{specializer-direct-methods} (class) \\*
\end{tabbing}
  
\end{defun}
  
\begin{defun}[Primary Method]
add-direct-method (specializer eql-specializer) (method method)

This method implements the behavior of the generic function for \cdf{eql}
specializers. No behavior is specified for this method beyond that which is
specified for the generic function.
\end{defun}

\end{defun}

\begin{defun}[Generic Function]
add-direct-subclass superclass subclass

\textbf{Arguments:}

The \emph{superclass} argument is a class metaobject.

The \emph{subclass} argument is a class metaobject.

\textbf{Values:}

The value returned by this generic function is unspecified.

\textbf{Purpose:}

This generic function is called to maintain a set of backpointers from a class
to its direct subclasses. This generic function adds \emph{subclass} to the set
of direct subclasses of \emph{superclass.}

When a class is initialized, this generic function is called once for each
direct superclass of the class. 

When a class is reinitialized, this generic function is called once for each
added direct superclass of the class. The generic function
\cdf{remove-direct-subclass} is called once for each deleted direct superclass of the
class. 

\textbf{Methods:}

\begin{defun}[Primary Method]
add-direct-subclass (superclass class) (subclass class)

No behavior is specified for this method beyond that which is specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

\begin{tabbing}
    \cdf{remove-direct-subclass} (class class) \\*
    \cdf{class-direct-subclasses} (class) 
\end{tabbing}
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
add-method generic-function method

\textbf{Arguments:}

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

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

\textbf{Values:}

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

\textbf{Purpose:}

This generic function associates an unattached method with a generic function. 

An error is signaled if the lambda list of the method is not congruent with the
lambda list of the generic function. An error is also signaled if the method is
already associated with some other generic function. 

If the given method agrees with an existing method of the generic function on
parameter specializers and qualifiers, the existing method is removed by calling
remove-method before the new method is added. See the
section~\ref{Agreement-on-Parameter-Specializers-and-Qualifiers-SECTION} of the
CLOS Specification for a definition of agreement in this context.

Associating the method with the generic function then proceeds in four steps:
\begin{itemize}
\item (i) add \emph{method} to the set returned by generic-function-methods and arrange
  for method-generic-function to return \emph{generic-function};
\item (ii) call add-direct-method for each of the method's specializers;
\item (iii) call \cdf{compute-discriminating-function} and install its result
  with set-funcallable-instance-function;
\item and (iv) update the dependents of the generic function.
\end{itemize}
The generic function \cdf{add-method} can be called by the user or the implementation.

\textbf{Methods:}

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

No behavior is specified for this method beyond that which is specified for the
generic function.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
allocate-instance class &rest initargs

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

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

\textbf{Values:}

The value returned is a newly allocated instance of \emph{class}.

\textbf{Purpose:}

This generic function is called to create a new, uninitialized instance of a
class. The interpretation of the concept of an ``uninitialized'' instance
depends on the class metaobject class.

Before allocating the new instance, class-finalized-p is called to see if \emph{class}
has been finalized. If it has not been finalized, \cdf{finalize-inheritance} is called
before the new instance is allocated.

\textbf{Methods:}

\begin{defun}[Primary Method]
allocate-instance (class standard-class) &rest initargs

This method allocates storage in the instance for each slot with allocation
\cd{:instance}. These slots are unbound. Slots with any other allocation are ignored
by this method (no error is signaled).
\end{defun}

\begin{defun}[Primary Method]
allocate-instance (class funcallable-standard-class) &rest initargs

This method allocates storage in the instance for each slot with allocation
\cd{:instance}. These slots are unbound. Slots with any other allocation are ignored
by this method (no error is signaled).

The funcallable instance function of the instance is undefined---the results are
undefined if the instance is applied to arguments before
set-funcallable-instance-function has been used to set the funcallable instance
function.
\end{defun}

\begin{defun}[Primary Method]
allocate-instance (class built-in-class) &rest initargs

This method signals an error.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
class-default-initargs \\
class-direct-default-initargs \\
class-direct-slots \\
class-direct-subclasses \\
class-direct-superclasses \\
class-finalized-p \\
class-name \\
class-precedence-list \\
class-prototype

The following generic functions are described together under
section~\ref{READERS-FOR-CLASS-METAOBJECTS}: \cdf{class-default-initargs},
\cdf{class-direct-default-initargs}, \cdf{class-direct-slots},
\cdf{class-direct-subclasses}, \cdf{class-direct-superclasses},
\cdf{class-finalized-p}, \cdf{class-name}, \cdf{class-precedence-list},
\cdf{class-prototype} and \cdf{class-slots}.
\end{defun}

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

\textbf{Arguments:}

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

The \emph{arguments} argument is a list of objects.

\textbf{Values:}

This generic function returns a possibly empty list of method metaobjects.

\textbf{Purpose:}

This generic function determines the method applicability of a generic function
given a list of required arguments. The returned list of method metaobjects is
sorted by precedence order with the most specific method appearing first. If no
methods are applicable to the supplied arguments the empty list is returned.

When a generic function is invoked, the discriminating function must determine
the ordered list of methods applicable to the arguments. Depending on the
generic function and the arguments, this is done in one of three ways: using a
memoized value; calling \cdf{compute-applicable-methods-using-classes}; or calling
\cdf{compute-applicable-methods}. (Refer to the description of
\cdf{compute-discriminating-function} for the details of this process.)

The \emph{arguments} argument is permitted to contain more elements than the generic
function accepts required arguments; in these cases the extra arguments will be
ignored. An error is signaled if \emph{arguments} contains fewer elements than the
generic function accepts required arguments.

The list returned by this generic function will not be mutated by the
implementation. The results are undefined if a portable program mutates the list
returned by this generic function.

\textbf{Methods:}

\begin{defun}[Primary Method]
compute-applicable-methods (generic-function standard-generic-function) arguments

This method signals an error if any method of the generic function has a
specializer which is neither a class metaobject nor an \cdf{eql} specializer
metaobject.

Otherwise, this method computes the sorted list of applicable methods according
to the rules described in the
section~\ref{Method-Selection-and-Combination-SECTION} of the CLOS
Specification.

This method can be overridden. Because of the consistency requirements between
this generic function and \cdf{compute-applicable-methods-using-classes}, doing so may
require also overriding \cd{compute-applicable-methods-using-classes
(standard-generic-function t)}.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
compute-applicable-methods-using-classes generic-function classes

\textbf{Arguments:}

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

The \emph{classes} argument is a list of class metaobjects.

\textbf{Values:}

This generic function returns two values. The first is a possibly empty list of
method metaobjects. The second is either true or false.

\textbf{Purpose:}

This generic function is called to attempt to determine the method applicability
of a generic function given only the classes of the required arguments.

If it is possible to completely determine the ordered list of applicable methods
based only on the supplied classes, this generic function returns that list as
its first value and true as its second value. The returned list of method
metaobjects is sorted by precedence order, the most specific method coming
first. If no methods are applicable to arguments with the specified classes, the
empty list and true are returned.

If it is not possible to completely determine the ordered list of applicable
methods based only on the supplied classes, this generic function returns an
unspecified first value and false as its second value.

When a generic function is invoked, the discriminating function must determine
the ordered list of methods applicable to the arguments. Depending on the
generic function and the arguments, this is done in one of three ways: using a
memoized value; calling \cdf{compute-applicable-methods-using-classes}; or calling
\cdf{compute-applicable-methods}. (Refer to the description of
compute-discriminating-function for the details of this process.)

The following consistency relationship between
\cdf{compute-applicable-methods-using-classes} and \cdf{compute-applicable-methods} must be
maintained: for any given generic function and set of arguments, if
\cdf{compute-applicable-methods-using-classes} returns a second value of true, the
first value must be equal to the value that would be returned by a corresponding
call to compute-applicable-methods. The results are undefined if a portable
method on either of these generic functions causes this consistency to be
violated.

The list returned by this generic function will not be mutated by the
implementation. The results are undefined if a portable program mutates the list
returned by this generic function.

\textbf{Methods:}

\begin{defun}[Primary Method]
compute-applicable-methods-using-classes (generic-function standard-generic-function) classes

If any method of the generic function has a specializer which is neither a class
metaobject nor an \cdf{eql} specializer metaobject, this method signals an error.

In cases where the generic function has no methods with \cdf{eql} specializers, or has
no methods with \cdf{eql} specializers that could be applicable to arguments of the
supplied classes, this method returns the ordered list of applicable methods as
its first value and true as its second value.

Otherwise this method returns an unspecified first value and false as its second
value.

This method can be overridden. Because of the consistency requirements between
this generic function and compute-applicable-methods, doing so may require also
overriding \cdf{compute-applicable-methods} (standard-generic-function t).
\end{defun}

\textbf{Notes:}

This generic function exists to allow user extensions which alter method lookup
rules, but which base the new rules only on the classes of the required
arguments, to take advantage of the class-based method lookup memoization found
in many implementations. (There is of course no requirement for an
implementation to provide this optimization.)

Such an extension can be implemented by two methods, one on this generic
function and one on \cdf{compute-applicable-methods}. Whenever the user extension is
in effect, the first method will return a second value of true. This should
allow the implementation to absorb these cases into its own memoization scheme.

To get appropriate performance, other kinds of extensions may require methods on
\cdf{compute-discriminating-function} which implement their own memoization scheme.
\end{defun}

\begin{defun}[Generic Function]
compute-class-precedence-list class

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

\textbf{Values:}

The value returned by this generic function is a list of class metaobjects.

\textbf{Purpose:}

This generic-function is called to determine the class precedence list of a
class.

The result is a list which contains each of class and its superclasses once and
only once. The first element of the list is class and the last element is the
\cdf{class} named \cdf{t}.

All methods on this generic function must compute the class precedence list as a
function of the ordered direct superclasses of the superclasses of class. The
results are undefined if the rules used to compute the class precedence list
depend on any other factors.

When a class is finalized, \cdf{finalize-inheritance} calls this generic function and
associates the returned value with the class metaobject. The value can then be
accessed by calling \cdf{class-precedence-list}.

The list returned by this generic function will not be mutated by the
implementation. The results are undefined if a portable program mutates the list
returned by this generic function.

\textbf{Methods:}

\begin{defun}[Primary Method]
compute-class-precedence-list (class class)

This method computes the class precedence list according to the rules described
in the section~\ref{Determining-the-Class-Precedence-List-SECTION} of the CLOS
Specification.

This method signals an error if \emph{class} or any of its superclasses is a
forward referenced class.

This method can be overridden.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
compute-default-initargs class

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

\textbf{Values:}

The value returned by this generic function is a list of canonicalized default
initialization arguments.

\textbf{Purpose:}

This generic-function is called to determine the default initialization
arguments for a class.

The result is a list of canonicalized default initialization arguments, with no
duplication among initialization argument names.

All methods on this generic function must compute the default initialization
arguments as a function of only: (i) the class precedence list of class, and
(ii) the direct default initialization arguments of each class in that list. The
results are undefined if the rules used to compute the default initialization
arguments depend on any other factors.

When a class is finalized, \cdf{finalize-inheritance} calls this generic function and
associates the returned value with the class metaobject. The value can then be
accessed by calling \cdf{class-default-initargs}.

The list returned by this generic function will not be mutated by the
implementation. The results are undefined if a portable program mutates the list
returned by this generic function.

\textbf{Methods:}

\begin{defun}[Primary Method]
compute-default-initargs (class standard-class)
compute-default-initargs (class funcallable-standard-class)

These methods compute the default initialization arguments according to the
rules described in the section~\ref{DEFAULTING-INITIALIZATION-ARGUMENTS} of the
CLOS Specification.

These methods signal an error if \emph{class} or any of its superclasses is a
forward referenced class.

These methods can be overridden.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
compute-discriminating-function generic-function

\textbf{Arguments:}

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

\textbf{Values:}

The value returned by this generic function is a function.

\textbf{Purpose:}

This generic function is called to determine the discriminating function for a
generic function. When a generic function is called, the \emph{installed}
discriminating function is called with the full set of arguments received by the
generic function, and must implement the behavior of calling the generic
function: determining the ordered set of applicable methods, determining the
effective method, and running the effective method.

To determine the ordered set of applicable methods, the discriminating function
first calls \cdf{compute-applicable-methods-using-classes}. If
\cdf{compute-applicable-methods-using-classes} returns a second value of false, the
discriminating function then calls \emph{compute-applicable-methods}. 

When \cdf{compute-applicable-methods-using-classes} returns a second value of true,
the discriminating function is permitted to memoize the first returned value as
follows. The discriminating function may reuse the list of applicable methods
without calling \cdf{compute-applicable-methods-using-classes} again provided that: 

\begin{itemize}
\item (i) the generic function is being called again with required arguments
  which are instances of the same classes,
\item (ii) the generic function has not been reinitialized,
\item (iii) no method has been added to or removed from the generic function,
\item (iv) for all the specializers of all the generic function's methods which
  are classes, their class precedence lists have not changed and
\item (v) for any such memoized value, the class precedence list of the class of
  each of the required arguments has not changed.
\end{itemize}
  
Determination of the effective method is done by calling
compute-effective-method. When the effective method is run, each method's
function is called, and receives as arguments: (i) a list of the arguments to
the generic function, and (ii) whatever other arguments are specified in the
\cdf{call-method} form indicating that the method should be called. (See
\cdf{make-method-lambda} for more information about how method functions are
called.)

The generic function \cdf{compute-discriminating-function} is called, and its
result installed, by \cdf{add-method}, \cdf{remove-method},
\cdf{initialize-instance} and \cdf{reinitialize-instance}.

\textbf{Methods:}

\begin{defun}[Primary Method]
compute-discriminating-function (generic-function standard-generic-function)

No behavior is specified for this method beyond that specified for the generic function.

This method can be overridden.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
compute-effective-method generic-function method-combination methods

\textbf{Arguments:}

The \cdf{generic-function} argument is a generic function metaobject.

The \cdf{method-combination} argument is a method combination metaobject.

The \cdf{methods} argument is a list of method metaobjects.

\textbf{Values:}

This generic function returns two values. The first is an effective method, the
second is a list of effective method options.

\textbf{Purpose:}

This generic function is called to determine the effective method from a sorted
list of method metaobjects.

An effective method is a form that describes how the applicable methods are to
be combined. Inside of effective method forms are \cdf{call-method} forms which
indicate that a particular method is to be called. The arguments to the
\cdf{call-method} form indicate exactly how the method function of the method
should be called. (See \cdf{make-method-lambda} for more details about method
functions.)

An effective method option has the same interpretation and syntax as either the
\cd{:arguments} or the \cd{:generic-function} option in the long form of
\cdf{define-method-combination}.

More information about the form and interpretation of effective methods and
effective method options can be found under the description of the
\cdf{define-method-combination} macro in the CLOS specification.

This generic function can be called by the user or the implementation. It is
called by discriminating functions whenever a sorted list of applicable methods
must be converted to an effective method.

\textbf{Methods:}

\begin{defun}[Primary Method]
compute-effective-method (generic-function standard-generic-function) method-combination methods

This method computes the effective method according to the rules of the method
combination type implemented by \emph{method-combination}.

This method can be overridden.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
compute-effective-slot-definition class name direct-slot-definitions

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

The \emph{name} argument is a slot name.

The \emph{direct-slot-definitions} argument is an ordered list of direct slot
definition metaobjects. The most specific direct slot definition metaobject
appears first in the list.

\textbf{Values:}

The value returned by this generic function is an effective slot definition
metaobject.

\textbf{Purpose:}

This generic function determines the effective slot definition for a slot in a
class. It is called by \cdf{compute-slots} once for each slot accessible in instances
of \emph{class}.

This generic function uses the supplied list of direct slot definition
metaobjects to compute the inheritance of slot properties for a single slot. The
returned effective slot definition represents the result of computing the
inheritance. The name of the new effective slot definition is the same as the
name of the direct slot definitions supplied.

The class of the effective slot definition metaobject is determined by calling
effective-slot-definition-class. The effective slot definition is then created
by calling \cdf{make-instance}. The initialization arguments passed in this call to
make-instance are used to initialize the new effective slot definition
metaobject. See section~\ref{INITIALIZATION-OF-SLOT-DEFINITION-METAOBJECTS} for details.

\textbf{Methods:}

\begin{defun}[Primary Method]
compute-effective-slot-definition (class standard-class) name direct-slot-definitions

This method implements the inheritance and defaulting of slot options following
the rules described in the
section~\ref{Inheritance-of-Slots-and-Slot-Options-SECTION} of the
CLOS Specification.

This method can be extended, but the value returned by the extending method must
be the value returned by this method.
\end{defun}

\begin{defun}[Primary Method]
compute-effective-slot-definition (class funcallable-standard-class) name direct-slot-definitions

This method implements the inheritance and defaulting of slot options following
the rules described in the
section~\ref{Inheritance-of-Slots-and-Slot-Options-SECTION} of the CLOS
Specification.

This method can be extended, but the value returned by the extending method must
be the value returned by this method.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
compute-slots class

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

\textbf{Values:}

The value returned is a set of effective slot definition metaobjects.

\textbf{Purpose:}

This generic function computes a set of effective slot definition metaobjects
for the class \emph{class}. The result is a list of effective slot definition
metaobjects: one for each slot that will be accessible in instances of
\emph{class}.

This generic function proceeds in 3 steps:

The first step collects the full set of direct slot definitions from the
superclasses of \emph{class}.

The direct slot definitions are then collected into individual lists, one list
for each slot name associated with any of the direct slot definitions. The slot
names are compared with \cdf{eql}. Each such list is then sorted into class
precedence list order. Direct slot definitions coming from classes earlier in
the class precedence list of \emph{class} appear before those coming from
classes later in the class precedence list. For each slot name, the generic
function \cdf{compute-effective-slot-definition} is called to compute an
effective slot definition. The result of \cdf{compute-slots} is a list of these
effective slot definitions, in unspecified order.

In the final step, the location for each effective slot definition is set. This
is done by specified around-methods; portable methods cannot take over this
behavior. For more information on the slot definition locations, see the
section~\ref{INSTANCE-STRUCTURE-PROTOCOL}. 

The list returned by this generic function will not be mutated by the
implementation. The results are undefined if a portable program mutates the list
returned by this generic function.

\textbf{Methods:}

\begin{defun}[Primary Method]
compute-slots (class standard-class)

This method implements the specified behavior of the generic function.

This method can be overridden.
\end{defun}

\begin{defun}[Primary Method]
compute-slots (class funcallable-standard-class)

This method implements the specified behavior of the generic function.

This method can be overridden.
\end{defun}

\begin{defun}[Around Method]
compute-slots (class standard-class)

This method implements the specified behavior of computing and storing slot
locations. This method cannot be overridden.
\end{defun}

\begin{defun}[Around Method]
compute-slots (class funcallable-standard-class)

This method implements the specified behavior of computing and storing slot
locations. This method cannot be overridden.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
direct-slot-definition-class class &rest initargs

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

The \emph{initargs} argument is a set of initialization arguments and values.

\textbf{Values:}

The value returned is a subclass of the class \cdf{direct-slot-definition}.

\textbf{Purpose:}

When a class is initialized, each of the canonicalized slot specifications must
be converted to a direct slot definition metaobject. This generic function is
called to determine the class of that direct slot definition metaobject.

The \emph{initargs} argument is simply the canonicalized slot specification for
the slot.

\textbf{Methods:}

\begin{defun}[Primary Method]
direct-slot-definition-class (class standard-class) &rest initargs

This method returns the class \cdf{standard-direct-slot-definition}.

This method can be overridden.
\end{defun}

\begin{defun}[Primary Method]
direct-slot-definition-class (class funcallable-standard-class) &rest initargs

This method returns the class \cdf{standard-direct-slot-definition}.

This method can be overridden.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
effective-slot-definition-class class &rest initargs

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

The \emph{initargs} argument is a set of initialization arguments and values.

\textbf{Values:}

The value returned is a subclass of the class \cdf{effective-slot-definition}.

\textbf{Purpose:}

This generic function is called by \cdf{compute-effective-slot-definition} to
determine the class of the resulting effective slot definition metaobject. The
\emph{initargs} argument is the set of initialization arguments and values that
will be passed to \cdf{make-instance} when the effective slot definition
metaobject is created.

\textbf{Methods:}

\begin{defun}[Primary Method]
effective-slot-definition-class (class standard-class) &rest initargs

This method returns the class standard-effective-slot-definition.

This method can be overridden.
\end{defun}

\begin{defun}[Primary Method]
effective-slot-definition-class (class funcallable-standard-class) &rest initargs

This method returns the class standard-effective-slot-definition.

This method can be overridden.
\end{defun}
\end{defun}

\begin{defun}[Function]
ensure-class name &key &allow-other-keys

\textbf{Arguments:}

The \emph{name} argument is a symbol.

Some of the keyword arguments accepted by this function are actually processed
by \cdf{ensure-class-using-class}, others are processed during initialization of
the class metaobject (as described in the
section~\ref{INITIALIZATION-OF-CLASS-METAOBJECTS}).

\textbf{Values:}

The result is a class metaobject.

\textbf{Purpose:}

This function is called to define or redefine a class with the specified name,
and can be called by the user or the implementation. It is the functional
equivalent of \cdf{defclass}, and is called by the expansion of the
\cdf{defclass} macro.

The behavior of this function is actually implemented by the generic function
\cdf{ensure-class-using-class}. When \cdf{ensure-class} is called, it
immediately calls \cdf{ensure-class-using-class} and returns that result as its
own.

The first argument to \cdf{ensure-class}-using-class is computed as follows:

\begin{itemize}
\item 
  If \emph{name} names a class (find-class returns a class when called with \cdf{name}) use that class.
\item 
  Otherwise use \cdf{nil}.
\end{itemize}

The second argument is \cdf{name}. The remaining arguments are the complete set of
keyword arguments received by the \cdf{ensure-class} function.
\end{defun}

\begin{defun}[Generic Function]
ensure-class-using-class class name &key direct-default-initargs direct-slots
  direct-superclasses name metaclass &allow-other-keys

\textbf{Arguments:}

The \emph{class} argument is a class metaobject or nil.

The \emph{name} argument is a class name.

The \cd{:metaclass} argument is a class metaobject class or a class metaobject
class name. If this argument is not supplied, it defaults to the class named
\cdf{standard-class}. If a class name is supplied, it is interpreted as the
class with that name. If a class name is supplied, but there is no such class,
an error is signaled.

The \cd{:direct-superclasses} argument is a list of which each element is a class
metaobject or a class name. An error is signaled if this argument is not a
proper list.

For the interpretation of additional keyword arguments, see
section~\ref{INITIALIZATION-OF-CLASS-METAOBJECTS}.

\textbf{Values:}

The result is a class metaobject.

\textbf{Purpose:}

This generic function is called to define or modify the definition of a named
class. It is called by the \cdf{ensure-class} function. It can also be called
directly.

The first step performed by this generic function is to compute the set of
initialization arguments which will be used to create or reinitialize the named
class. The initialization arguments are computed from the full set of keyword
arguments received by this generic function as follows:

\begin{itemize}
\item 
  The \cd{:metaclass} argument is not included in the initialization arguments.

\item 
  If the \cd{:direct-superclasses} argument was received by this generic function,
  it is converted into a list of class metaobjects. This conversion does not
  affect the structure of the supplied \cd{:direct-superclasses} argument. For each
  element in the \cd{:direct-superclasses} argument: 
  \begin{itemize}
  \item 
    If the element is a class metaobject, that class metaobject is used.
  \item 
    If the element names a class, that class metaobject is used.
  \item 
    Otherwise an instance of the class \cdf{forward-referenced-class} is created
    and used. The proper name of the newly created forward referenced class
    metaobject is set to \emph{name}. 
  \end{itemize}
\item 
  All other keyword arguments are included directly in the initialization
  arguments.
\end{itemize}

If the \emph{class} argument is \cdf{nil}, a new class metaobject is created by
calling the make-instance generic function with the value of the \cd{:metaclass}
argument as its first argument, and the previously computed initialization
arguments. The proper name of the newly created class metaobject is set to
\emph{name}. The newly created class metaobject is returned.

If the \emph{class} argument is a forward referenced class, \cdf{change-class}
is called to change its class to the value specified by the \cd{:metaclass}
argument. The class metaobject is then reinitialized with the previously
computed initialization arguments. (This is a documented violation of the
general constraint that \cdf{change-class} not be used with class metaobjects.)

If the \emph{class} of the class argument is not the same as the class specified
by the \cd{:metaclass} argument, an error is signaled.

Otherwise, the class metaobject \emph{class} is redefined by calling the
\cdf{reinitialize-instance} generic function with class and the initialization
arguments. The \emph{class} argument is then returned.

\textbf{Methods:}

\begin{defun}[Primary Method]
ensure-class-using-class (class class) name &key metaclass direct-superclasses
    &allow-other-keys

This method implements the behavior of the generic function in the case
where the class argument is a class.

This method can be overridden.
\end{defun}

\begin{defun}[Primary Method]
ensure-class-using-class (class forward-referenced-class) name &key metaclass
    direct-superclasses &allow-other-keys

This method implements the behavior of the generic function in the case where
the class argument is a forward referenced class.
\end{defun}

\begin{defun}[Primary Method]
ensure-class-using-class (class null) name &key metaclass direct-superclasses
    &allow-other-keys

This method implements the behavior of the generic function in the case where
the class argument is \cdf{nil}.
\end{defun}
\end{defun}

\begin{defun}[Function]
ensure-generic-function function-name &key &allow-other-keys

\textbf{Arguments:}

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

Some of the keyword arguments accepted by this function are actually processed
by \cdf{ensure-generic-function-using-class}, others are processed during
initialization of the generic function metaobject (as described in the
section~\ref{INITIALIZATION-OF-GENERIC-FUNCTION-METAOBJECTS}).

\textbf{Values:}

The result is a generic function metaobject.

\textbf{Purpose:}

This function is called to define a globally named generic function or to
specify or modify options and declarations that pertain to a globally named
generic function as a whole. It can be called by the user or the implementation.

It is the functional equivalent of \cdf{defgeneric}, and is called by the expansion of
the \cdf{defgeneric} and \cdf{defmethod} macros.

The behavior of this function is actually implemented by the generic function
\cdf{ensure-generic-function-using-class}. When \cdf{ensure-generic-function} is
called, it immediately calls \cdf{ensure-generic-function-using-class} and
returns that result as its own.

The first argument to \cdf{ensure-generic-function-using-class} is computed as follows:

\begin{itemize}
\item If \emph{function-name} names a non-generic function, a macro, or a
  special operator, an error is signaled.
\item If \emph{function-name} names a generic function, that generic function
  metaobject is used.
\item Otherwise, \cdf{nil} is used.
\end{itemize}

The second argument is function-name. The remaining arguments are the complete
set of keyword arguments received by \cdf{ensure-generic-function}.
\end{defun}

\begin{defun}[Generic Function]
ensure-generic-function-using-class generic-function function-name 
  &key argument-precedence-order declarations documentation
  generic-function-class lambda-list method-class method-combination name
  &allow-other-keys

\textbf{Arguments:}

The \emph{generic-function} argument is a generic function metaobject or \cdf{nil}.

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

The \cd{:generic-function-class} argument is a class metaobject or a class
name. If it is not supplied, it defaults to the class named
\cdf{standard-generic-function}. If a class name is supplied, it is interpreted
as the class with that name. If a class name is supplied, but there is no such
class, an error is signaled.

For the interpretation of additional keyword arguments, see
section~\ref{INITIALIZATION-OF-GENERIC-FUNCTION-METAOBJECTS}.

\textbf{Values:}

The result is a generic function metaobject.

\textbf{Purpose:}

The generic function \cdf{ensure-generic-function-using-class} is called to
define or modify the definition of a globally named generic function. It is
called by the \cdf{ensure-generic-function} function. It can also be called
directly.

The first step performed by this generic function is to compute the set of
initialization arguments which will be used to create or reinitialize the
globally named generic function. These initialization arguments are computed
from the full set of keyword arguments received by this generic function as
follows:

\begin{itemize}
\item The \cd{:generic-function-class} argument is not included in the
  initialization arguments.
\item If the \cd{:method-class} argument was received by this generic function,
  it is converted into a class metaobject. This is done by looking up the class
  name with \cdf{find-class}. If there is no such class, an error is signalled.
\item All other keyword arguments are included directly in the initialization
  arguments.
\end{itemize}

If the \emph{generic-function} argument is nil, an instance of the class
specified by the \cd{:generic-function-class} argument is created by calling
\cdf{make-instance} with the previously computed initialization arguments. The
function name \emph{function-name} is set to name the generic function. The
newly created generic function metaobject is returned.

If the class of the \emph{generic-function} argument is not the same as the
class specified by the \cd{:generic-function-class} argument, an error is
signaled.

Otherwise the generic function \emph{generic-function} is redefined by calling
the \cdf{reinitialize-instance} generic function with \emph{generic-function}
and the initialization arguments. The \emph{generic-function} argument is then
returned.

\textbf{Methods:}

\begin{defun}[Primary Method]
ensure-generic-function-using-class (generic-function generic-function)
  function-name &key generic-function-class &allow-other-keys

  This method implements the behavior of the generic function in the case where
  function-name names an existing generic function.

This method can be overridden.
\end{defun}

\begin{defun}[Primary Method]
ensure-generic-function-using-class (generic-function null) function-name 
  &key generic-function-class &allow-other-keys

This method implements the behavior of the generic function in the case where
function-name names no function, generic function, macro or special operator.
\end{defun}
\end{defun}

\begin{defun}[Function]
eql-specializer-object eql-specializer

\textbf{Arguments:}

The \emph{eql-specializer} argument is an \cdf{eql} specializer metaobject.

\textbf{Values:}

The value returned by this function is an object.

\textbf{Purpose:}

This function returns the object associated with \emph{eql-specializer} during
initialization. The value is guaranteed to be \cdf{eql} to the value originally
passed to \cdf{intern-eql-specializer}, but it is not necessarily \cdf{eq} to
that value.

This function signals an error if \emph{eql-specializer} is not an \cdf{eql}
specializer.
\end{defun}

\begin{defun}[Function]
extract-lambda-list specialized-lambda-list

\textbf{Arguments:}

The \emph{specialized-lambda-list} argument is a specialized lambda list as
accepted by \cdf{def-method}.

\textbf{Values:}

The result is an unspecialized lambda list.

\textbf{Purpose:}

This function takes a specialized lambda list and returns the lambda list with
the specializers removed. This is a non-destructive operation. Whether the
result shares any structure with the argument is unspecified.

If the \emph{specialized-lambda-list} argument does not have legal syntax, an error is
signaled. This syntax checking does not check the syntax of the actual
specializer names, only the syntax of the lambda list and where the specializers
appear.

\textbf{Examples:}

\begin{lisp}
(extract-lambda-list '((p position))) \EQ\ (P)\\*
\\
(extract-lambda-list '((p position) x y)) \EQ\ (P X Y)\\*
\\
(extract-lambda-list '(a (b (eql x)) c \&rest i)) \EQ\ (A B C \&OPTIONAL I)
\end{lisp}
\end{defun}

\begin{defun}[Function]
extract-specializer-names specialized-lambda-list

\textbf{Arguments:}

The \emph{specialized-lambda-list} argument is a specialized lambda list as
accepted by def-method.

\textbf{Values:}

The result is a list of specializer names.

\textbf{Purpose:}

This function takes a specialized lambda list and returns its specializer
names. This is a non-destructive operation. Whether the result shares structure
with the argument is unspecified. The results are undefined if the result of
this function is modified.

The result of this function will be a list with a number of elements equal to
the number of required arguments in \emph{specialized-lambda-list}. Specializers are
defaulted to the symbol \cdf{t}.

If the \emph{specialized-lambda-list} argument does not have legal syntax, an
error is signaled. This syntax checking does not check the syntax of the actual
specializer names, only the syntax of the lambda list and where the specializers
appear.

\textbf{Examples:}

\begin{lisp}
(extract-specializer-names '((p position))) \EV\ (POSITION)\\*
\\
(extract-specializer-names '((p position) x y)) \EV\ (POSITION T T)\\*
\\
(extract-specializer-names '(a (b (eql x)) c \&rest i)) \EV (T (EQL X) T)
\end{lisp}
\end{defun}

\begin{defun}[Generic Function]
finalize-inheritance class

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

\textbf{Values:}

The value returned by this generic function is unspecified.

\textbf{Purpose:}

This generic function is called to finalize a class metaobject. This is
described in the section~\ref{CLASS-FINALIZATION-PROTOCOL}.

After \cdf{finalize-inheritance} returns, the class metaobject is finalized and the
result of calling \cdf{class-finalized-p} on the class metaobject will be true.

\textbf{Methods:}

\begin{defun}[Primary Method]
finalize-inheritance (class standard-class) \\
finalize-inheritance (class funcallable-standard-class)

No behavior is specified for these methods beyond that which is specified for the generic function.
\end{defun}

\begin{defun}[Primary Method]
finalize-inheritance (class forward-referenced-class)

This method signals an error.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
find-method-combination generic-function method-combination-type-name method-combination-options

\textbf{Arguments:}

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

The \emph{method-combination-type-name} argument is a symbol which names a type
of method combination.

The \emph{method-combination-options} argument is a list of arguments to the
method combination type.

\textbf{Values:}

The value returned by this generic function is a method combination metaobject.

\textbf{Purpose:}

This generic function is called to determine the method combination object used
by a generic function.

\textbf{Notes:}

Further details of method combination metaobjects are not specified.
\end{defun}

\begin{defun}[Function]
funcallable-standard-instance-access instance location

\textbf{Arguments:}

The \emph{instance} argument is an object.

The \emph{location} argument is a slot location.

\textbf{Values:}

The result of this function is an object.

\textbf{Purpose:}

This function is called to provide direct access to a slot in an instance. By
usurping the normal slot lookup protocol, this function is intended to provide
highly optimized access to the slots associated with an instance.

The following restrictions apply to the use of this function:

\begin{itemize}
\item The \emph{instance} argument must be a funcallable instance (it must have
  been returned by \cd{allocate-instance (funcallable-standard-class)}).
\item The \emph{instance} argument cannot be an non-updated obsolete instance.
\item The \emph{location} argument must be a location of one of the directly
  accessible slots of the instance's class.
\item The slot must be bound.
\end{itemize}

The results are undefined if any of these restrictions are not met.
\end{defun}

\begin{defun}[Generic Function]
generic-function-argument-precedence-order \\
generic-function-declarations \\
generic-function-lambda-list \\
generic-function-method-combination \\
generic-function-methods \\
generic-function-name

The following generic functions are described together under
section~\ref{READERS-FOR-GENERIC-FUNCTION-METAOBJECTS}:
generic-function-argument-precedence-order,
generic-function-declarations, generic-function-lambda-list,
generic-function-method-class, generic-function-method-combination,
generic-function-methods and generic-function-name.
\end{defun}

\subsection{Initialization of Class Metaobjects}
\label{INITIALIZATION-OF-CLASS-METAOBJECTS}

A class metaobject can be created by calling \cdf{make-instance}. The
initialization arguments establish the definition of the class. A class
metaobject can be redefined by calling \cdf{reinitialize-instance}. Some classes
of class metaobject do not support redefinition; in these cases,
\cdf{reinitialize-instance} signals an error.

Initialization of a class metaobject must be done by calling \cdf{make-instance}
and allowing it to call \cdf{initialize-instance}. Reinitialization of a class
metaobject must be done by calling \cdf{reinitialize-instance}. Portable
programs must not call initialize-instance directly to initialize a class
metaobject. Portable programs must not call \cdf{shared-initialize} directly to
initialize or reinitialize a class metaobject. Portable programs must not call
\cdf{change-class} to change the class of any class metaobject or to turn a
non-class object into a class metaobject.

Since metaobject classes may not be redefined, no behavior is specified for the
result of calls to \cdf{update-instance-for-redefined-class} on class
metaobjects. Since the class of class metaobjects may not be changed, no
behavior is specified for the result of calls to
\cdf{update-instance-for-different-class} on class metaobjects.

During initialization or reinitialization, each initialization argument is
checked for errors and then associated with the class metaobject. The value can
then be accessed by calling the appropriate accessor as shown in
table~\ref{INITARGS-ACCESSORS-FOR-CLASS-METAOBJECT}.

This section begins with a description of the error checking and processing of
each initialization argument. This is followed by a table showing the generic
functions that can be used to access the stored initialization
arguments. Initialization behavior specific to the different specified class
metaobject classes comes next. The section ends with a set of restrictions on
portable methods affecting class metaobject initialization and reinitialization.

In these descriptions, the phrase ``this argument defaults to \emph{value}''
means that when that initialization argument is not supplied, initialization or
reinitialization is performed as if \emph{value} had been supplied. For some
initialization arguments this could be done by the use of default initialization
arguments, but whether it is done this way is not specified. Implementations are
free to define default initialization arguments for specified class metaobject
classes. Portable programs are free to define default initialization arguments
for portable subclasses of the class \cdf{class}.

Unless there is a specific note to the contrary, then during reinitialization,
if an initialization argument is not supplied, the previously stored value is
left unchanged.

\begin{itemize}
\item The \cd{:direct-default-initargs} argument is a list of canonicalized default
  initialization arguments.

  An error is signaled if this value is not a proper list, or if any element
  of the list is not a canonicalized default initialization argument.
  
  If the class metaobject is being initialized, this argument defaults to
  the empty list.
\item The \cd{:direct-slots} argument is a list of canonicalized slot specifications.
  
  An error is signaled if this value is not a proper list or if any element
  of the list is not a canonicalized slot specification.

  After error checking, this value is converted to a list of direct slot
  definition metaobjects before it is associated with the class
  metaobject. Conversion of each canonicalized slot specification to a direct
  slot definition metaobject is a two-step process. First, the generic function
  \cdf{direct-slot-definition-class} is called with the class metaobject and the
  canonicalized slot specification to determine the class of the new direct slot
  definition metaobject; this permits both the class metaobject and the
  canonicalized slot specification to control the resulting direct slot
  definition metaobject class. Second, \cdf{make-instance} is applied to the
  direct slot definition metaobject class and the canonicalized slot
  specification. This conversion could be implemented as shown in the following
  code:

  \begin{lisp}
    ~~~~(defun convert-to-direct-slot-definition (class canonicalized-slot)\\*
    ~~~~~~(apply \#'make-instance\\*
    ~~~~~~~~~~~~ (apply \#'direct-slot-definition-class\\*
    ~~~~~~~~~~~~~~~~~~~~class canonicalized-slot)\\*
    ~~~~~~~~~~~~ canonicalized-slot))
  \end{lisp}

  If the class metaobject is being initialized, this argument defaults to the
  empty list.

  Once the direct slot definition metaobjects have been created, the specified
  reader and writer methods are created. The generic functions
  \cdf{reader-method-class} and \cdf{writer-method-class} are called to
  determine the classes of the method metaobjects created.

\item The \cd{:direct-superclasses} argument is a list of class metaobjects. Classes
  which do not support multiple inheritance signal an error if the list contains
  more than one element.

  An error is signaled if this value is not a proper list or if
  validate-superclass applied to class and any element of this list returns
  false.

  When the class metaobject is being initialized, and this argument is either
  not supplied or is the empty list, this argument defaults as follows: if the
  class is an instance of \cdf{standard-class} or one of its subclasses the
  default value is a list of the class \cdf{standard-object}; if the class is an
  instance of \cdf{funcallable-standard-class} or one of its subclasses the
  default value is list of the class \cdf{funcallable-standard-object}.

  After any defaulting of the value, the generic function \cdf{add-direct-subclass} is
  called once for each element of the list.

  When the class metaobject is being reinitialized and this argument is
  supplied, the generic function \cdf{remove-direct-subclass} is called once for
  each class metaobject in the previously stored value but not in the new value;
  the generic function \cdf{add-direct-subclass} is called once for each class
  metaobject in the new value but not in the previously stored value.

\item The \cd{:documentation} argument is a string or \cdf{nil}.

  An error is signaled if this value is not a string or \cdf{nil}.

  If the class metaobject is being initialized, this argument defaults to \cdf{nil}.

\item The \cd{:name} argument is an object.

  If the class is being initialized, this argument defaults to \cdf{nil}.
\end{itemize}
  
After the processing and defaulting of initialization arguments described
above, the value of each initialization argument is associated with the
class metaobject. These values can then be accessed by calling the
corresponding generic function. The correspondences are as follows:

\begin{table}[t]
\caption{Initialization arguments and accessors for class
metaobjects}
\label{INITARGS-ACCESSORS-FOR-CLASS-METAOBJECT}
\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\textbf{Initialization Argument}&\textbf{Generic Function}\\
:direct-default-initargs&class-direct-default-initargs\\
:direct-slots&class-direct-slots\\
:direct-superclasses&class-direct-superclasses\\
:documentation&documentation\\
:name&class-name\\
\end{tabular}
\end{flushleft}
\end{table}

Instances of the class \cdf{standard-class} support multiple inheritance and
reinitialization. Instances of the class \cdf{funcallable-standard-class} support
multiple inheritance and reinitialization. For forward referenced classes, all
of the initialization arguments default to \cdf{nil}.

Since built-in classes cannot be created or reinitialized by the user, an error
is signaled if \cdf{initialize-instance} or \cdf{reinitialize-instance} are
called to initialize or reinitialize a derived instance of the class
\cdf{built-in-class}.

\textbf{Methods:}

It is not specified which methods provide the initialization and
reinitialization behavior described above. Instead, the information needed to
allow portable programs to specialize this behavior is presented as a set of
restrictions on the methods a portable program can define. The model is that
portable initialization methods have access to the class metaobject when either
all or none of the specified initialization has taken effect.

These restrictions govern the methods that a portable program can define on the
generic functions initialize-instance, \cdf{reinitialize-instance}, and
\cdf{shared-initialize}. These restrictions apply only to methods on these generic
functions for which the first specializer is a subclass of the class
\cdf{class}. Other portable methods on these generic functions are not affected by
these restrictions.

\begin{itemize}
\item 
  Portable programs must not define methods on \cdf{shared-initialize}.
\item 
  For \cdf{initialize-instance} and \cdf{reinitialize-instance}:
  \begin{itemize}
  \item 
    Portable programs must not define primary methods.
  \item 
    Portable programs may define around-methods, but these must be
    extending, not overriding methods. 
  \item 
    Portable before-methods must assume that when they are run, none of the
    initialization behavior described above has been completed. 
  \item 
    Portable after-methods must assume that when they are run, all of the
    initialization behavior described above has been completed. 

    The results are undefined if any of these restrictions are violated.
  \end{itemize}
\end{itemize}

\subsection{Initialization of Generic Function Metaobjects}
\label{INITIALIZATION-OF-GENERIC-FUNCTION-METAOBJECTS}

A generic function metaobject can be created by calling \cdf{make-instance}. The
initialization arguments establish the definition of the generic function. A
generic function metaobject can be redefined by calling
\cdf{reinitialize-instance}. Some classes of generic function metaobject do not
support redefinition; in these cases, \cdf{reinitialize-instance} signals an
error.

Initialization of a generic function metaobject must be done by calling
\cdf{make-instance} and allowing it to call
\cdf{initialize-instance}. Reinitialization of a generic-function metaobject
must be done by calling \cdf{reinitialize-instance}. Portable programs must not
call \cdf{initialize-instance} directly to initialize a generic function
metaobject. Portable programs must not call \cdf{shared-initialize} directly to
initialize or reinitialize a generic function metaobject. Portable programs must
not call \cdf{change-class} to change the class of any generic function
metaobject or to turn a non-generic-function object into a generic function
metaobject.

Since metaobject classes may not be redefined, no behavior is specified for the
result of calls to \cdf{update-instance-for-redefined-class} on generic function
metaobjects. Since the class of a generic function metaobject may not be
changed, no behavior is specified for the results of calls to
\cdf{update-instance-for-different-class} on generic function metaobjects.

During initialization or reinitialization, each initialization argument is
checked for errors and then associated with the generic function metaobject. The
value can then be accessed by calling the appropriate accessor as shown in
table~\ref{INITARGS-ACCESSORS-FOR-GENERIC-FUNCTION}.

This section begins with a description of the error checking and processing of
each initialization argument. This is followed by a table showing the generic
functions that can be used to access the stored initialization arguments. The
section ends with a set of restrictions on portable methods affecting generic
function metaobject initialization and reinitialization. 

In these descriptions, the phrase ``this argument defaults to \emph{value}''
means that when that initialization argument is not supplied, initialization or
reinitialization is performed as if \emph{value} had been supplied. For some
initialization arguments this could be done by the use of default initialization
arguments, but whether it is done this way is not specified. Implementations are
free to define default initialization arguments for specified generic function
metaobject classes. Portable programs are free to define default initialization
arguments for portable subclasses of the class \cdf{generic-function}.

Unless there is a specific note to the contrary, then during reinitialization,
if an initialization argument is not supplied, the previously stored value is
left unchanged. 

\begin{itemize}
\item 
  The \cd{:argument-precedence}-order argument is a list of symbols.

  An error is signaled if this argument appears but the \cd{:lambda-list}
  argument does not appear. An error is signaled if this value is not a proper
  list or if this value is not a permutation of the symbols from the required
  arguments part of the \cd{:lambda-list} initialization argument.

  When the generic function is being initialized or reinitialized, and this
  argument is not supplied, but the \cd{:lambda-list} argument is supplied,
  this value defaults to the symbols from the required arguments part of the
  \cd{:lambda-list} argument, in the order they appear in that argument. If
  neither argument is supplied, neither are initialized (see the description
  of \cd{:lambda-list}.)

\item The \cd{:declarations} argument is a list of declarations.

  An error is signaled if this value is not a proper list or if each of its
  elements is not a legal declaration.

  When the generic function is being initialized, and this argument is not
  supplied, it defaults to the empty list.

\item 
  The \cd{:documentation} argument is a string or \cdf{nil}.

  An error is signaled if this value is not a string or \cdf{nil}.

  If the generic function is being initialized, this argument defaults to \cdf{nil}.

\item 
  The \cd{:lambda-list} argument is a lambda list.

  An error is signaled if this value is not a proper generic function lambda list.

  When the generic function is being initialized, and this argument is not
  supplied, the generic function's lambda list is not initialized. The lambda
  list will be initialized later, either when the first method is added to the
  generic function, or a later reinitialization of the generic function.

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

\item 
  The \cd{:method-class} argument is a class metaobject.

  An error is signaled if this value is not a subclass of the class \cdf{method}.

  When the generic function is being initialized, and this argument is not
  supplied, it defaults to the class \cdf{standard-method}. 

\item 
  The \cd{:name} argument is an object.

  If the generic function is being initialized, this argument defaults to
  \cdf{nil}.
\end{itemize}

After the processing and defaulting of initialization arguments described above,
the value of each initialization argument is associated with the generic
function metaobject. These values can then be accessed by calling the
corresponding generic function. The correspondences are as follows:

\begin{table}[t]
\caption{Initialization arguments and accessors for generic function
  metaobjects}
\label{INITARGS-ACCESSORS-FOR-GENERIC-FUNCTION}
\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\textbf{Initialization Argument}&\textbf{Generic Function}\\
:argument-precedence-order&generic-function-argument-precedence-order\\
:declarations&generic-function-declarations\\
:documentation&documentation\\
:lambda-list&generic-function-lambda-list\\
:method-combination&generic-function-method-combination\\
:method-class&generic-function-method-class\\
:name&generic-function-name
\end{tabular}
\end{flushleft}
\end{table}

\textbf{Methods:}

It is not specified which methods provide the initialization and
reinitialization behavior described above. Instead, the information needed to
allow portable programs to specialize this behavior is presented as a set of
restrictions on the methods a portable program can define. The model is that
portable initialization methods have access to the generic function metaobject
when either all or none of the specified initialization has taken effect.

These restrictions govern the methods that a portable program can define on the
generic functions initialize-instance, \cdf{reinitialize-instance}, and
\cdf{shared-initialize}. These restrictions apply only to methods on these generic
functions for which the first specializer is a subclass of the class
\cdf{generic-function}. Other portable methods on these generic functions are not
affected by these restrictions.

\begin{itemize}
\item 
  Portable programs must not define methods on \cdf{shared-initialize}.
\item 
  For \cdf{initialize-instance} and \cdf{reinitialize-instance}:
  \begin{itemize}
  \item 
    Portable programs must not define primary methods.
  \item 
    Portable programs may define around-methods, but these must be extending, not overriding methods.
  \item 
    Portable before-methods must assume that when they are run, none of the
    initialization behavior described above has been completed. 
  \item 
    Portable after-methods must assume that when they are run, all of the
    initialization behavior described above has been completed. 
  \end{itemize}
\end{itemize}

The results are undefined if any of these restrictions are violated.

\subsection{Initialization of Method Metaobjects}

A method metaobject can be created by calling \cdf{make-instance}. The initialization
arguments establish the definition of the method. A method metaobject cannot be
redefined; calling \cdf{reinitialize-instance} signals an error. 

Initialization of a method metaobject must be done by calling
\cdf{make-instance} and allowing it to call \cdf{initialize-instance}. Portable
programs must not call \cdf{initialize-instance} directly to initialize a method
metaoject. Portable programs must not call \cdf{shared-initialize} directly to
initialize a method metaobject. Portable programs must not call
\cdf{change-class} to change the class of any method metaobject or to turn a
non-method object into a method metaobject.

Since metaobject classes may not be redefined, no behavior is specified for the
result of calls to \cdf{update-instance-for-redefined-class} on method
metaobjects. Since the class of a method metaobject cannot be changed, no
behavior is specified for the result of calls to
\cdf{update-instance-for-different-class} on method metaobjects.

During initialization, each initialization argument is checked for errors and
then associated with the method metaobject. The value can then be accessed by
calling the appropriate accessor as shown in
table~\ref{INITARGS-ACCESSORS-FOR-METHOD-METAOBJECTS}.

This section begins with a description of the error checking and processing of
each initialization argument. This is followed by a table showing the generic
functions that can be used to access the stored initialization arguments. The
section ends with a set of restrictions on portable methods affecting method
metaobject initialization.

In these descriptions, the phrase ``this argument defaults to \emph{value}''
means that when that initialization argument is not supplied, initialization is
performed as if \emph{value} had been supplied. For some initialization
arguments this could be done by the use of default initialization arguments, but
whether it is done this way is not specified. Implementations are free to define
default initialization arguments for specified method metaobject
classes. Portable programs are free to define default initialization arguments
for portable subclasses of the class \cdf{method}.

\begin{itemize}
\item The \cd{:qualifiers} argument is a list of method qualifiers. An error is
  signaled if this value is not a proper list, or if any element of the list is
  not a non-null atom. This argument defaults to the empty list.

\item The \cd{:lambda-list} argument is the unspecialized lambda list of the
  method. An error is signaled if this value is not a proper lambda list. If
  this value is not supplied, an error is signaled.

\item The \cd{:specializers} argument is a list of the specializer metaobjects
  for the method. An error is signaled if this value is not a proper list, or if
  the length of the list differs from the number of required arguments in the
  :lambda-list argument, or if any element of the list is not a specializer
  metaobject. If this value is not supplied, an error is signaled.

\item The \cd{:function} argument is a method function. It must be compatible
  with the methods on \cdf{compute-effective-method} defined for this class of
  method and generic function with which it will be used. That is, it must
  accept the same number of arguments as all uses of \cdf{call-method} that will
  call it supply. (See \cdf{compute-effective-method} for more information.) An
  error is signaled if this argument is not supplied.

\item When the method being initialized is an instance of a subclass of
  \cdf{standard-accessor-method}, the \cd{:slot-definition} initialization
  argument must be provided. Its value is the direct slot definition metaobject
  which defines this accessor method. An error is signaled if the value is not
  an instance of a subclass of \cdf{direct-slot-definition}.

\item The \cd{:documentation} argument is a string or \cdf{nil}. An error is
  signaled if this value is not a string or \cdf{nil}. This argument defaults to
  \cdf{nil}.
\end{itemize}

After the processing and defaulting of initialization arguments described
above, the value of each initialization argument is associated with the
method metaobject. These values can then be accessed by calling the
corresponding generic function. The correspondences are as follows:

\begin{table}[t]
\caption{Initialization arguments and accessors for method metaobjects}
\label{INITARGS-ACCESSORS-FOR-METHOD-METAOBJECTS}
\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\textbf{Initialization Argument}&\textbf{Generic Function}\\
:qualifiers&method-qualifiers\\
:lambda-list&method-lambda-list\\
:specializers&method-specializers\\
:function&method-function\\
:slot-definition&accessor-method-slot-definition\\
:documentation&documentation
\end{tabular}
\end{flushleft}
\end{table}

\textbf{Methods:}

It is not specified which methods provide the initialization behavior described
above. Instead, the information needed to allow portable programs to specialize
this behavior is presented in as a set of restrictions on the methods a portable
program can define. The model is that portable initialization methods have
access to the method metaobject when either all or none of the specified
initialization has taken effect.

These restrictions govern the methods that a portable program can define on the
generic functions \cdf{initialize-instance}, \cdf{reinitialize-instance}, and
shared-initialize. These restrictions apply only to methods on these generic
functions for which the first specializer is a subclass of the class
\cdf{method}. Other portable methods on these generic functions are not affected
by these restrictions.

\begin{itemize}
\item Portable programs must not define methods on shared-initialize or
  \cdf{reinitialize-instance}.
\item For initialize-instance:
  \begin{itemize}
  \item 
    Portable programs must not define primary methods.
  \item 
    Portable programs may define around-methods, but these must be
    extending, not overriding methods.
  \item 
    Portable before-methods must assume that when they are run, none of the
    initialization behavior described above has been completed.
  \item 
    Portable after-methods must assume that when they are run, all of the
    initialization behavior described above has been completed.
  \end{itemize}
\end{itemize}

The results are undefined if any of these restrictions are violated.

\subsection{Initialization of Slot Definition Metaobjects}
\label{INITIALIZATION-OF-SLOT-DEFINITION-METAOBJECTS}

A slot definition metaobject can be created by calling \cdf{make-instance}. The
initialization arguments establish the definition of the slot definition. A slot
definition metaobject cannot be redefined; calling \cdf{reinitialize-instance}
signals an error.

Initialization of a slot definition metaobject must be done by calling
\cdf{make-instance} and allowing it to call \cdf{initialize-instance}. Portable
programs must not call \cdf{initialize-instance} directly to initialize a slot
definition metaobject. Portable programs must not call \cdf{shared-initialize}
directly to initialize a slot definition metaobject. Portable programs must not
call \cdf{change-class} to change the class of any slot definition metaobject or
to turn a non-slot-definition object into a slot definition metaobject.

Since metaobject classes may not be redefined, no behavior is specified for the
result of calls to update\cdf{-instance-for-redefined-class} on slot definition
metaobjects. Since the class of a slot definition metaobject cannot be changed,
no behavior is specified for the result of calls to
\cdf{update-instance-for-different-class} on slot definition metaobjects.

During initialization, each initialization argument is checked for errors and
then associated with the slot definition metaobject. The value can then be
accessed by calling the appropriate accessor as shown in
table~\ref{Initialization-arguments-and-accessors-for-slot-definition-metaobjects}.

This section begins with a description of the error checking and processing of
each initialization argument. This is followed by a table showing the generic
functions that can be used to access the stored initialization arguments.

In these descriptions, the phrase ``this argument defaults to \emph{value''}
means that when that initialization argument is not supplied, initialization is
performed as if \emph{value} had been supplied. For some initialization
arguments this could be done by the use of default initialization arguments, but
whether it is done this way is not specified. Implementations are free to define
default initialization arguments for specified slot definition metaobject
classes. Portable programs are free to define default initialization arguments
for portable subclasses of the class slot-definition.

\begin{itemize}
\item The \cdf{:name} argument is a slot name. An error is signaled if this
  argument is not a symbol which can be used as a variable name. An error is
  signaled if this argument is not supplied.

\item The \cdf{:initform} argument is a form. The \cdf{:initform} argument
  defaults to nil. An error is signaled if the :initform argument is supplied,
  but the \cdf{:initfunction} argument is not supplied.

\item The \cdf{:initfunction} argument is a function of zero arguments which,
  when called, evaluates the \cdf{:initform} in the appropriate lexical
  environment. The \cdf{:initfunction} argument defaults to false. An error is
  signaled if the \cdf{:initfunction} argument is supplied, but the :initform
  argument is not supplied.

\item The \cdf{:type} argument is a type specifier name. An error is signaled
  otherwise. The \cd{:type} argument defaults to the symbol \cdf{t}.

\item The \cd{:allocation} argument is a symbol. An error is signaled
  otherwise. The \cd{:allocation} argument defaults to the symbol
  \cd{:instance}.

\item The \cd{:initargs} argument is a list of symbols. An error is signaled if
  this argument is not a proper list, or if any element of this list is not a
  symbol. The \cd{:initargs} argument defaults to the empty list.

\item The \cd{:readers} argument is a list of function names. An error is signaled if
  it is not a proper list, or if any element is not a valid function name. It
  defaults to the empty list. An error is signaled if this argument is supplied
  and the metaobject is not a direct slot definition.

\item The \cd{:writers} argument is a list of function names. An error is signaled if
  it is not a proper list, or if any element is not a valid function name. It
  defaults to the empty list. An error is signaled if this argument is supplied
  and the metaobject is not a direct slot definition.

\item The \cd{:documentation} argument is a string or \cdf{nil}. An error is
  signaled otherwise. The \cd{:documentation} argument defaults to \cdf{nil}.
\end{itemize}

After the processing and defaulting of initialization arguments described above,
the value of each initialization argument is associated with the slot definition
metaobject. These values can then be accessed by calling the corresponding
generic function. The correspondences are as follows: 

\begin{table}[t]
\caption{Initialization arguments and accessors for slot definition metaobjects}
\label{Initialization-arguments-and-accessors-for-slot-definition-metaobjects}
\begin{flushleft}
\cf
\begin{tabular}{@{}ll@{}}
\textbf{Initialization Argument}&\textbf{Generic Function}\\
:name&slot-definition-name\\
:initform&slot-definition-initform\\
:initfunction&slot-definition-initfunction\\
:type&slot-definition-type\\
:allocation&slot-definition-allocation\\
:initargs&slot-definition-initargs\\
:readers&slot-definition-readers\\
:writers&slot-definition-writers\\
:documentation&documentation
\end{tabular}
\end{flushleft}
\end{table}

\textbf{Methods:}

It is not specified which methods provide the initialization and
reinitialization behavior described above. Instead, the information needed to
allow portable programs to specialize this behavior is presented as a set of
restrictions on the methods a portable program can define. The model is that
portable initialization methods have access to the slot definition metaobject
when either all or none of the specified initialization has taken effect.

These restrictions govern the methods that a portable program can define on the
generic functions \cdf{initialize-instance}, \cdf{reinitialize-instance}, and
\cdf{shared-initialize}. These restrictions apply only to methods on these
generic functions for which the first specializer is a subclass of the class
\cdf{slot-definition}. Other portable methods on these generic functions are not
affected by these restrictions.

\begin{itemize}
\item Portable programs must not define methods on \cdf{shared-initialize} or
  \cdf{reinitialize-instance}.

\item For \cdf{initialize-instance}:

  \begin{itemize}
  \item Portable programs must not define primary methods.

  \item Portable programs may define around-methods, but these must be
    extending, not overriding methods.

  \item Portable before-methods must assume that when they are run, none of the
    initialization behavior described above has been completed.

  \item Portable after-methods must assume that when they are run, all of the
    initialization behavior described above has been completed.
  \end{itemize}
\end{itemize}

The results are undefined if any of these restrictions are violated.

\begin{defun}[Function]
intern-eql-specializer object

\textbf{Arguments:}

The \emph{object} argument is any Lisp object.

\textbf{Values:}

The result is the \cdf{eql} specializer metaobject for object.

\textbf{Purpose:}

This function returns the unique \cdf{eql} specializer metaobject for object, creating
one if necessary. Two calls to \cdf{intern-eql-specializer} with \cdf{eql} arguments will
return the same (i.e., \cdf{eq}) value. 

\textbf{Notes:}

The result of calling \cdf{eql-specializer}-object on the result of a call to
intern-eql-special-izer is only guaranteed to be \cdf{eql} to the original object
argument, not necessarily \cdf{eq}.
\end{defun}

\begin{defun}[Generic Function]
make-instance class &rest initargs

\textbf{Arguments:}

The \emph{class} argument is a class metaobject or a class name.

The \emph{initargs} argument is a list of alternating initialization argument names and
values. 

\textbf{Values:}

The result is a newly allocated and initialized instance of class.

\textbf{Purpose:}

The generic function \cdf{make-instance} creates and returns a new instance of the
given class. Its behavior and use is described in the CLOS specification. 

\textbf{Methods:}

\begin{defun}[Primary Method]
make-instance (class symbol) &rest initargs

This method simply invokes \cdf{make-instance} recursively on the arguments (find-class class) and initargs.
\end{defun}

\begin{defun}[Primary Method]
make-instance (class standard-class) &rest initargs
make-instance (class funcallable-standard-class) &rest initargs

These methods implement the behavior of \cdf{make-instance} described in the CLOS
specification section~\ref{Object-Creation-and-Initialization-SECTION}.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
make-method-lambda generic-function method lambda-expression environment

\textbf{Arguments:}

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

The \emph{method} argument is a (possibly uninitialized) method metaobject.

The \emph{lambda-expression} argument is a lambda expression.

The \emph{environment} argument is the same as the \cd{\&environment} argument
to macro expansion functions.

\textbf{Values:}

This generic function returns two values. The first is a lambda expression, the
second is a list of initialization arguments and values.

\textbf{Purpose:}

This generic function is called to produce a lambda expression which can itself
be used to produce a method function for a method and generic function with the
specified classes. The generic function and method the method function will be
used with are not required to be the given ones. Moreover, the method metaobject
may be uninitialized.

Either the function \cdf{compile}, the special operator \cdf{function} or the
function \cdf{coerce} must be used to convert the lambda expression to a method
function. The method function itself can be applied to arguments with \cdf{apply} or
\cdf{funcall}.

When a method is actually called by an effective method, its first argument will
be a list of the arguments to the generic function. Its remaining arguments will
be all but the first argument passed to \cdf{call-method}. By default, all
method functions must accept two arguments: the list of arguments to the generic
function and the list of next methods.

For a given generic function and method class, the applicable methods on
\cdf{make-method-lambda} and \cdf{compute-effective-method} must be consistent
in the following way: each use of \cdf{call-method} returned by the method on
\cdf{compute-effective-method} must have the same number of arguments, and the
method lambda returned by the method on \cdf{make-method-lambda} must accept a
corresponding number of arguments.

Note that the system-supplied implementation of \cdf{call-next-method} is not
required to handle extra arguments to the method function. Users who define
additional arguments to the method function must either redefine or forego
\cdf{call-next-method}. (See the example below.)

When the method metaobject is created with \cdf{make-instance}, the method
function must be the value of the \cd{:function} initialization argument. The
additional initialization arguments, returned as the second value of this
generic function, must also be passed in this call to \cdf{make-instance}.

\textbf{Methods:}

\begin{defun}[Primary Method]
make-method-lambda (generic-function standard-generic-function) (method
   standard-method) lambda-expression environment

This method returns a method lambda which accepts two arguments, the list of
arguments to the generic function, and the list of next methods. What
initialization arguments may be returned in the second value are unspecified.

This method can be overridden.

This example shows how to define a kind of method which, from within the body of
the method, has access to the actual method metaobject for the method. This
simplified code overrides whatever method combination is specified for the
generic function, implementing a simple method combination supporting only
primary methods, \cdf{call-next-method} and \cdf{next-method-p}. (In addition,
its a simplified version of \cdf{call-next-method} which does no error
checking.)

Notice that the extra lexical function bindings get wrapped around the body
before \cdf{call-next-method} is called. In this way, the user's definition of
\cdf{call-next-method} and \cdf{next-method-p} are sure to override the system's
definitions.

\begin{lisp}
(defclass my-generic-function (standard-generic-function)\\*
~~~~()\\*
~~(:default-initargs :method-class (find-class 'my-method)))\\*
\\
(defclass my-method (standard-method) ())\\*
\\
(defmethod \cdf{make-method-lambda} ((gf my-generic-function) (method my-method)\\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~lambda-expression environment)\\*
~~(declare (ignore environment))\\*
~~`(lambda (args next-methods this-method)\\*
~~~~ (,(\cdf{call-next-method} gf method \\*
~~~~~~~~ `(lambda ,(cadr lambda-expression)\\*
~~~~~~~~~~~~(flet ((this-method () this-method) \\*
~~~~~~~~~~~~~~(\cdf{call-next-method} (\&rest cnm-args)\\*
~~~~~~~~~~~~~~~~(funcall (method-function (car next-methods))\\*
~~~~~~~~~~~~~~~~~~(or cnm-args args) (cdr next-methods) (car next-methods)))\\*
~~~~~~~~~~~~~~(next-method-p ()\\*
~~~~~~~~~~~~~~~~(not (null next-methods))))\\*
~~~~~~~~~~~~~~,@(cddr lambda-expression))) environment) args next-methods)))\\*
\\
(defmethod compute-effective-method ((gf my-generic-function)\\*
~~method-combination methods)\\*
~~`(call-method ,(car methods) ,(cdr methods) ,(car methods)))\\*
\end{lisp}
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
map-dependents metaobject function

\textbf{Arguments:}

The \emph{metaobject} argument is a class or generic function metaobject.

The \emph{function} argument is a function which accepts one argument.

\textbf{Values:}

The value returned is unspecified.

\textbf{Purpose:}

This generic function applies function to each of the dependents of
metaobject. The order in which the dependents are processed is not specified,
but function is applied to each dependent once and only once. If, during the
mapping, \cdf{add-dependent} or \cdf{remove-dependent} is called to alter the
dependents of metaobject, it is not specified whether the newly added or removed
dependent will have function applied to it.

\textbf{Methods:}

\begin{defun}[Primary Method]
map-dependents (metaobject standard-class) function

This method has no specified behavior beyond that which is specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

\begin{tabbing}
    \cdf{add-dependent} (standard-class t)\\*
    \cdf{remove-dependent} (standard-class t) 
\end{tabbing}
\end{defun}

\begin{defun}[Primary Method]
map-dependents (metaobject funcallable-standard-class) function

This method has no specified behavior beyond that which is specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

    \cdf{add-dependent} (funcallable-standard-class t)
    \cdf{remove-dependent} (funcallable-standard-class t) 
\end{defun}

\begin{defun}[Primary Method]
map-dependents (metaobject standard-generic-function) function

This method has no specified behavior beyond that which is specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

    \cdf{add-dependent} (standard-generic-function t)
    \cdf{remove-dependent} (standard-generic-function t) 
\end{defun}

\textbf{Notes:}

See the section~\ref{DEPENDENT-MAINTENANCE-PROTOCOL} for remarks about the use
of this facility.
\end{defun}

\begin{defun}[Generic Function]
method-function \\
method-generic-function \\
method-lambda-list \\
method-specializers \\
method-qualifiers \\
accessor-method-slot-definition

The following generic functions are described together
under~\ref{READERS-FOR-GENERIC-FUNCTION-METAOBJECTS}: method-function,
method-generic-function, method-lambda-list, method-specializers,
method-qualifiers and accessor-method-slot-definition.
\end{defun}

\subsection{Readers for Class Metaobjects}
\label{READERS-FOR-CLASS-METAOBJECTS}
       
In this and the immediately following sections, the ``reader'' generic functions
which simply return information associated with a particular kind of metaobject
are presented together. General information is presented first, followed by a
description of the purpose of each, and ending with the specified methods for
these generic functions.

The reader generic functions which simply return information associated with
class metaobjects are presented together in this section.

Each of the reader generic functions for class metaobjects has the same syntax,
accepting one required argument called \emph{class}, which must be an class
metaobject; otherwise, an error is signaled. An error is also signaled if the
class metaobject has not been initialized.

These generic functions can be called by the user or the implementation.

For any of these generic functions which returns a list, such lists will not be
mutated by the implementation. The results are undefined if a portable program
allows such a list to be mutated.

\begin{defun}[Generic Function]
class-default-initargs class

Returns a list of the default initialization arguments for \emph{class}. Each
element of this list is a canonicalized default initialization argument. The
empty list is returned if class has no default initialization arguments.

During finalization \cdf{finalize-inheritance} calls
\cdf{compute-default-initargs} to compute the default initialization arguments
for the class. That value is associated with the class metaobject and is
returned by \cdf{class-default-initargs}.

This generic function signals an error if \emph{class} has not been finalized.
\end{defun}

\begin{defun}[Generic Function]
class-direct-default-initargs class

Returns a list of the direct default initialization arguments for class. Each
element of this list is a canonicalized default initialization argument. The
empty list is returned if class has no direct default initialization
arguments. This is the defaulted value of the \cd{:direct-default-initargs}
initialization argument that was associated with the class during initialization
or reinitialization.
\end{defun}

\begin{defun}[Generic Function]
class-direct-slots class

Returns a set of the direct slots of \emph{class}. The elements of this set are direct
slot definition metaobjects. If the class has no direct slots, the empty set is
returned. This is the defaulted value of the \cd{:direct-slots} initialization
argument that was associated with the class during initialization and
reinitialization.
\end{defun}

\begin{defun}[Generic Function]
class-direct-subclasses class

Returns a set of the direct subclasses of \emph{class}. The elements of this set are
class metaobjects that all mention this class among their direct
superclasses. The empty set is returned if class has no direct subclasses. This
value is maintained by the generic functions \cdf{add-direct-subclass} and
\cdf{remove-direct-subclass}.
\end{defun}

\begin{defun}[Generic Function]
class-direct-superclasses class

Returns a list of the direct superclasses of \emph{class}. The elements of this
list are class metaobjects. The empty list is returned if class has no direct
superclasses. This is the defaulted value of the \cd{:direct-superclasses}
initialization argument that was associated with the class during initialization
or reinitialization.
\end{defun}

\begin{defun}[Generic Function]
class-finalized-p class

Returns true if \emph{class} has been finalized. Returns false otherwise. Also
returns false if the \emph{class} has not been initialized.
\end{defun}

\begin{defun}[Generic Function]
class-name class

Returns the name of \emph{class}. This value can be any Lisp object, but is usually a
symbol, or nil if the class has no name. This is the defaulted value of the
\cd{:name} initialization argument that was associated with the class during
initialization or reinitialization. (Also see (\cdf{{setf class-name}}).)
\end{defun}

\begin{defun}[Generic Function]
class-precedence-list class

Returns the class precedence list of \emph{class}. The elements of this list are
class metaobjects.

During class finalization \cdf{finalize-inheritance} calls
\cdf{compute-class-precedence-list} to compute the class precedence list of the
class. That value is associated with the class metaobject and is returned by
\cdf{class-precedence-list}.

This generic function signals an error if \emph{class} has not been finalized.
\end{defun}

\begin{defun}[Generic Function]
class-prototype class

Returns a prototype instance of \cdf{class}. Whether the instance is initialized is
not specified. The results are undefined if a portable program modifies the
binding of any slot of prototype instance.

This generic function signals an error if \emph{class} has not been finalized.
\end{defun}

\begin{defun}[Generic Function]
class-slots class

Returns a possibly empty set of the slots accessible in instances of
\cdf{class}. The elements of this set are effective slot definition metaobjects.

During class finalization \cdf{finalize-inheritance} calls \cdf{compute-slots}
to compute the slots of the class. That value is associated with the class
metaobject and is returned by \cdf{class-slots}.

This generic function signals an error if \emph{class} has not been finalized.
\end{defun}

\textbf{Methods:}

The specified methods for the class metaobject reader generic functions are presented below.

Each entry in the table indicates a method on one of the reader generic
functions, specialized to a specified class. The number in each entry is a
reference to the full description of the method. The full descriptions appear
after the table.

\begin{table}[t]
\caption{Initialization arguments and accessors for slot definition metaobjects}
\begin{flushleft}
\cf
\begin{tabular}{@{}llll@{}}
&\textbf{standard-class and funcallable-standard-class}&\textbf{forward-referenced-class}&\textbf{built-in-class}\\
class-default-initargs&2&3&4\\
class-direct-default-initargs&1&4&4\\
class-direct-slots&1&4&4\\
class-direct-subclasses&9&9&7\\
class-direct-superclasses&1&4&7\\
class-finalized-p&2&6&5\\
class-name&1&1&8\\
\cdf{class-precedence-list}&2&3&7\\
class-prototype&10&10&10\\
\cdf{class-slots}&2&3&4
\end{tabular}
\end{flushleft}
\end{table}


\begin{enumerate}
\item This method returns the value which was associated with the class
  metaobject during initialization or reinitialization.

\item This method returns the value associated with the class metaobject by
  \cdf{finalize-inheritance} (standard-class) or \cdf{finalize-inheritance}
  (funcallable-standard-class).

\item This method signals an error.

\item This method returns the empty list.

\item This method returns true.

\item This method returns false.

\item This method returns a value derived from the information in
  table~\ref{MOP-CLASSES}, except that implementation-specific modifications are
  permitted as described in
  section~\ref{IMPLEMENTATION-AND-USER-SPECIALIZATION}.

\item This method returns the name of the built-in class.

\item This methods returns a value which is maintained by \cd{add-direct-subclass
    (class class)} and \cd{remove-direct-subclass (class class)}. This method can be
  overridden only if those methods are overridden as well.

\item No behavior is specified for this method beyond that specified for the
  generic function.
\end{enumerate}

\subsection{Readers for Generic Function Metaobjects}
\label{READERS-FOR-GENERIC-FUNCTION-METAOBJECTS}

The reader generic functions which simply return information associated with
generic function metaobjects are presented together in this section.

Each of the reader generic functions for generic function metaobjects has the
same syntax, accepting one required argument called \emph{generic-function},
which must be a generic function metaobject; otherwise, an error is signaled. An
error is also signaled if the generic function metaobject has not been
initialized.

These generic functions can be called by the user or the implementation.

The list returned by this generic function will not be mutated by the
implementation. The results are undefined if a portable program mutates the list
returned by this generic function.

\begin{defun}[Generic Function]
generic-function-argument-precedence-order generic-function

Returns the argument precedence order of the generic function. This value is a
list of symbols, a permutation of the required parameters in the lambda list of
the generic function. This is the defaulted value of the
\cd{:argument-precedence-order} initialization argument that was associated with the
generic function metaobject during initialization or reinitialization.
\end{defun}

\begin{defun}[Generic Function]
generic-function-declarations generic-function

Returns a possibly empty list of the declarations of the generic function. The
elements of this list are declarations. This list is the defaulted value of the
\cd{:declarations} initialization argument that was associated with the generic
function metaobject during initialization or reinitialization.
\end{defun}

\begin{defun}[Generic Function]
generic-function-lambda-list generic-function

Returns the lambda list of the generic function. This is the defaulted value of
the \cd{:lambda-list} initialization argument that was associated with the generic
function metaobject during initialization or reinitialization. An error is
signaled if the lambda list has yet to be supplied.
\end{defun}

\begin{defun}[Generic Function]
generic-function-method-class generic-function

Returns the default method class of the generic function. This class must be a
subclass of the class \cdf{method}. This is the defaulted value of the \cd{:method-class}
initialization argument that was associated with the generic function metaobject
during initialization or reinitialization.
\end{defun}

\begin{defun}[Generic Function]
generic-function-method-combination generic-function

Returns the method combination of the generic function. This is a method
combination metaobject. This is the defaulted value of the \cd{:method-combination}
initialization argument that was associated with the generic function metaobject
during initialization or reinitialization.
\end{defun}

\begin{defun}[Generic Function]
generic-function-methods generic-function

Returns the set of methods currently connected to the generic function. This is
a set of method metaobjects. This value is maintained by the generic functions
\cdf{add-method} and \cdf{remove-method}.
\end{defun}

\begin{defun}[Generic Function]
generic-function-name generic-function

Returns the name of the generic function, or \cdf{nil} if the generic function has no
name. This is the defaulted value of the :name initialization argument that was
associated with the generic function metaobject during initialization or
reinitialization. (Also see \cdf{{(setf generic-function-name)}}.)
\end{defun}

\textbf{Methods:}

The specified methods for the generic function metaobject reader generic
functions are presented below.

\begin{defun}[Primary Method]
generic-function-argument-precedence-order (generic-function standard-generic-function) \\
generic-function-declarations (generic-function standard-generic-function) \\
generic-function-lambda-list (generic-function standard-generic-function) \\
generic-function-method-class (generic-function standard-generic-function) \\
generic-function-method-combination (generic-function standard-generic-function) \\
generic-function-name (generic-function standard-generic-function) 

No behavior is specified for these methods beyond that which is specified for
their respective generic functions.
\end{defun}

\begin{defun}[Primary Method]
generic-function-methods (generic-function standard-generic-function)

No behavior is specified for this method beyond that which is specified for
their respective generic functions.

The value returned by this method is maintained by \cd{add-method
(standard-generic-function standard-method)} and \cd{remove-method
(standard-generic-function standard-method)}.
\end{defun}

\subsection{Readers for Method Metaobjects}
\label{READERS-FOR-METHOD-METAOBJECTS}

The reader generic functions which simply return information associated with
method metaobjects are presented together here in the format described under
section~\ref{READERS-FOR-CLASS-METAOBJECTS}.

Each of these reader generic functions have the same syntax, accepting one
required argument called method, which must be a method metaobject; otherwise,
an error is signaled. An error is also signaled if the method metaobject has not
been initialized.

These generic functions can be called by the user or the implementation.

For any of these generic functions which returns a list, such lists will not be
mutated by the implementation. The results are undefined if a portable program
allows such a list to be mutated.

\begin{defun}[Generic Function]
method-function method

Returns the method function of \emph{method}. This is the defaulted value of the
\cd{:function} initialization argument that was associated with the method during
initialization.
\end{defun}

\begin{defun}[Generic Function]
method-generic-function method

Returns the generic function that \emph{method} is currently connected to, or \cdf{nil} if it
is not currently connected to any generic function. This value is either a
generic function metaobject or \cdf{nil}. When a method is first created it is not
connected to any generic function. This connection is maintained by the generic
functions \cdf{add-method} and \cdf{remove-method}.
\end{defun}

\begin{defun}[Generic Function]
method-lambda-list method

Returns the (unspecialized) lambda list of \emph{method}. This value is a Common Lisp
lambda list. This is the defaulted value of the \cd{:lambda-list} initialization
argument that was associated with the method during initialization.
\end{defun}

\begin{defun}[Generic Function]
method-specializers method

Returns a list of the specializers of \emph{method}. This value is a list of
specializer metaobjects. This is the defaulted value of the \cd{:specializers}
initialization argument that was associated with the method during
initialization.
\end{defun}

\begin{defun}[Generic Function]
method-qualifiers method

Returns a (possibly empty) list of the qualifiers of \emph{method}. This value
is a list of non-\cdf{nil} atoms. This is the defaulted value of the \cd{:qualifiers}
initialization argument that was associated with the method during
initialization.
\end{defun}

\begin{defun}[Generic Function]
accessor-method-slot-definition method

This accessor can only be called on accessor methods. It returns the direct slot
definition metaobject that defined this method. This is the value of the
\cd{:slot-definition} initialization argument associated with the method during
initialization.
\end{defun}

\textbf{Methods:}

The specified methods for the method metaobject readers are presented below.

\begin{defun}[Primary Method]
method-function (method standard-method) \\
method-lambda-list (method standard-method) \\
method-specializers (method standard-method) \\
method-qualifiers (method standard-method)

No behavior is specified for these methods beyond that which is specified for
their respective generic functions.
\end{defun}

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

No behavior is specified for this method beyond that which is specified for its
generic function.

The value returned by this method is maintained by \cd{add-method
(standard-generic-function standard-method)} and \cd{remove-method
(standard-generic-function standard-method)}.
\end{defun}

\begin{defun}[Primary Method]
accessor-method-slot-definition (method standard-accessor-method)

No behavior is specified for this method beyond that which is specified for its
generic function.
\end{defun}

\subsection{Readers for Slot Definition Metaobjects}
\label{READERS-FOR-SLOT-DEFINITION-METAOBJECTS}

The reader generic functions which simply return information associated with
slot definition metaobjects are presented together here in the format described
under section~\ref{READERS-FOR-CLASS-METAOBJECTS}.

Each of the reader generic functions for slot definition metaobjects has the
same syntax, accepting one required argument called \emph{slot}, which must be a slot
definition metaobject; otherwise, an error is signaled. An error is also
signaled if the slot definition metaobject has not been initialized.

These generic functions can be called by the user or the implementation.

For any of these generic functions which returns a list, such lists will not be
mutated by the implementation. The results are undefined if a portable program
allows such a list to be mutated.

Generic Functions:

\begin{defun}[Generic Function]
slot-definition-allocation slot

Returns the allocation of \emph{slot}. This is a symbol. This is the defaulted
value of the \cd{:allocation} initialization argument that was associated with
the slot definition metaobject during initialization.
\end{defun}

\begin{defun}[Generic Function]
slot-definition-initargs slot

Returns the set of initialization argument keywords for \emph{slot}. This is the
defaulted value of the \cd{:initargs} initialization argument that was
associated with the slot definition metaobject during initialization.
\end{defun}

\begin{defun}[Generic Function]
slot-definition-initform slot

Returns the initialization form of \emph{slot}. This can be any form. This is
the defaulted value of the \cd{:initform} initialization argument that was
associated with the slot definition metaobject during initialization. When slot
has no initialization form, the value returned is unspecified (however,
\cdf{slot-definition-initfunction} is guaranteed to return \cdf{nil}).
\end{defun}

\begin{defun}[Generic Function]
slot-definition-initfunction slot

Returns the initialization function of \emph{slot}. This value is either a function of
no arguments, or \cdf{nil}, indicating that the slot has no initialization
function. This is the defaulted value of the \cd{:initfunction} initialization
argument that was associated with the slot definition metaobject during
initialization.
\end{defun}

\begin{defun}[Generic Function]
slot-definition-name slot

Returns the name of \emph{slot}. This value is a symbol that can be used as a
variable name. This is the value of the \cd{:name} initialization argument that
was associated with the slot definition metaobject during initialization.
\end{defun}

\begin{defun}[Generic Function]
slot-definition-type slot

Returns the type of \emph{slot}. This is a type specifier name. This is the
defaulted value of the \cd{:type} initialization argument that was associated
with the slot definition metaobject during initialization.
\end{defun}

\textbf{Methods:}

The specified methods for the slot definition metaobject readers are presented below.

\begin{defun}[Primary Method]
slot-definition-allocation (slot-definition standard-slot-definition) \\
slot-definition-initargs (slot-definition standard-slot-definition) \\
slot-definition-initform (slot-definition standard-slot-definition) \\
slot-definition-initfunction (slot-definition standard-slot-definition) \\
slot-definition-name (slot-definition standard-slot-definition) \\
slot-definition-type (slot-definition standard-slot-definition)

No behavior is specified for these methods beyond that which is specified for
their respective generic functions.
\end{defun}

\textbf{Direct Slot Definition Metaobjects:}

The following additional reader generic functions are defined for direct slot
definition metaobjects.

\begin{defun}[Generic Function]
slot-definition-readers direct-slot

Returns a (possibly empty) set of readers of the direct \emph{slot}. This value
is a list of function names. This is the defaulted value of the \cd{:readers}
initialization argument that was associated with the direct slot definition
metaobject during initialization.
\end{defun}

\begin{defun}[Generic Function]
slot-definition-writers direct-slot

Returns a (possibly empty) set of writers of the direct \emph{slot}. This value
is a list of function names. This is the defaulted value of the \cd{:writers}
initialization argument that was associated with the direct slot definition
metaobject during initialization.
\end{defun}

\begin{defun}[Primary Method]
slot-definition-readers (direct-slot-definition standard-direct-slot-definition) \\
slot-definition-writers (direct-slot-definition standard-direct-slot-definition)

No behavior is specified for these methods beyond what is specified for their
generic functions.
\end{defun}

\textbf{Effective Slot Definition Metaobjects:}

The following reader generic function is defined for effective slot definition metaobjects.

\begin{defun}[Generic Function]
slot-definition-location effective-slot-definition

Returns the location of effective-slot-definition. The meaning and
interpretation of this value is described in the
section~\ref{INSTANCE-STRUCTURE-PROTOCOL}.

\begin{defun}[Primary Method]
slot-definition-location (effective-slot-definition standard-effective-slot-definition)

This method returns the value stored by
\end{defun}

\begin{defun}[Around Method]
compute-slots (standard-class) \\
compute-slots (funcallable-standard-class)

Stub
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
reader-method-class class direct-slot &rest initargs

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

The \emph{direct-slot} argument is a direct slot definition metaobject.

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

\textbf{Values:}

The value returned is a class metaobject.

\textbf{Purpose:}

This generic function is called to determine the class of reader methods created
during class initialization and reinitialization. The result must be a subclass
of standard-reader-method.

The \emph{initargs} argument must be the same as will be passed to
\cdf{make-instance} to create the reader method. The \emph{initargs} must
include \cd{:slot-definition} with slot-definition as its value.

\textbf{Methods:}

\begin{defun}[Primary Method]
reader-method-class (class standard-class) (direct-slot
  standard-direct-slot-definition) &rest initargs \\ 
reader-method-class (class funcallable-standard-class) (direct-slot
  standard-direct-slot-definition) &rest initargs

These methods return the class \cdf{standard-reader-method}. These methods
can be overridden.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
remove-dependent metaobject dependent

\textbf{Arguments:}

The \emph{metaobject} argument is a class or generic function metaobject.

The \emph{dependent} argument is an object.

\textbf{Values:}

The value returned by this generic function is unspecified.

\textbf{Purpose:}

This generic function removes \emph{dependent} from the dependents of
\emph{metaobject}. If dependent is not one of the dependents of
\emph{metaobject}, no error is signaled.

The generic function \cdf{map-dependents} can be called to access the set of
dependents of a class or generic function. The generic function
\cdf{add-dependent} can be called to add an object from the set of dependents of
a class or generic function. The effect of calling \cdf{add-dependent} or
\cdf{remove-dependent} while a call to \cdf{map-dependents} on the same class or
generic function is in progress is unspecified.

The situations in which \cdf{remove-dependent} is called are not specified.

\textbf{Methods:}

\begin{defun}[Primary Method]
remove-dependent (class standard-class) dependent

No behavior is specified for this method beyond that which is specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

\begin{tabbing}
    \cdf{add-dependent} (standard-class t)\\*
    \cdf{map-dependents} (standard-class t) 
\end{tabbing}
\end{defun}

\begin{defun}[Primary Method]
remove-dependent (class funcallable-standard-class) dependent

No behavior is specified for this method beyond that which is specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

\begin{tabbing}
    \cdf{add-dependent} (funcallable-standard-class t)\\*
    \cdf{map-dependents} (funcallable-standard-class t) 
\end{tabbing}
\end{defun}

\begin{defun}[Primary Method]
remove-dependent (generic-function standard-generic-function) dependent

No behavior is specified for this method beyond that which is specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

\begin{tabbing}
    \cdf{add-dependent} (standard-generic-function t)\\*
    \cdf{map-dependents} (standard-generic-function t) 
\end{tabbing}
\end{defun}

\textbf{Notes:}

See the section~\ref{DEPENDENT-MAINTENANCE-PROTOCOL} for remarks about the use
of this facility.
\end{defun}

\begin{defun}[Generic Function]
remove-direct-method specializer method

\textbf{Arguments:}

The \emph{specializer} argument is a specializer metaobject.

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

\textbf{Values:}

The value returned by remove-direct-method is unspecified.

\textbf{Purpose:}

This generic function is called to maintain a set of backpointers from a
specializer to the set of methods specialized to it. If \emph{method} is in the set it
is removed. If it is not, no error is signaled.

This set can be accessed as a list by calling the generic function
\cdf{specializer-direct-methods}. Methods are added to the set by
\cdf{add-direct-method}.

The generic function \cdf{remove-direct-method} is called by \cdf{remove-method}
whenever a method is removed from a generic function. It is called once for each
of the specializers of the method. Note that in cases where a specializer
appears more than once in the specializers of a method, this generic function
will be called more than once with the same specializer as argument.

The results are undefined if the \emph{specializer} argument is not one of the
specializers of the \emph{method} argument.

\textbf{Methods:}

\begin{defun}[Primary Method]
remove-direct-method (specializer class) (method method)

This method implements the behavior of the generic function for class
specializers. No behavior is specified for this method beyond that which is
specified for the generic function.

This method cannot be overridden unless the following methods are overridden as
well:

\begin{tabbing}
    add-direct-method (class method)\\*
    specializer-direct-generic-functions (class)\\*
    specializer-direct-methods (class)
\end{tabbing}
\end{defun}

\begin{defun}[Primary Method]
remove-direct-method (specializer \cdf{eql-specializer}) (method method)

This method implements the behavior of the generic function for eql
specializers. No behavior is specified for this method beyond that which is
specified for the generic function.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
remove-direct-subclass superclass subclass

\textbf{Arguments:}

The \emph{superclass} argument is a class metaobject.

The \emph{subclass} argument is a class metaobject.

\textbf{Values:}

The value returned by this generic function is unspecified.

\textbf{Purpose:}

This generic function is called to maintain a set of backpointers from a class
to its direct subclasses. It removes subclass from the set of direct subclasses
of \emph{superclass}. No error is signaled if \emph{subclass} is not in this
set.

Whenever a class is reinitialized, this generic function is called once with
each deleted direct superclass of the class.

\textbf{Methods:}

\begin{defun}[Primary Method]
remove-direct-subclass (superclass class) (subclass class)

No behavior is specified for this method beyond that which is specified for the
generic function.

This method cannot be overridden unless the following methods are overridden as
well:

\begin{tabbing}
    add-direct-subclass (class class)\\*
    class-direct-subclasses (class) 
\end{tabbing}
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
remove-method generic-function method

\textbf{Arguments:}

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

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

\textbf{Values:}

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

\textbf{Purpose:}

This generic function breaks the association between a generic function and one of its methods.

No error is signaled if the method is not among the methods of the generic function.

Breaking the association between the method and the generic function proceeds in
four steps: 
\begin{itemize}
\item (i) remove method from the set returned by \cdf{generic-function-methods}
  and arrange for \cdf{method-generic-function} to return \cdf{nil};

\item (ii) call \cdf{remove-direct-method} for each of the method's
  specializers;

\item (iii) call \cdf{compute-discriminating-function} and install its result
  with \cdf{set-funcallable-instance-function};

\item and (iv) update the dependents of the generic function.
\end{itemize}

The generic function \cdf{remove-method} can be called by the user or the implementation.

\textbf{Methods:}

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

No behavior is specified for this method beyond that which is specified for the
generic function.  
\end{defun}
\end{defun}

\begin{defun}[Function]
set-funcallable-instance-function funcallable-instance function

\textbf{Arguments:}

The \emph{funcallable-instance} argument is a funcallable instance (it must have
been returned by \cd{allocate-instance (funcallable-standard-class)}).

The function argument is a function.

\textbf{Values:}

The value returned by this function is unspecified.

\textbf{Purpose:}

This function is called to set or to change the function of a funcallable
instance. After \cdf{set-funcallable-instance-function} is called, any subsequent
calls to funcallable-instance will run the new function.
\end{defun}

\begin{defun}[Function]
(setf class-name) new-name class

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

The \emph{new-name} argument is any Lisp object.

\textbf{Values:}

This function returns its \emph{new-name} argument.

\textbf{Purpose:}

This function changes the name of \emph{class} to \emph{new-name}. This value is
usually a symbol, or \cdf{nil} if the class has no name.

This function works by calling \cdf{reinitialize-instance} with \emph{class} as
its first argument, the symbol \cd{:name} as its second argument and
\emph{new-name} as its third argument.
\end{defun}

\begin{defun}[Function]
(setf generic-function-name) new-name generic-function

\textbf{Arguments:}

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

The \emph{new-name} argument is a function name or \cdf{nil}.

\textbf{Values:}

This function returns its \emph{new-name} argument.

\textbf{Purpose:}

This function changes the name of generic-function to new-name. This value is
usually a function name (i.e., a symbol or a list of the form \cd{(setf
  symbol)}) or \cdf{nil}, if the generic function is to have no name.

This function works by calling \cdf{reinitialize-instance} with
\emph{generic-function} as its first argument, the symbol \cd{:name} as its
second argument and \emph{new-name} as its third argument.
\end{defun}

\begin{defun}[Generic Function]
(setf slot-value-using-class) new-value class object slot

\textbf{Arguments:}

The \emph{new-value} argument is an object.

The \emph{class} argument is a class metaobject. It is the class of the
\emph{object} argument.

The \emph{object} argument is an object.

The \emph{slot} argument is an effective slot definition metaobject.

\textbf{Values:}

This generic function returns the \emph{new-value} argument.

\textbf{Purpose:}

The generic function \cd{(setf slot-value-using-class)} implements the behavior
of the \cd{(setf slot-value)} function. It is called by \cd{(setf slot-value)}
with the class of object as its second argument and the pertinent effective slot
definition metaobject as its fourth argument.

The generic function \cd{(setf slot-value-using-class)} sets the value contained in
the given slot of the given object to the given new value; any previous value is
lost.

The results are undefined if the \emph{class} argument is not the class of the
\emph{object} argument, or if the slot argument does not appear among the set of
effective slots associated with the \emph{class} argument.

\textbf{Methods:}

\begin{defun}[Primary Method]
(setf slot-value-using-class) new-value (class standard-class) object (slot
    standard-effective-slot-definition) \\
(setf slot-value-using-class) new-value (class funcallable-standard-class)
    object (slot standard-effective-slot-definition)

These methods implement the full behavior of this generic function for slots
with allocation \cd{:instance} and \cd{:class}. If the supplied slot has an allocation
other than \cd{:instance} or \cd{:class} an error is signaled.

Overriding these methods is permitted, but may require overriding other methods
in the standard implementation of the slot access protocol.
\end{defun}

\begin{defun}[Primary Method]
(setf slot-value-using-class) new-value (class built-in-class) object slot

This method signals an error.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
slot-boundp-using-class class object slot

\textbf{Arguments:}

The \emph{class} argument is a class metaobject. It is the class of the
\emph{object} argument.

The \emph{object} argument is an object.

The \emph{slot} argument is an effective slot definition metaobject.

\textbf{Values:}

This generic function returns true or false.

\textbf{Purpose:}

This generic function implements the behavior of the \cdf{slot-boundp}
function. It is called by slot-boundp with the class of \emph{object} as its
first argument and the pertinent effective slot definition metaobject as its
third argument.

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

The results are undefined if the \emph{class} argument is not the class of the
\emph{object} argument, or if the \emph{slot} argument does not appear among the
set of effective slots associated with the \emph{class} argument.

\textbf{Methods:}

\begin{defun}[Primary Method]
slot-boundp-using-class (class standard-class) object (slot standard-effective-slot-definition) \\
slot-boundp-using-class (class funcallable-standard-class) object (slot standard-effective-slot-definition)

These methods implement the full behavior of this generic function for slots
with allocation \cd{:instance} and \cd{:class}. If the supplied slot has an
allocation other than \cd{:instance} or \cd{:class} an error is signaled.

Overriding these methods is permitted, but may require overriding other methods
in the standard implementation of the slot access protocol.
\end{defun}

\begin{defun}[Primary Method]
slot-boundp-using-class (class built-in-class) object slot

This method signals an error.
\end{defun}

\textbf{Notes:}

In cases where the class metaobject class does not distinguish unbound slots,
true should be returned.
\end{defun}

\begin{defun}[Generic Function]
slot-definition-allocation \\
slot-definition-initargs \\
slot-definition-initform \\
slot-definition-initfunction \\
slot-definition-location \\
slot-definition-name \\
slot-definition-readers \\
slot-definition-writers \\
slot-definition-type

The following generic functions are described together under
section~\ref{READERS-FOR-SLOT-DEFINITION-METAOBJECTS}:
slot-definition-allocation, slot-definition-initargs, slot-definition-initform,
slot-definition-initfunction, slot-definition-location, slot-definition-name,
slot-definition-readers, slot-definition-writers and slot-definition-type.
\end{defun}

\begin{defun}[Generic Function]
slot-makunbound-using-class class object slot

\textbf{Arguments:}

The \emph{class} argument is a class metaobject. It is the class of the \emph{object} argument.

The \emph{object} argument is an object.

The \emph{slot} argument is an effective slot definition metaobject.

\textbf{Values:}

This generic function returns its \emph{object} argument.

\textbf{Purpose:}

This generic function implements the behavior of the \cdf{slot-makunbound}
function. It is called by \cdf{slot-makunbound} with the class of \emph{object}
as its first argument and the pertinent effective slot definition metaobject as
its third argument.

The generic function \cdf{slot-makunbound-using-class} restores a slot in an
object to its unbound state. The interpretation of ``restoring a slot to its
unbound state'' depends on the class metaobject class.

The results are undefined if the class argument is not the class of the
\emph{object} argument, or if the \emph{slot} argument does not appear among the
set of effective slots associated with the \emph{class} argument.

\textbf{Methods:}

\begin{defun}[Primary Method]
slot-makunbound-using-class (class standard-class) object (slot
  standard-effective-slot-definition) \\
slot-makunbound-using-class (class funcallable-standard-class) object (slot
  standard-effective-slot-definition)

  These methods implement the full behavior of this generic function for slots
  with allocation \cd{:instance} and \cd{:class}. If the supplied slot has an
  allocation other than \cd{:instance} or \cd{:class} an error is signaled.

Overriding these methods is permitted, but may require overriding other methods
in the standard implementation of the slot access protocol.
\end{defun}

\begin{defun}[Primary Method]
slot-makunbound-using-class (class built-in-class) object slot

This method signals an error.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
slot-value-using-class class object slot

\textbf{Arguments:}

The \emph{class} argument is a class metaobject. It is the class of the \emph{object} argument.

The \emph{object} argument is an object.

The slot argument is an effective slot definition metaobject.

\textbf{Values:}

The value returned by this generic function is an object.

\textbf{Purpose:}

This generic function implements the behavior of the \cdf{slot-value}
function. It is called by \cdf{slot-value} with the class of \emph{object} as
its first argument and the pertinent effective slot definition metaobject as its
third argument.

The generic function \cdf{slot-value-using-class} returns the value contained in
the given slot of the given object. If the slot is unbound \cdf{slot-unbound} is
called.

The results are undefined if the \emph{class} argument is not the class of the
\emph{object} argument, or if the \emph{slot} argument does not appear among the
set of effective slots associated with the \emph{class} argument.

\textbf{Methods:}

\begin{defun}[Primary Method]
slot-value-using-class (class standard-class) object (slot standard-effective-slot-definition) \\
slot-value-using-class (class funcallable-standard-class) object (slot standard-effective-slot-definition)

These methods implement the full behavior of this generic function for slots
with allocation \cd{:instance} and \cd{:class}. If the supplied slot has an
allocation other than \cd{:instance} or \cd{:class} an error is signaled.

Overriding these methods is permitted, but may require overriding other methods
in the standard implementation of the slot access protocol.
\end{defun}

\begin{defun}[Primary Method]
slot-value-using-class (class built-in-class) object slot

This method signals an error.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
specializer-direct-generic-functions specializer

\textbf{Arguments:}

The \emph{specializer} argument is a specializer metaobject.

\textbf{Values:}

The result of this generic function is a possibly empty list of generic function metaobjects.

\textbf{Purpose:}

This generic function returns the possibly empty set of those generic functions
which have a method with specializer as a specializer. The elements of this set
are generic function metaobjects. This value is maintained by the generic
functions \cdf{add-direct-method} and \cdf{remove-direct-method}.

\textbf{Methods:}

\begin{defun}[Primary Method]
specializer-direct-generic-functions (specializer class)

No behavior is specified for this method beyond that which is specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

    add-direct-method (class method)
    remove-direct-method (class method)
    specializer-direct-methods (class) 
\end{defun}

\begin{defun}[Primary Method]
specializer-direct-generic-functions (specializer \cdf{eql-specializer})

No behavior is specified for this method beyond that which is specified for the generic function.
\end{defun}
\end{defun}

\begin{defun}[Generic Function]
specializer-direct-methods specializer

\textbf{Arguments:}

The \emph{specializer} argument is a specializer metaobject.

\textbf{Values:}

The result of this generic function is a possibly empty list of method metaobjects.

\textbf{Purpose:}

This generic function returns the possibly empty set of those methods, connected
to generic functions, which have \emph{specializer} as a specializer. The elements of
this set are method metaobjects. This value is maintained by the generic
functions \cdf{add-direct-method} and \cdf{remove-direct-method}.

\textbf{Methods:}

\begin{defun}[Primary Method]
specializer-direct-methods (specializer class)

No behavior is specified for this method beyond that which is specified for the generic function.

This method cannot be overridden unless the following methods are overridden as well:

\begin{tabbing}
    add-direct-method (class method)\\*
    remove-direct-method (class method)\\*
    specializer-direct-generic-functions (class)
\end{tabbing}

\end{defun}

\begin{defun}[Primary Method]
specializer-direct-methods (specializer \cdf{eql-specializer})

No behavior is specified for this method beyond that which is specified for the
generic function.
\end{defun}
\end{defun}

\begin{defun}[Function]
standard-instance-access instance location

\textbf{Arguments:}

The \emph{instance} argument is an object.

The \emph{location} argument is a slot location.

\textbf{Values:}

The result of this function is an object.

\textbf{Purpose:}

This function is called to provide direct access to a slot in an instance. By
usurping the normal slot lookup protocol, this function is intended to provide
highly optimized access to the slots associated with an instance.

The following restrictions apply to the use of this function:

\begin{itemize}
\item The instance argument must be a standard instance (it must have been
  returned by \cd{allocate-instance (standard-class)}).

\item The \emph{instance} argument cannot be an non-updated obsolete instance.

\item The \emph{location} argument must be a location of one of the directly
  accessible slots of the instance's class.

\item The slot must be bound.
\end{itemize}

The results are undefined if any of these restrictions are not met.
\end{defun}

\begin{defun}[Generic Function]
update-dependent metaobject dependent &rest initargs

\textbf{Arguments:}

The \emph{metaobject} argument is a class or generic function metaobject. It is
the metaobject being reinitialized or otherwise modified.

The \emph{dependent} argument is an object. It is the dependent being updated.

The \emph{initargs} argument is a list of the initialization arguments for the
metaobject redefinition.

\textbf{Values:}

The value returned by \cdf{update-dependent} is unspecified.

\textbf{Purpose:}

This generic function is called to update a dependent of \emph{metaobject}.

When a class or a generic function is reinitialized each of its dependents is
updated. The initargs argument to \cdf{update-dependent} is the set of initialization
arguments received by \cdf{reinitialize-instance}.

When a method is added to a generic function, each of the generic function's
dependents is updated. The \emph{initargs} argument is a list of two elements: the
symbol \cdf{add-method}, and the method that was added.

When a method is removed from a generic function, each of the generic function's
dependents is updated. The \emph{initargs} argument is a list of two elements: the
symbol \cdf{remove-method}, and the method that was removed.

In each case, \cdf{map-dependents} is used to call \cdf{update-dependent} on each of the
dependents. So, for example, the update of a generic function's dependents when
a method is added could be performed by the following code:

\begin{lisp}
~~(map-dependents generic-function \\*
~~~~~~~~~~~~~~~~~~\#'(lambda (dep) \\*
~~~~~~~~~~~~~~~~~~~~~~(update-dependent generic-function \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~dep \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'add-method \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~new-method \\*
\end{lisp}
                                      
\textbf{Methods:}

There are no specified methods on this generic function.

\textbf{Notes:}

See the section~\ref{DEPENDENT-MAINTENANCE-PROTOCOL} for remarks about the use
of this facility.
\end{defun}

\begin{defun}[Generic Function]
validate-superclass class superclass

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

The \emph{superclass} argument is a class metaobject.

\textbf{Values:}

This generic function returns true or false.

\textbf{Purpose:}

This generic function is called to determine whether the class \emph{superclass}
is suitable for use as a superclass of \emph{class}.

This generic function can be be called by the implementation or user code. It is
called during class metaobject initialization and reinitialization, before the
direct superclasses are stored. If this generic function returns false, the
initialization or reinitialization will signal an error.

\textbf{Methods:}

\begin{defun}[Primary Method]
validate-superclass (class class) (superclass class)

This method returns true in three situations:

\begin{itemize}
\item (i) If the superclass argument is the class named t,
\item (ii) if the class of the class argument is the same as the class of the
  superclass argument or
\item (iii) if the classes one of the arguments is standard-class and the class
  of the other is funcallable-standard-class.
\end{itemize}

In all other cases, this method returns false.

This method can be overridden.
\end{defun}

\textbf{Notes:}

Defining a method on \cdf{validate-superclass} requires detailed knowledge of of the
internal protocol followed by each of the two class metaobject classes. A method
on \cdf{validate-superclass} which returns true for two different class metaobject
classes declares that they are compatible.
\end{defun}

\begin{defun}[Generic Function]
writer-method-class class direct-slot &rest initargs

\textbf{Arguments:}

The \emph{class} argument is a class metaobject.

The \emph{direct-slot} argument is a direct slot definition metaobject.

The \emph{initargs} argument is a list of initialization arguments and values.

\textbf{Values:}

The value returned is a class metaobject.

\textbf{Purpose:}

This generic function is called to determine the class of writer methods created
during class initialization and reinitialization. The result must be a subclass
of \cdf{standard-writer-method}.

The initargs argument must be the same as will be passed to \cdf{make-instance} to
create the reader method. The initargs must include \cd{:slot-definition} with
\emph{slot-definition} as its value.

\textbf{Methods:}

\begin{defun}[Primary Method][Primary Method]
writer-method-class (class standard-class) (direct-slot
  standard-direct-slot-definition) &rest initargs \\
writer-method-class (class funcallable-standard-class) (direct-slot
  standard-direct-slot-definition) &rest initargs

These methods returns the class \cdf{standard-writer-method}. These methods can be
overridden.
\end{defun}
\end{defun}


%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "clm"
%%% End: