doc/: Minor cleanups, as a result of a spell-check pass.
[sod] / doc / concepts.tex
index 0533a68..30b3be6 100644 (file)
@@ -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
@@ -169,8 +169,8 @@ in~\cite{barrett-1996:monot-super-linear-dylan}.  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
   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
 \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
@@ -1040,7 +1040,7 @@ initialization fragments.
 
 There are two kinds of initarg definitions.  \emph{User initargs} are defined
 by an explicit @|initarg| item appearing in a class definition: the item
 
 There are two kinds of initarg definitions.  \emph{User initargs} are defined
 by an explicit @|initarg| item appearing in a class definition: the item
-defines a name, type, and (optionally) a default value for the initarg.
+defines a name, type, and (optionally) a default value for the initarg.
 \emph{Slot initargs} are defined by attaching an @|initarg| property to a
 slot or slot initializer item: the property's value determines the initarg's
 name, while the type is taken from the underlying slot type; slot initargs do
 \emph{Slot initargs} are defined by attaching an @|initarg| property to a
 slot or slot initializer item: the property's value determines the initarg's
 name, while the type is taken from the underlying slot type; slot initargs do
@@ -1072,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