doc/concepts.tex: Emphasize a defining occurrence of `methods'.

[sod] / doc / concepts.tex

diff --git a/doc/concepts.tex b/doc/concepts.tex
index b8dcacf..fc83714 100644 (file)
--- a/doc/concepts.tex
+++ b/doc/concepts.tex
@@ -78,11 +78,11 @@ and a C value being returned to the sender.
 
 Every object is a \emph{direct instance} of exactly one \emph{class}.  The
 class determines which slots its instances have, which messages its instances
 
 Every object is a \emph{direct instance} of exactly one \emph{class}.  The
 class determines which slots its instances have, which messages its instances

-can be sent, and which methods are invoked when those messages are received.
-The Sod translator's main job is to read class definitions and convert them
-into appropriate C declarations, tables, and functions.  An object cannot
-(usually) change its direct class, and the direct class of an object is not
-affected by, for example, the static type of a pointer to it.
+can be sent, and which \emph{methods} are invoked when those messages are
+received.  The Sod translator's main job is to read class definitions and
+convert them into appropriate C declarations, tables, and functions.  An
+object cannot (usually) change its direct class, and the direct class of an
+object is not affected by, for example, the static type of a pointer to it.

 
 If an object~$x$ is a direct instance of some class~$C$, then we say that $C$
 is \emph{the class of}~$x$.  Note that the class of an object is a property
 
 If an object~$x$ is a direct instance of some class~$C$, then we say that $C$
 is \emph{the class of}~$x$.  Note that the class of an object is a property


@@ -144,9 +144,9 @@ This partial order is not quite sufficient for our purposes.  For each class
 $C$, we shall need to extend it into a total order on $C$'s superclasses.
 This calculation is called \emph{superclass linearization}, and the result is
 a \emph{class precedence list}, which lists each of $C$'s superclasses
 $C$, we shall need to extend it into a total order on $C$'s superclasses.
 This calculation is called \emph{superclass linearization}, and the result is
 a \emph{class precedence list}, which lists each of $C$'s superclasses

-exactly once.  If a superclass $B$ precedes (resp.\ follows) some other
-superclass $A$ in $C$'s class precedence list, then we say that $B$ is a more
-(resp.\ less) \emph{specific} superclass of $C$ than $A$ is.
+exactly once.  If a superclass $B$ precedes or follows some other superclass
+$A$ in $C$'s class precedence list, then we say that $B$ is respectively a
+more or less \emph{specific} superclass of $C$ than $A$.

 
 The superclass linearization algorithm isn't fixed, and extensions to the
 translator can introduce new linearizations for special effects, but the
 
 The superclass linearization algorithm isn't fixed, and extensions to the
 translator can introduce new linearizations for special effects, but the


@@ -159,8 +159,8 @@ following properties are expected to hold.
   list, i.e., $B$ is a more specific superclass of $C$ than $A$ is.
 \end{itemize}
 The default linearization algorithm used in Sod is the \emph{C3} algorithm,
   list, i.e., $B$ is a more specific superclass of $C$ than $A$ is.
 \end{itemize}
 The default linearization algorithm used in Sod is the \emph{C3} algorithm,

-which has a number of good properties described in~\cite{Barrett:1996:MSL}.
-It works as follows.
+which has a number of good properties described
+in~\cite{barrett-1996:monot-super-linear-dylan}.  It works as follows.

 \begin{itemize}
 \item A \emph{merge} of some number of input lists is a single list
   containing each item that is in any of the input lists exactly once, and no
 \begin{itemize}
 \item A \emph{merge} of some number of input lists is a single list
   containing each item that is in any of the input lists exactly once, and no


@@ -263,8 +263,9 @@ It works as follows.
 
   \end{itemize}
 
 
   \end{itemize}
 

-  (This example combines elements from \cite{Barrett:1996:MSL} and
-  \cite{Ducournau:1994:PMM}.)
+  (This example combines elements from
+  \cite{barrett-1996:monot-super-linear-dylan} and
+  \cite{ducournau-1994:monot-multip-inher-linear}.)

 \end{example}
 
 \subsubsection{Class links and chains}
 \end{example}
 
 \subsubsection{Class links and chains}


@@ -536,7 +537,7 @@ Keyword arguments can be provided in three ways.
 \end{enumerate}
 
 Perhaps surprisingly, keyword arguments have a relatively small performance
 \end{enumerate}
 
 Perhaps surprisingly, keyword arguments have a relatively small performance

-impact.  On the author's aging laptop, a call to a simple function, passing
+impact.  On the author's ageing laptop, a call to a simple function, passing

 two out of three keyword arguments, takes about 30 cycles longer than calling
 a standard function which just takes integer arguments.  On the other hand,
 quite a lot of code is involved in decoding keyword arguments, so code size
 two out of three keyword arguments, takes about 30 cycles longer than calling
 a standard function which just takes integer arguments.  On the other hand,
 quite a lot of code is involved in decoding keyword arguments, so code size


@@ -607,9 +608,9 @@ message.  The method combination determines which direct method rôles are
 acceptable, and, for each rôle, the appropriate argument lists and return
 types.
 
 acceptable, and, for each rôle, the appropriate argument lists and return
 types.
 

-One direct method, $M$, is said to be more (resp.\ less) \emph{specific} than
+One direct method, $M$, is said to be more or less \emph{specific} than

 another, $N$, with respect to a receiving class~$C$, if the class defining
 another, $N$, with respect to a receiving class~$C$, if the class defining

-$M$ is a more (resp.\ less) specific superclass of~$C$ than the class
+$M$ is respectively a more or less specific superclass of~$C$ than the class

 defining $N$.
 
 \subsubsection{The standard method combination}
 defining $N$.
 
 \subsubsection{The standard method combination}


@@ -1071,7 +1072,10 @@ follows.
   initializers, \emph{and} the sender supplied a value for one or more of the
   corresponding effective initargs, then the value of the most specific such
   initarg is stored in the slot.  (For this purpose, initargs defined earlier
   initializers, \emph{and} the sender supplied a value for one or more of the
   corresponding effective initargs, then the value of the most specific such
   initarg is stored in the slot.  (For this purpose, initargs defined earlier

-  in a class definition are more specific than initargs defined later.)
+  in a class definition are more specific than initargs defined
+  later.)\footnote{%
+    This is very different from the CLOS behaviour, in which a slot is
+    initialized from the first applicable initarg in the argument list.}

 
 \item Otherwise, if there are any slot initializers defined which include an
   initializer expression, then the initializer expression from the most
 
 \item Otherwise, if there are any slot initializers defined which include an
   initializer expression, then the initializer expression from the most


@@ -1277,7 +1281,7 @@ functions.
 Metaobject classes are chosen in a fairly standard way.
 \begin{itemize}
 \item All metaobject definitions support a symbol-valued property, usually
 Metaobject classes are chosen in a fairly standard way.
 \begin{itemize}
 \item All metaobject definitions support a symbol-valued property, usually

-  named @|@<thing>_class| (e.g., @|slot_class|, @|method_class|), which sets
+  named @|@<thing>{}_class| (e.g., @|slot_class|, @|method_class|), which sets

   the metaobject class explicitly.  (The class for a class metaobject is
   taken from the @|lisp_class| property, because @|class_class| seems less
   meaningful.)
   the metaobject class explicitly.  (The class for a class metaobject is
   taken from the @|lisp_class| property, because @|class_class| seems less
   meaningful.)