doc/: Fix various unfortunate garblings.

diff --git a/doc/concepts.tex b/doc/concepts.tex
index 406c00236ce348e4e6a4150d6cc80c6d67beb2ad..e301ae7813e861506f871b6fe38b4f448e03d9a4 100644 (file)
--- a/doc/concepts.tex
+++ b/doc/concepts.tex
@@ -177,11 +177,12 @@ a link superclass, and the link superclass of a class $C$, if it exists, need
 not be a direct superclass of $C$.
 
 Superclass links must obey the following rule: if $C$ is a class, then there
 not be a direct superclass of $C$.
 
 Superclass links must obey the following rule: if $C$ is a class, then there

-must be no three superclasses $X$, $Y$ and~$Z$ of $C$ such that $Z$ is the
-link superclass of both $X$ and $Y$.  As a consequence of this rule, the
-superclasses of $C$ can be partitioned into linear \emph{chains}, such that
-superclasses $A$ and $B$ are in the same chain if and only if one can trace a
-path from $A$ to $B$ by following superclass links, or \emph{vice versa}.
+must be no three distinct superclasses $X$, $Y$ and~$Z$ of $C$ such that $Z$
+is the link superclass of both $X$ and $Y$.  As a consequence of this rule,
+the superclasses of $C$ can be partitioned into linear \emph{chains}, such
+that superclasses $A$ and $B$ are in the same chain if and only if one can
+trace a path from $A$ to $B$ by following superclass links, or \emph{vice
+versa}.

 
 Since a class links only to one of its proper superclasses, the classes in a
 chain are naturally ordered from most- to least-specific.  The least specific
 
 Since a class links only to one of its proper superclasses, the classes in a
 chain are naturally ordered from most- to least-specific.  The least specific


@@ -606,7 +607,7 @@ follows (see also~\xref{fig:concepts.methods.stdmeth}).
 
 A typical use for @|around| methods is to allow a base class to set up the
 dynamic environment appropriately for the primary methods of its subclasses,
 
 A typical use for @|around| methods is to allow a base class to set up the
 dynamic environment appropriately for the primary methods of its subclasses,

-e.g., by claiming a lock, and restore it afterwards.
+e.g., by claiming a lock, and releasing it afterwards.

 
 The @|next_method| function provided to methods with the primary and
 @|around| rôles accepts the same arguments, and returns the same type, as the
 
 The @|next_method| function provided to methods with the primary and
 @|around| rôles accepts the same arguments, and returns the same type, as the


@@ -812,8 +813,8 @@ imprint storage for one of that class's instances.
 
 Once an instance's storage has been imprinted, it is technically possible to
 send messages to the instance; however the instance's slots are still
 
 Once an instance's storage has been imprinted, it is technically possible to
 send messages to the instance; however the instance's slots are still

-uninitialized at this point, the applicable methods are unlikely to do much
-of any use unless they've been written specifically for the purpose.
+uninitialized at this point, so the applicable methods are unlikely to do
+much of any use unless they've been written specifically for the purpose.

 
 The following simple function imprints storage at address @<p> as an instance
 of a class, given a pointer to its class object @<cls>.
 
 The following simple function imprints storage at address @<p> as an instance
 of a class, given a pointer to its class object @<cls>.


@@ -875,9 +876,9 @@ 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.
 \emph{Slot initargs} are defined by attaching an @|initarg| property to a
 by an explicit @|initarg| item appearing in a class definition: the item
 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 determines the initarg's name,
-while the type is taken from the underlying slot type; slot initargs do not
-have default values.  Both kinds define a \emph{direct initarg} for the
+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
+not have default values.  Both kinds define a \emph{direct initarg} for the

 containing class.
 
 Initargs are inherited.  The \emph{applicable} direct initargs for an @|init|
 containing class.
 
 Initargs are inherited.  The \emph{applicable} direct initargs for an @|init|

diff --git a/doc/intro.tex b/doc/intro.tex
index f4b3168d1e5f59a01120d8cffe254741a0545c28..f77eed05cb463c3da3b4e1f8e50c02aea13be988 100644 (file)
--- a/doc/intro.tex
+++ b/doc/intro.tex
@@ -88,7 +88,7 @@ are subclasses; \Cplusplus\ has no such root class.
 Both systems provide multiple inheritance, but go about it very differently.
 The most important difference is that \Cplusplus\ provides only \emph{static
   delegation}: if you have a class @|B| which defines some (virtual) member
 Both systems provide multiple inheritance, but go about it very differently.
 The most important difference is that \Cplusplus\ provides only \emph{static
   delegation}: if you have a class @|B| which defines some (virtual) member

-function @|f|, and a derived class of @|D| which wants to \emph{extend} the
+function @|f|, and a derived class @|D| which wants to \emph{extend} the

 behaviour of @|f| on instances of @|D|, then you must explicitly call @|B::f|
 at the appropriate point:
 \begin{prog}
 behaviour of @|f| on instances of @|D|, then you must explicitly call @|B::f|
 at the appropriate point:
 \begin{prog}

diff --git a/doc/structures.tex b/doc/structures.tex
index 2dfe3559a99bd07272c6e8596e43fa489e9fe7a3..b2835fe93afd978e7af7cb3593d18de91fd86828 100644 (file)
--- a/doc/structures.tex
+++ b/doc/structures.tex
@@ -444,7 +444,7 @@ vtable pointer
 In general, the vtables for the different chains will have \emph{different}
 structures.
 
 In general, the vtables for the different chains will have \emph{different}
 structures.
 

-The instance layout split neatly into disjoint chains.  This is necessary
+The instance layout splits neatly into disjoint chains.  This is necessary

 because each @|ichain| must have as a prefix the @|ichain| for each
 superclass in the same chain, and each slot must be stored in exactly one
 place.  The layout of vtables doesn't have this second requirement: it
 because each @|ichain| must have as a prefix the @|ichain| for each
 superclass in the same chain, and each slot must be stored in exactly one
 place.  The layout of vtables doesn't have this second requirement: it

diff --git a/lib/sod-structs.3 b/lib/sod-structs.3
index 672fe596debee5c41230b80733af0e853d0622a1..a515c8e2f70143dbb17d7d72f061a5714bd64de7 100644 (file)
--- a/lib/sod-structs.3
+++ b/lib/sod-structs.3
@@ -692,7 +692,7 @@ will have
 .I different
 structures.
 .PP
 .I different
 structures.
 .PP

-The instance layout split neatly into disjoint chains.
+The instance layout splits neatly into disjoint chains.

 This is necessary because
 each
 .B ichain
 This is necessary because
 each
 .B ichain