diff --git a/annotations/changelog b/annotations/changelog
index 925180d3..b36c2942 100644
--- a/annotations/changelog
+++ b/annotations/changelog
@@ -327,7 +327,7 @@ C++-annotations (9.7.0)
 
   * Rewrote all sections about multi-threading)
 
-  * Rewrote the section about lamba expressions
+  * Rewrote the section about lambda expressions
 
   * Replaced references to `ascii-z string' by `null terminated byte string'
     (NTBS), following the C++11 standard's terminology.
@@ -418,7 +418,7 @@ C++-annotations (9.2.1)
 
   * Removed excessive use of the verb 'will' from the Annotations. 
 
-  * The required operators for each of the standard interators (input,
+  * The required operators for each of the standard iterators (input,
     output, forward, bidirectional, random_access) are now explicitly
     mentioned in the paragraphs covering them.
 
diff --git a/annotations/yo/advancedtemplates/implementing.yo b/annotations/yo/advancedtemplates/implementing.yo
index c7e78e39..1db9f5fc 100644
--- a/annotations/yo/advancedtemplates/implementing.yo
+++ b/annotations/yo/advancedtemplates/implementing.yo
@@ -53,7 +53,7 @@ tt(rhs). Its in-class implementation is
         )
 
     To retrieve the resulting tt(IntVect) a conversion operator is defined. We
