X-Git-Url: https://git.distorted.org.uk/~mdw/sod/blobdiff_plain/8987c73e1fd651a6be4fd3c62c9efff849151c80..c3e28c92f639126436db713381309200eaba3ba2:/doc/concepts.tex

diff --git a/doc/concepts.tex b/doc/concepts.tex
index 68780e2..397920f 100644
--- 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
-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
@@ -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,
-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
@@ -169,8 +169,8 @@ It works as follows.
   have no merge then they are said to be \emph{inconsistent}.
 \item The class precedence list of a class $C$ is a merge of the local
   precedence list of $C$ together with the class precedence lists of each of
-  $C$'s direct superclasses.
-\item If there are no such merges, then the definition of $C$ is invalid.
+  $C$'s direct superclasses.  If these lists are inconsistent, then the
+  definition of $C$ is invalid.
 \item Suppose that there are multiple candidate merges.  Consider the
   earliest position in these candidate merges at which they disagree.  The
   \emph{candidate classes} at this position are the classes appearing at this
@@ -263,8 +263,9 @@ It works as follows.
 
   \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}
@@ -536,7 +537,7 @@ Keyword arguments can be provided in three ways.
 \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
@@ -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
-  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
@@ -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
-  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.)