X-Git-Url: https://git.distorted.org.uk/~mdw/sod/blobdiff_plain/b05636518b4e46caf9e6a689f11742c6a7a24c6b..756e9293611d2b1dc34fba6cca89fd70098f5546:/doc/concepts.tex

diff --git a/doc/concepts.tex b/doc/concepts.tex
index 406c002..e301ae7 100644
--- 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
-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
@@ -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,
-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
@@ -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
-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>.
@@ -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
-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|