-already encountered its implentation (in the previous section). Here is it,
+already encountered its implementation (in the previous section). Here is it,
 as an in-class implemented tt(BinExpr) member:
         verb(
     operator ObjType() const
diff --git a/annotations/yo/advancedtemplates/intro.yo b/annotations/yo/advancedtemplates/intro.yo
index 7d991b04..7f412bb3 100644
--- a/annotations/yo/advancedtemplates/intro.yo
+++ b/annotations/yo/advancedtemplates/intro.yo
@@ -27,7 +27,7 @@ main characteristics of i(template meta programming) are introduced.
 In addition to template type and template non-type parameters there is a third
 kind of template parameter, the
     emi(template template parameter). This kind of template parameter is
-introduced shortly, laying the groundwork for the discusion of em(trait
+introduced shortly, laying the groundwork for the discussion of em(trait
 classes) and em(policy classes).
 
 This chapter ends with the discussion of several additional and interesting
diff --git a/annotations/yo/classes/subtleties.yo b/annotations/yo/classes/subtleties.yo
index 1dc011e4..f4de11c6 100644
--- a/annotations/yo/classes/subtleties.yo
+++ b/annotations/yo/classes/subtleties.yo
@@ -102,7 +102,7 @@ these parentheses for us:
     itemization(
     it() Anonymous objects are great for initializing tt(const) reference
 parameters.
-    it() The same syntaxis, however, can also be used in stand-alone
+    it() The same syntax, however, can also be used in stand-alone
 statements, in which they are interpreted as variable definitions if our
 intention actually was to initialize an anonymous object using an existing
 object.
diff --git a/annotations/yo/classtemplates/cirquemembers.yo b/annotations/yo/classtemplates/cirquemembers.yo
index 3958cf3f..d80dcf05 100644
--- a/annotations/yo/classtemplates/cirquemembers.yo
+++ b/annotations/yo/classtemplates/cirquemembers.yo
@@ -16,7 +16,7 @@ tt(CirQue) declares several constructors and (public) members (their
 definitions are provided as well; all definitions are provided below the class
 interface).
 
-Here are the constructors and the destrctor:
+Here are the constructors and the destructor:
 
     itemization(
     ittq(explicit CirQue(size_t maxSize = 0))(Constructor initializing a
diff --git a/annotations/yo/classtemplates/converting.yo b/annotations/yo/classtemplates/converting.yo
index ab3d924d..f34918a6 100644
--- a/annotations/yo/classtemplates/converting.yo
+++ b/annotations/yo/classtemplates/converting.yo
@@ -176,7 +176,7 @@ multiple levels of inheritance let's summarize the steps that took to
 implement static polymorphism
     itemization(
     it() First, starting at the base class,
-the class tt(Vehicle). tt(Vehicle's) non-redifinable interface is moved
+the class tt(Vehicle). tt(Vehicle's) non-redefinable interface is moved
 to a class tt(VehicleBase), and tt(Vehicle) itself is turned into a statically
 polymorphic base class. In general all members of the original 
 polymorphic base class that do not use or implement virtual members should be
@@ -244,7 +244,7 @@ type. The following tt(main) function displays, respectively, 1000 and 15000:
     Note that this program implements tt(fun) twice, rather than once in the
 case of dynamic polymorphism. The same holds true for the tt(Vehicle) class
 template: two implementations, one for the tt(Car) type, and one for the
-tt(Truck) type. The statically polumorphic program will be slightly faster,
+tt(Truck) type. The statically polymorphic program will be slightly faster,
 though.
 
     (A compilable example using static polymorphism is found in the
diff --git a/annotations/yo/classtemplates/examplestaticpoly.yo b/annotations/yo/classtemplates/examplestaticpoly.yo
index 6e7f694c..55a8c757 100644
--- a/annotations/yo/classtemplates/examplestaticpoly.yo
+++ b/annotations/yo/classtemplates/examplestaticpoly.yo
@@ -160,7 +160,7 @@ statically polymorphic base classes. If the base class defines data members
 and member functions, and if these additional members are used by derived
 class types, then each member has its own instantiation for each derived class
 type. This also results in i(code bloat), albeit of a different kind than
-obeserved with dynamic polymorphism. This kind of code bloat can often be
+observed with dynamic polymorphism. This kind of code bloat can often be
 somewhat reduced by deriving the base class from its own (ordinary,
 non-template) base class, encapsulating all elements of the statically
 polymorphic base class that do not depend on its template type parameters.
diff --git a/annotations/yo/classtemplates/externtemplate.yo b/annotations/yo/classtemplates/externtemplate.yo
index 73517b9c..d9975216 100644
--- a/annotations/yo/classtemplates/externtemplate.yo
+++ b/annotations/yo/classtemplates/externtemplate.yo
@@ -37,7 +37,7 @@ name a few): all are assumed by the compiler to have been instantiated
 elsewhere;
     it() Although the above source file em(compiles), the em(instantiations)
 of the templates must be available before the linker can build the final
-program. To accomplish this one or more sourcefiles may be constructed in
+program. To accomplish this one or more source files may be constructed in
 which all required instantiations are made available.
 
     In a stand-alone program one might postpone defining the required members
diff --git a/annotations/yo/classtemplates/fold.yo b/annotations/yo/classtemplates/fold.yo
index de589e87..8509c6c7 100644
--- a/annotations/yo/classtemplates/fold.yo
+++ b/annotations/yo/classtemplates/fold.yo
@@ -9,7 +9,7 @@ Sometimes the arguments must be combined using binary operators (like tt(arg1
 + arg2 + ...)). In those cases a emi(folding expression) can be used instead
 of combining the arguments using a traditional variadic template.
 
-All binary operators (including the assignment, compount assignment and comma
+All binary operators (including the assignment, compound assignment and comma
 operators) can be used in folding expressions. 
 
     itemization(
diff --git a/annotations/yo/classtemplates/lambda.yo b/annotations/yo/classtemplates/lambda.yo
index 9f84bb39..bc7a056f 100644
--- a/annotations/yo/classtemplates/lambda.yo
+++ b/annotations/yo/classtemplates/lambda.yo
@@ -1,4 +1,4 @@
-em(Generic lambda expressions) hi(lamda: generic) use tt(auto) to define their
+em(Generic lambda expressions) hi(lambda: generic) use tt(auto) to define their
 parameters. When used, an appropriate lambda expression is created by looking
 at the actual types of arguments. Since they are generic, they can be used
 inside one function with different types of arguments. Here is an example
@@ -62,7 +62,7 @@ its values via a lambda function:
 
 In generic lambda expressions the keyword tt(auto) indicates that the compiler
 determines which types to use when the lambda function is instantiated. A
-generic lamda expression therefore em(is) a class template, even though it
+generic lambda expression therefore em(is) a class template, even though it
 doesn't look like one. As an example, the following lambda expression defines
 a generic class template, which can be used as shown:
         verb(
diff --git a/annotations/yo/classtemplates/static.yo b/annotations/yo/classtemplates/static.yo
index f7e738b4..75ca2e56 100644
--- a/annotations/yo/classtemplates/static.yo
+++ b/annotations/yo/classtemplates/static.yo
@@ -35,7 +35,7 @@ looks like this:
     Here tt(s_objectCounter) is an tt(int) and is thus independent of the
 template type parameter tt(Type). Multiple instantiations of
 tt(s_objectCounter) for identical tt(Type)s cause no problem, as the linker
-will remove all but one instantation from the final executable (cf. section
+will remove all but one instantiation from the final executable (cf. section
 ref(TEMPFUNDECL)).
 
     In list-like constructions, where a i(pointer to objects) of the class
diff --git a/annotations/yo/classtemplates/variadicnontype.yo b/annotations/yo/classtemplates/variadicnontype.yo
index 20d12695..d1096291 100644
--- a/annotations/yo/classtemplates/variadicnontype.yo
+++ b/annotations/yo/classtemplates/variadicnontype.yo
@@ -1,4 +1,4 @@
-Variadic templates not necesssarily define template types. Non-types can also
+Variadic templates not necessarily define template types. Non-types can also
 be used with
     hi(variadic non-type parameters)
         variadic templates. The following function template accepts any series
diff --git a/annotations/yo/concrete/codegeneration.yo b/annotations/yo/concrete/codegeneration.yo
index 01b74c98..695be26a 100644
--- a/annotations/yo/concrete/codegeneration.yo
+++ b/annotations/yo/concrete/codegeneration.yo
@@ -1,5 +1,5 @@
 The calculator is built using tt(bisonc++) and tt(flexc++).  Here is the
-implentation of the calculator's tt(main) function:
+implementation of the calculator's tt(main) function:
         verbinclude(-a bisonc++/calculator.cc)
 
 The parser's files tt(parse.cc) and tt(parserbase.h) are generated by the
diff --git a/annotations/yo/concrete/fistreamexample.yo b/annotations/yo/concrete/fistreamexample.yo
index 42854be7..2574ad6a 100644
--- a/annotations/yo/concrete/fistreamexample.yo
+++ b/annotations/yo/concrete/fistreamexample.yo
@@ -22,7 +22,7 @@ tt(field) object, initialized in one of three different ways:
     itemization(
     itt(field()): When tt(setField)'s argument is a tt(field) object
         constructed by its default constructor the next extraction will use
-        the same fieldwidth as the previous extraction.
+        the same field width as the previous extraction.
     itt(field(0)): When this tt(field) object is used as tt(setField)'s
         argument, fixed-sized field extraction stops, and the tt(Fistream)
         acts like any standard tt(istream) object again.
diff --git a/annotations/yo/concrete/iterators.yo b/annotations/yo/concrete/iterators.yo
index 9fe9180e..5ee5a1cb 100644
--- a/annotations/yo/concrete/iterators.yo
+++ b/annotations/yo/concrete/iterators.yo
@@ -1,5 +1,5 @@
 In section ref(RANDOMIT) the construction of iterators and
-reverse iteraters was discussed. In that section the iterator was constructed
+reverse iterators was discussed. In that section the iterator was constructed
 as an inner class in a class derived from a vector of pointers to strings.
 
     An object of this nested iterator class handles the dereferencing of the
diff --git a/annotations/yo/concrete/promotions.yo b/annotations/yo/concrete/promotions.yo
index dee7bec1..da911c2a 100644
--- a/annotations/yo/concrete/promotions.yo
+++ b/annotations/yo/concrete/promotions.yo
@@ -4,7 +4,7 @@ promotions. E.g., a statement like
   result = rhs + 2;
         )
     generates a compilation error as promotions are not recognized by
-the template argument deduction algoritm. Currently, the above statement needs
+the template argument deduction algorithm. Currently, the above statement needs
 to be rewritten to have it accepted by the compiler:
         verb(
   result = rhs + Class{ 2 };
diff --git a/annotations/yo/containers/container.yo b/annotations/yo/containers/container.yo
index ec467170..b8ecf095 100644
--- a/annotations/yo/containers/container.yo
+++ b/annotations/yo/containers/container.yo
@@ -60,7 +60,7 @@ A variant of the tt(pair) is the tt(complex) container, implementing
 operations that are defined on complex numbers.
 
 A tt(tuple) (cf. section ref(TUPLES)) generalizes the tt(pair) container to a
-data structure accomodating any number of different data types.
+data structure accommodating any number of different data types.
 
 All abstract containers described in this chapter as well as the tt(string)
 and stream datatypes (cf. chapters ref(String) and ref(IOStreams)) are part of
diff --git a/annotations/yo/containers/multimap.yo b/annotations/yo/containers/multimap.yo
index 25d076e7..1636662e 100644
--- a/annotations/yo/containers/multimap.yo
+++ b/annotations/yo/containers/multimap.yo
@@ -61,5 +61,5 @@ non-existing keys: they both return the first element having a key that
 exceeds the provided key.
     it() Although the keys are ordered in the tt(multimap), the values for
 equal keys are not ordered: they are retrieved in the order in which they were
-enterd.
+entered.
     )
diff --git a/annotations/yo/friends/friendfun.yo b/annotations/yo/friends/friendfun.yo
index aad2aa06..c4f41d75 100644
--- a/annotations/yo/friends/friendfun.yo
+++ b/annotations/yo/friends/friendfun.yo
@@ -44,7 +44,7 @@ friend.
 hi(friend: function declaration) em(friend declarations) are not em(member)
 functions, and so they are independent of the class's tt(private, protected)
 and tt(public) sections. Friend declaration may be placed anywhere in the
-class interface. Convention dictates that friend declaractions are listed
+class interface. Convention dictates that friend declarations are listed
 directly at the top of the class interface. The class tt(Person), using
 tt(friend) declaration for its extraction and insertion operators starts like
 this:
diff --git a/annotations/yo/functiontemplates/insertion.yo b/annotations/yo/functiontemplates/insertion.yo
index 10911236..bb135b5a 100644
--- a/annotations/yo/functiontemplates/insertion.yo
+++ b/annotations/yo/functiontemplates/insertion.yo
@@ -6,7 +6,7 @@ A conversion operator is guaranteed to be used as an rvalue. This means that
 objects of a class defining a tt(string) conversion operator can be assigned
 to, e.g., tt(string) objects. But when trying to insert objects defining
 tt(string) conversion operators into streams then the compiler complains that
-we're attemping to insert an inappropriate type into an tt(ostream).
+we're attempting to insert an inappropriate type into an tt(ostream).
 
 On the other hand, when this class defines an tt(int) conversion operator
 insertion is performed flawlessly.
diff --git a/annotations/yo/functiontemplates/limits.yo b/annotations/yo/functiontemplates/limits.yo
index 8a48c4c7..ab5d3884 100644
--- a/annotations/yo/functiontemplates/limits.yo
+++ b/annotations/yo/functiontemplates/limits.yo
@@ -100,7 +100,7 @@ can be used as follows:
         `Not-a-Number' value.
     )
     ithtq(infinity)(Type constexpr infinity())(
-        if available for tt(Type): its positive infiniy value.
+        if available for tt(Type): its positive infinity value.
     )
     ithtq(is_bounded)(bool is_bounded)(
         tt(true) if tt(Type) contains a finite set of values.
diff --git a/annotations/yo/functiontemplates/selection.yo b/annotations/yo/functiontemplates/selection.yo
index 7c97f253..968bbf03 100644
--- a/annotations/yo/functiontemplates/selection.yo
+++ b/annotations/yo/functiontemplates/selection.yo
@@ -63,7 +63,7 @@ arguments.
 This implies that at least the number of arguments must match the number of
 parameters of the viable functions. Function 10's first argument is a
 tt(string). As a tt(string) cannot be initialized by an tt(int) value no
-approprate conversion exists and function 10 is removed from the list of
+appropriate conversion exists and function 10 is removed from the list of
 candidate functions.  tt(double) parameters can be retained. Standard
 conversions em(do) exists for tt(int)s to tt(double)s, so all functions having
 ordinary tt(double) parameters can be retained. Therefore, the set of viable
diff --git a/annotations/yo/functiontemplates/specialization.yo b/annotations/yo/functiontemplates/specialization.yo
index ebe514ef..a140b37c 100644
--- a/annotations/yo/functiontemplates/specialization.yo
+++ b/annotations/yo/functiontemplates/specialization.yo
@@ -17,7 +17,7 @@ a more specialized function over a less specialized one. So the template
 explicit specialization is selected whenever possible.
 
 A template explicit specialization offers a specialization for its template
-type parameter(s). The special type is consistently subsituted for
+type parameter(s). The special type is consistently substituted for
 the template type parameter in the function template's code. For
 example if the explicitly specialized type is tt(char const *) then in the
 template definition
@@ -86,7 +86,7 @@ case only a tt(Type const *), allowing tt(char const *)'s to be passed as
 arguments. There's no opportunity for a qualification transformation here.
 The qualification transformation allows the compiler to add a tt(const) to a
 non-const argument if the parameter itself (and em(not)  tt(Type)) is
-specified in terms of a tt(const) or tt(const &). Loooking at, e.g., tt(t1) we
+specified in terms of a tt(const) or tt(const &). Looking at, e.g., tt(t1) we
 see that it's defined as a tt(Type const *). There's nothing tt(const) here
 that's referring to the parameter (in which case it would have been tt(Type
 const *const t1) or tt(Type const *const &t1)). Consequently a qualification
diff --git a/annotations/yo/generic/foreach.yo b/annotations/yo/generic/foreach.yo
index 0bb88509..43db8ca1 100644
--- a/annotations/yo/generic/foreach.yo
+++ b/annotations/yo/generic/foreach.yo
@@ -19,7 +19,7 @@ the tt(for_each) call, which argument is eventually also passed to the
 function given to tt(for_each). Within tt(for_each) the return value of the
 function that is passed to it is ignored. The tt(for_each) generic algorithm
 looks a lot like the range-based for loop, but different from the range-based
-for-loop the tt(for_each) algoritm can also be used with sub-ranges and with
+for-loop the tt(for_each) algorithm can also be used with sub-ranges and with
 reverse-iterators.
         )
         it() Example:
diff --git a/annotations/yo/generic/intro.yo b/annotations/yo/generic/intro.yo
index addf460f..bf890ccd 100644
--- a/annotations/yo/generic/intro.yo
+++ b/annotations/yo/generic/intro.yo
@@ -23,7 +23,7 @@ something akin to
     sort(first-element, last-element)
         )
 
-Generic algoritms should be used wherever possible. Avoid the urge to design
+Generic algorithms should be used wherever possible. Avoid the urge to design
 your own code for commonly encountered algorithms. Make it a habit to
 em(first) thoroughly search the generic algorithms for an available
 candidate. The generic algorithms should become your em(weapon of choice) when
@@ -43,7 +43,7 @@ i(generic data type). Furthermore, the particular type of iterator (see
 section ref(ITERATORS)) that is required is mentioned as well as other generic
 types that might be required (e.g., performing tt(BinaryOperations), like
 tt(plus<Type>)). Although iterators are commonly provided by abstract
-containers and comparable pre-defined data structrues, at some point you may
+containers and comparable pre-defined data structures, at some point you may
 want to design your own iterators. Section ref(ITERATORCONS) offers guidelines
 for constructing your own iterator classes and provides an overview of of
 operators that must be implemented for the various types of iterators.
diff --git a/annotations/yo/generic/transform.yo b/annotations/yo/generic/transform.yo
index c6cdeccf..8c6a76a0 100644
--- a/annotations/yo/generic/transform.yo
+++ b/annotations/yo/generic/transform.yo
@@ -36,7 +36,7 @@ function object's tt(operator()).
     )
     Also note that the range-based for loop can often be used instead of the
 tt(transform) generic algorithm. However, but different from the
-range-based for-loop the tt(transform) algoritm can also be used width
+range-based for-loop the tt(transform) algorithm can also be used width
 sub-ranges and with reverse-iterators.
 
 
diff --git a/annotations/yo/inheritance/move.yo b/annotations/yo/inheritance/move.yo
index 871ae762..326d4fc0 100644
--- a/annotations/yo/inheritance/move.yo
+++ b/annotations/yo/inheritance/move.yo
@@ -8,7 +8,7 @@ A derived class may offer a move constructor for two reasons:
 
     The design of move constructors moving data members was covered in section
 ref(MOVE). A move constructor for a derived class whose base class is
-move-aware must em(anonimize) the rvalue reference before passing it to the
+move-aware must em(anonymize) the rvalue reference before passing it to the
 base class move constructor. The tt(std::move) function should be used when
 implementing the move constructor to move the information in base classes or
 composed objects to their new destination object.
@@ -21,7 +21,7 @@ movable data members, but that its tt(Vehicle) base class is move-aware:
         verb(
     Car::Car(Car &&tmp)
     :
-        Land(std::move(tmp)),           // anonimize `tmp'
+        Land(std::move(tmp)),           // anonymize `tmp'
         d_brandName(tmp.d_brandName)    // move the char *'s value
     {
         tmp.d_brandName = 0;
diff --git a/annotations/yo/inheritance/related.yo b/annotations/yo/inheritance/related.yo
index 9f64b6fc..08710882 100644
--- a/annotations/yo/inheritance/related.yo
+++ b/annotations/yo/inheritance/related.yo
@@ -23,7 +23,7 @@ store and retrieve a vehicle's mass:
 corresponding object has been created. At a later stage the mass can be
 changed or retrieved.
 
-To represent vehicles travelling over land, a new class tt(Land) can be
+To represent vehicles traveling over land, a new class tt(Land) can be
 defined offering tt(Vehicle)'s functionality and adding its own specific
 functionality. Assume we are interested in the speed of land vehicles em(and)
 in their mass. The relationship between tt(Vehicle)s and tt(Land)s could of
diff --git a/annotations/yo/iostreams/iosbase.yo b/annotations/yo/iostreams/iosbase.yo
index 6423f8fa..81a89d9d 100644
--- a/annotations/yo/iostreams/iosbase.yo
+++ b/annotations/yo/iostreams/iosbase.yo
@@ -17,7 +17,7 @@ class: the class ti(streambuf) or its derivatives.
 It is neither possible nor required to construct an tt(ios_base) object
 directly. Its construction is always a side-effect of constructing an object
 further down the class hierarchy, like tt(std::ios). tt(Ios) is the next
-class down the iostream hierarchy (see figure ref(IOCLASSESFIG)). Since all
+class down the iostream hierarchy (see Figure ref(IOCLASSESFIG)). Since all
 stream classes in turn inherit from tt(ios), and thus also from tt(ios_base),
 the distinction between tt(ios_base) and ti(ios) is in practice not
 important. Therefore, facilities actually provided by tt(ios_base) will be
diff --git a/annotations/yo/nested/nestedfriends.yo b/annotations/yo/nested/nestedfriends.yo
index 7a00bb93..97016346 100644
--- a/annotations/yo/nested/nestedfriends.yo
+++ b/annotations/yo/nested/nestedfriends.yo
@@ -9,7 +9,7 @@ are members of the outer class and thus can access all the outer class's
 members. Here is an example showing this principle. The example won't compile
 as members of the class tt(Extern) are denied access to tt(Outer)'s private
 members, but tt(Outer::Inner)'s members em(can) access tt(Outer)'s private
-memebrs:
+members:
         verb(
     class Outer
     {
diff --git a/annotations/yo/overloading/lambda.yo b/annotations/yo/overloading/lambda.yo
index 68a57802..e6caaf81 100644
--- a/annotations/yo/overloading/lambda.yo
+++ b/annotations/yo/overloading/lambda.yo
@@ -20,7 +20,7 @@ that is irrelevant at the current level of specification. Nested classes don't
 solve these problems either. Moreover, nested classes can't be used in
 templates.
 
-Lamba expressions solve these problems.  A i(lambda expression) defines an
+lambda expressions solve these problems.  A i(lambda expression) defines an
     i(anonymous function object) which may immediately be passed to functions
 expecting function object arguments, as explained in the next few sections.
 
diff --git a/annotations/yo/overloading/lambdasyntax.yo b/annotations/yo/overloading/lambdasyntax.yo
index f83ede9c..0b36a2ef 100644
--- a/annotations/yo/overloading/lambdasyntax.yo
+++ b/annotations/yo/overloading/lambdasyntax.yo
@@ -6,7 +6,7 @@ its emi(closure type).
 
 Lambda expressions are used inside blocks, classes or namespaces (i.e.,
 pretty much anywhere you like). Their implied closure type is defined in the
-smallest block, class or namespace scope containing the lamba
+smallest block, class or namespace scope containing the lambda
 expression. The closure object's visibility starts at its point of definition
 and ends where its closure type ends.
 
@@ -24,7 +24,7 @@ operator. Here is an example of a lambda expression:
     The function call operator of the closure object created by this lambda
 expression expects two tt(int) arguments and returns their product. It is an
 inline tt(const) member of the closure type. To drop the tt(const) attribute,
-the lamba expression should specify hi(lambda: mutable) tt(mutable), as
+the lambda expression should specify hi(lambda: mutable) tt(mutable), as
 follows:
         verb(
     [](int x, int y) mutable
@@ -32,8 +32,8 @@ follows:
         )
     The lambda-declarator may be omitted, if no parameters are defined, but
 when specifying tt(mutable) (or tt(constexpr), see below) the
-lambda-declarator must at least start with an empty set of parenthese. The
-parameters in a lamba declarator cannot be given default arguments. 
+lambda-declarator must at least start with an empty set of parentheses. The
+parameters in a lambda declarator cannot be given default arguments.
 
 Declarator specifiers can be tt(mutable), tt(constexpr), or both. A
 tt(constexpr) lambda-expression is itself a tt(constexpr), which may be
@@ -62,7 +62,7 @@ identical:
         )
 
 
-A closure object as defined by the previous lamda expression could be used e.g.,
+A closure object as defined by the previous lambda expression could be used e.g.,
 in combination with the tt(accumulate) (cf. section ref(ACCU)) generic
 algorithm to compute the product of a series of tt(int) values stored in a
 vector:
diff --git a/annotations/yo/overloading/lambdause.yo b/annotations/yo/overloading/lambdause.yo
index d1bfa3f9..c1e9f39b 100644
--- a/annotations/yo/overloading/lambdause.yo
+++ b/annotations/yo/overloading/lambdause.yo
@@ -93,14 +93,14 @@ reports 0. What's happening here?
     When a generic algorithm is given a lambda function, its implementation
 instantiates a reference to a function. The referenced function is thereupon
 called from within the generic algorithm. But, in the above example the
-range-based for-loop's nested statement merely represents the em(defintion)
-of a lamba function. Nothing is actually called, and hence tt(total) remains
+range-based for-loop's nested statement merely represents the em(definition)
+of a lambda function. Nothing is actually called, and hence tt(total) remains
 equal to 0. 
 
     Thus, to make the above example work we not only must em(define) the
 lambda expression, but we must also em(call) the lambda function. We can do
 this by  giving the lambda function a em(name), and then call the
-lamba function by its given name:
+lambda function by its given name:
         verb(
     void showSum(vector<int> const &vi)
     {
@@ -122,7 +122,7 @@ In fact, there is no need to give the lambda function a name: the tt(auto
 lambda) definition represents the lambda function, which could also
 directly be called. The syntax for doing this may look a
 bit weird, but there's nothing wrong with it, and it allows us to drop the
-compound statment, required in the last example, completely. Here goes:
+compound statement, required in the last example, completely. Here goes:
         verb(
     void showSum(vector<int> const &vi)
     {
diff --git a/annotations/yo/pointermembers/sizes.yo b/annotations/yo/pointermembers/sizes.yo
index ea2c0b80..005be704 100644
--- a/annotations/yo/pointermembers/sizes.yo
+++ b/annotations/yo/pointermembers/sizes.yo
@@ -43,7 +43,7 @@ But the problem here is that tt(&fstr) does not represent the correct object
 address: tt(seekp) operates on an tt(ofstream), and that object does not start
 at tt(&fstr), so (in tt(fstream (a))), at tt(&(fstr + sizeof(ifstream))).
 
-So, the compiler, when calling a memberfunction of a class using inheritance,
+So, the compiler, when calling a member function of a class using inheritance,
 must make a correction for the relative location of an object whose members we
 are calling.
 
@@ -116,7 +116,7 @@ used to display the contents of the ptr fields (see below):
     (your address values (the first ones on the two lines) may differ). Note
 that the functions' addresses are the same, but since in the C world the B
 object lives beyond the A object, and the A object is 4 bytes large, we must
-add 4 to the value of the `tt(this)' pointer when calling the fnction from a C
+add 4 to the value of the `tt(this)' pointer when calling the function from a C
 object. That's exactly what the shift value in the pointer's second field is
 telling the compiler.
 
diff --git a/annotations/yo/polymorphism/implementation.yo b/annotations/yo/polymorphism/implementation.yo
index 090f8340..e66ec1c0 100644
--- a/annotations/yo/polymorphism/implementation.yo
+++ b/annotations/yo/polymorphism/implementation.yo
@@ -35,7 +35,7 @@ should) a virtual destructor). The actually called function is determined from
 this table.
 
 The internal organization of the objects having virtual functions is
-illustrated in figures fig(ImplementationFigure) and fig(CaumonFigure)
+illustrated in fig(ImplementationFigure) and fig(CaumonFigure)
 (originals provided by url(Guillaume Caumon)
     (mailto:Guillaume.Caumon@ensg.inpl-nancy.fr)).
 
@@ -47,7 +47,7 @@ illustrated in figures fig(ImplementationFigure) and fig(CaumonFigure)
         (Complementary figure, provided by Guillaume Caumon)
         (CaumonFigure)
 
-    As shown by figures fig(ImplementationFigure) and fig(CaumonFigure),
+    As shown by fig(ImplementationFigure) and fig(CaumonFigure),
 objects potentially using virtual member functions must have one (hidden) data
 member to address a table of function pointers. The objects of the classes
 tt(Vehicle) and tt(Car) both address the same table. The class tt(Truck),
diff --git a/annotations/yo/polymorphism/notvirtual.yo b/annotations/yo/polymorphism/notvirtual.yo
index eccfc41a..fc096407 100644
--- a/annotations/yo/polymorphism/notvirtual.yo
+++ b/annotations/yo/polymorphism/notvirtual.yo
@@ -40,7 +40,7 @@ mass of the trailer. A slight complication is that a class organization like
     class Truck: public Car, public Vehicle
         )
     is not accepted by the bf(C++) compiler. As a tt(Vehicle) is already part
-of a tt(Car), it is therefore not needed once again. This organzation may,
+of a tt(Car), it is therefore not needed once again. This organization may,
 however be forced using a small trick. By creating an additional class
 inheriting from tt(Vehicle) and deriving tt(Truck) from that additional class
 rather than directly from tt(Vehicle) the problem is solved. Simply derive a
diff --git a/annotations/yo/polymorphism/pure.yo b/annotations/yo/polymorphism/pure.yo
index ca96867f..fa21bbf7 100644
--- a/annotations/yo/polymorphism/pure.yo
+++ b/annotations/yo/polymorphism/pure.yo
@@ -16,7 +16,7 @@ Such incompletely defined classes are always base classes. They enforce a
 protocol by merely declaring names, return values and arguments of some of
 their members. These classes are call hi(class: abstract)
  emi(abstract classes) or em(abstract base classes).  Derived classes become
-non-abtract classes by implementing the as yet not implemented members.
+non-abstract classes by implementing the as yet not implemented members.
 
 Abstract base classes are the foundation of many em(design patterns)
  hi(design pattern) (cf. em(Gamma et al.) (1995))
diff --git a/annotations/yo/stl/arithmetic.yo b/annotations/yo/stl/arithmetic.yo
index 69c57834..4df30741 100644
--- a/annotations/yo/stl/arithmetic.yo
+++ b/annotations/yo/stl/arithmetic.yo
@@ -51,7 +51,7 @@ tt(cout).
 
     While this section's first example illustrated using a em(named) function
 object, the last two examples illustrate how emi(anonymous) objects can be
-passed to the (tt(accumulate)) function .
+passed to the (tt(accumulate)) function.
 
     The STL supports the following set of arithmetic function objects.  The
 function call operator (tt(operator())) of these function objects calls the
diff --git a/annotations/yo/stl/exponential.yo b/annotations/yo/stl/exponential.yo
index cd27a9ef..0279a909 100644
--- a/annotations/yo/stl/exponential.yo
+++ b/annotations/yo/stl/exponential.yo
@@ -1,5 +1,5 @@
 The ti(exponential_distribution<RealType = double>) is used to describe the
-lengths between events that can be modelled with a homogeneous Poisson
+lengths between events that can be modeled with a homogeneous Poisson
 process. It can be interpreted as the continuous form of the
 geometric distribution.
 
diff --git a/annotations/yo/stl/filesystem/path.yo b/annotations/yo/stl/filesystem/path.yo
index 89305b5a..5eb90618 100644
--- a/annotations/yo/stl/filesystem/path.yo
+++ b/annotations/yo/stl/filesystem/path.yo
@@ -110,7 +110,7 @@ the component is present. Also available: tt(is_absolute, is_relative)
 
 In addition to the member functions various free operators are available:
 tt(==, !=, <, <=, >,) and tt(>=) comparing two tt(path) objects; tt(/)
-returning the contatenated tt(lhs) and tt(rhs). Comparisons use
+returning the concatenated tt(lhs) and tt(rhs). Comparisons use
 lexicographical comparisons (as if by comparing the return values of their
 tt(string) members).
 
diff --git a/annotations/yo/stl/istreamiterators.yo b/annotations/yo/stl/istreamiterators.yo
index fd376ae0..34520fb0 100644
--- a/annotations/yo/stl/istreamiterators.yo
+++ b/annotations/yo/stl/istreamiterators.yo
@@ -6,7 +6,7 @@ tt(istream_iterator) iterator is:
     istream_iterator<Type> identifier(istream &in)
         )
     Here, tt(Type) is the type of the data elements read from the tt(istream)
-stream. It is used as the `begin' iterator in an interator range. tt(Type) may
+stream. It is used as the `begin' iterator in an iterator range. tt(Type) may
 be any type for which oprshift() is defined in combination with tt(istream)
 objects.
 
diff --git a/annotations/yo/stl/logical.yo b/annotations/yo/stl/logical.yo
index cf0068a7..bafbae21 100644
--- a/annotations/yo/stl/logical.yo
+++ b/annotations/yo/stl/logical.yo
@@ -15,5 +15,5 @@ logical operator that is actually called is mentioned below:
     )
     An example using tt(operator!) is provided in the following trivial
 program, using ti(transform)  to transform
-the logicalvalues stored in an array:
+the logical values stored in an array:
         verbinclude(-a examples/not.cc)
diff --git a/annotations/yo/threading/atomic.yo b/annotations/yo/threading/atomic.yo
index 1d265ac5..4cc092ac 100644
--- a/annotations/yo/threading/atomic.yo
+++ b/annotations/yo/threading/atomic.yo
@@ -132,17 +132,17 @@ the following member functions:
 
     ithtq(fetch_and)(Integral fetch_and(Integral mask) noexcept)
        (The tt(bit-and) operator is applied to the object's value and
-        tt(mask), assigning the resulting value to the currrent object. The
+        tt(mask), assigning the resulting value to the current object. The
         object's value at the time of the call is returned;)
 
     ithtq(fetch_|=)(Integral fetch_|=(Integral mask) noexcept)
        (The tt(bit-or) operator is applied to the object's value and tt(mask),
-        assigning the resulting value to the currrent object. The object's
+        assigning the resulting value to the current object. The object's
         value at the time of the call is returned;)
 
     ithtq(fetch_^=)(Integral fetch_^=(Integral mask) noexcept)
        (The tt(bit-xor) operator is applied to the object's value and
-        tt(mask), assigning the resulting value to the currrent object. The
+        tt(mask), assigning the resulting value to the current object. The
         object's value at the time of the call is returned;)
 
     ithtq(operator++)(Integral operator++() noexcept)
@@ -169,17 +169,17 @@ the following member functions:
 
     ithtq(operator&=)(Integral operator&=(Integral mask) noexcept)
        (The tt(bit-and) operator is applied to the object's current value and
-        tt(mask), assigning the resulting value to the currrent object. The
+        tt(mask), assigning the resulting value to the current object. The
         object's new value is returned;)
 
     ithtq(operator|=)(Integral operator|=(Integral mask) noexcept)
        (The tt(bit-or) operator is applied to the object's current value and
-        tt(mask), assigning the resulting value to the currrent object. The
+        tt(mask), assigning the resulting value to the current object. The
         object's new value is returned;)
 
     ithtq(operator^=)(Integral operator^=(Integral mask) noexcept)
        (The tt(bit-xor) operator is applied to the object's current value and
-        tt(mask), assigning the resulting value to the currrent object. The
+        tt(mask), assigning the resulting value to the current object. The
         object's new value is returned;)
     )
     
diff --git a/annotations/yo/threading/compilations.yo b/annotations/yo/threading/compilations.yo
index 1a65dd8e..426d166e 100644
--- a/annotations/yo/threading/compilations.yo
+++ b/annotations/yo/threading/compilations.yo
@@ -30,7 +30,7 @@ description.
 
 Next the dispatcher. It ignores empty lines. Also, if a compilation has
 failed by the time the dispatcher is called, processing stops (lines
-6-7). Otherwise, the dispacher waits for an available worker, prepares a new
+6-7). Otherwise, the dispatcher waits for an available worker, prepares a new
 task, and notifies a worker to handle it:
         verbinclude(-ns4 //code examples/multicompile/dispatch.cc)
 
diff --git a/annotations/yo/threading/future.yo b/annotations/yo/threading/future.yo
index db42da8d..9e47abbc 100644
--- a/annotations/yo/threading/future.yo
+++ b/annotations/yo/threading/future.yo
@@ -77,7 +77,7 @@ Here are the members of the class tt(std::future):
 
     ittq(ResultType get())
        (First tt(wait) (see below) is called. Once tt(wait) has returned the
-        results produced by the associated asynchronoust task
+        results produced by the associated asynchronous task
         are returned. With tt(future<Type>) specifications the returned value
         is the moved shared value if tt(Type) supports move assignment,
         otherwise a copy is returned.  With tt(future<Type &>) specifications
diff --git a/annotations/yo/threading/packagedtask.yo b/annotations/yo/threading/packagedtask.yo
index b31cfe20..f4116229 100644
--- a/annotations/yo/threading/packagedtask.yo
+++ b/annotations/yo/threading/packagedtask.yo
@@ -66,7 +66,7 @@ specified):
         it() The main thread reads commands from the standard input until an
             empty or no line is received (lines 38-40).
         it() By convention the line's first letter starts the car's brand
-            (volkswagen or peugeot), and the tt(packaged_task), provided with
+            (tt(volkswagen) or tt(peugeot)), and the tt(packaged_task), provided with
             the right servicing function, is constructed
             next (line 45).
         it() Then, at line 48 the results, stored in a tt(future), are
diff --git a/annotations/yo/threading/sharedfuture.yo b/annotations/yo/threading/sharedfuture.yo
index 7ce3140b..cfdb8dde 100644
--- a/annotations/yo/threading/sharedfuture.yo
+++ b/annotations/yo/threading/sharedfuture.yo
@@ -70,7 +70,7 @@ with the current object, then the results are also destroyed.
 Here are the members of the class tt(std::shared_future):
     itemization(
     ittq(shared_future& operator=(shared_future &&tmp))
-       (The move assignment operator releases the current opject's shared
+       (The move assignment operator releases the current object's shared
         results, and move assigns tt(tmp's) results to the current
         object. After calling the move assignment operator the current
         object's tt(valid) member returns the same value as tt(tmp.valid())
@@ -78,7 +78,7 @@ Here are the members of the class tt(std::shared_future):
         tt(tmp.valid()) returns tt(false);)
 
     ittq(shared_future& operator=(shared_future const &rhs))
-       (The assignment operator releases the current opject's shared results,
+       (The assignment operator releases the current object's shared results,
         and tt(rhs)'s results are shared with the current object. After
         calling the assignment operator the current object's tt(valid) member
         returns the same value as tt(tmp.valid());)
diff --git a/annotations/yo/threading/sharedmutex.yo b/annotations/yo/threading/sharedmutex.yo
index 8050ad98..ea042ba5 100644
--- a/annotations/yo/threading/sharedmutex.yo
+++ b/annotations/yo/threading/sharedmutex.yo
@@ -51,7 +51,7 @@ the relative time period specified by tt(rel_time). If the time specified by
 tt(rel_time) is less than or equal to tt(rel_time.zero()), the member attempts
 to obtain ownership without blocking (as if by calling
 tt(try_lock_shared())). The member shall return within the time interval
-specified by rel_time only if it has obtained shared ownership of the mutex
+specified by tt(rel_time) only if it has obtained shared ownership of the mutex
 object.  Returns tt(true) if the shared ownership lock was acquired, tt(false)
 otherwise. Initially the calling thread may not yet own the mutex;)
 
diff --git a/annotations/yo/threading/timepoint.yo b/annotations/yo/threading/timepoint.yo
index 22dd3433..381587cb 100644
--- a/annotations/yo/threading/timepoint.yo
+++ b/annotations/yo/threading/timepoint.yo
@@ -26,7 +26,7 @@ The class tt(std::chrono::time_point) features three constructors:
 
     ittq(time_point(time_point<Clock, Duration> const &timeStep))
        (initializes a tt(time_point) object to represent a point in time
-tt(timeStep Duration) units byond the clock's epoch;)
+tt(timeStep Duration) units beyond the clock's epoch;)
 
     ittq(time_point(time_point<Clock, Duration2> const &timeStep))
        (this constructor is defined as a member template, using the template
@@ -34,7 +34,7 @@ header tt(template <typename Duration2>). The type tt(Duration2) is a
 tt(std::chrono::duration) (or comparable) type, using a possibly larger period
 for its unit than tt(time_point's Duration) type. It initializes a
 tt(time_point) object to represent a point in time tt(timeStep Duration2)
-units byond the clock's epoch.)
+units beyond the clock's epoch.)
     )
 
 The class tt(std::chrono::time_point) has these operators and members: