Index: actor.qbk
===================================================================
--- actor.qbk	(revision 69506)
+++ actor.qbk	(working copy)
@@ -50,7 +50,7 @@
 
 The actor class accepts the arguments through a set of function call operators
 for 0 to `BOOST_PHOENIX_LIMIT` arities (Don't worry about the details, for now. Note, for example,
-that we skimp over the details regarding `return_type`). The arguments
+that we skimed over the details regarding `return_type`). The arguments
 are then forwarded to the actor's `Expr` for evaluation.
 
 [endsect]
Index: inside.qbk
===================================================================
--- inside.qbk	(revision 69506)
+++ inside.qbk	(working copy)
@@ -11,7 +11,7 @@
 
 This chapter explains in more detail how the library operates. The information
 henceforth should not be necessary to those who are interested in just using the
-library. However, a microscopic view might prove to be beneficial to moderate
+library. However, a microscopic view might prove to be beneficial
 to advanced programmers who wish to extend the library.
 
 [include inside/actor.qbk]
Index: modules/core.qbk
===================================================================
--- modules/core.qbk	(revision 69506)
+++ modules/core.qbk	(working copy)
@@ -67,7 +67,7 @@
 
 In C++, we can pass in a reference to a variable as the first argument in our
 example above. Yet, by default, the library forces arguments passed to partially
-applied functions functions to be immutable values (see [link phoenix.modules.core.values
+applied functions to be immutable values (see [link phoenix.modules.core.values
 Values]). To achieve our intent, we use:
 
     expression::reference<T>::type
@@ -229,7 +229,7 @@
 
     #include <boost/phoenix/core/nothing.hpp>
 
-Finally, the `expression::null<mpl::void_>::type` does nothing; (a "bum", if you will :-).
+Finally, the `expression::null<mpl::void_>::type` does nothing; (a "bum", if you will :-) ).
 There's a sole `expression::null<mpl::void_>::type` instance named "nothing". This actor is
 actually useful in situations where we don't want to do anything. (See
 [link phoenix.modules.statement.for_statement for_ Statement] for example).
Index: inside/custom_terminal.qbk
===================================================================
--- inside/custom_terminal.qbk	(revision 69506)
+++ inside/custom_terminal.qbk	(working copy)
@@ -9,16 +9,16 @@
 
 [section Custom Terminals]
 
-Custom Terminals are used in phoenix to handle special values transparently.
-For example, as phoenix captures everything by value, we needed to use
-`boost::reference_wrapper` to bring in reference semantics into phoenix.
+Custom Terminals are used in Phoenix to handle special values transparently.
+For example, as Phoenix captures everything by value, we needed to use
+`boost::reference_wrapper` to bring reference semantics into Phoenix.
 
 Custom terminals could be any wrapper class:
 
     template <typename T>
     struct is_custom_terminal;
 
-needs to be specialized in order for phoenix to recognize this wrapper type.
+needs to be specialized in order for Phoenix to recognize this wrapper type.
 `default_action` calls `custom_terminal<T>`.
 
 Example:
Index: inside/actor.qbk
===================================================================
--- inside/actor.qbk	(revision 69506)
+++ inside/actor.qbk	(working copy)
@@ -132,7 +132,7 @@
 [heading Actions]
 
 Actions is the part of Phoenix which are responsible for giving the actual expressions
-a specific behaviour. During the traversal of the Phoenix Expression Tree theses actions
+a specific behaviour. During the traversal of the Phoenix Expression Tree these actions
 are called whenever a specified rule in the grammar matches.
 
     struct actions
@@ -142,7 +142,7 @@
     };
 
 The nested `when` template is required to be __proto_primitive_transform__. No
-Worries, you don't have to learn __proto__ just yet! Phoenix provides some wrappers
+worries, you don't have to learn __proto__ just yet! Phoenix provides some wrappers
 to let you define simple actions without the need to dive deep into proto.
 
 Phoenix ships with a predefined `default_actions` class that evaluates the expressions with
@@ -156,7 +156,7 @@
         {};
     };
 
-For more Information on how to use the default_actions class and how to attach custom actions
+For more information on how to use the default_actions class and how to attach custom actions
 to the evaluation process, see [link phoenix.inside.actions more on actions].
 
 [heading Evaluation]
@@ -172,7 +172,7 @@
 The evaluation of a Phoenix expression is started by a call to the function call operator of
 `evaluator`.
 
-The evaluator is called by the `actor` functio operator overloads after the context is built up.
+The evaluator is called by the `actor` function operator overloads after the context is built up.
 For reference, here is a typical `actor::operator()` that accepts two arguments:
 
     template <typename T0, typename T1>
@@ -188,7 +188,7 @@
 
 For reasons of symmetry to the family of `actor::operator()` there is a special
 metafunction usable for actor result type calculation named `result_of::actor`. This
-metafunction allows us to directly to specify the types of the parameters to be
+metafunction allows us to directly specify the types of the parameters to be
 passed to the `actor::operator()` function. Here's a typical `actor_result` that
 accepts two arguments:
 
Index: inside/expression.qbk
===================================================================
--- inside/expression.qbk	(revision 69506)
+++ inside/expression.qbk	(working copy)
@@ -12,11 +12,10 @@
 A Phoenix Expression is a model of the __proto_expr__ Concept. These expressions
 are wrapped inside an [link phoenix.inside.actor Actor] template. The `actor` provides
 the function call operator which evaluates the expressions.
-The `actor` is the domain specific wrapper around phoenix expressions.
+The `actor` is the domain specific wrapper around Phoenix expressions.
 
 By design, Phoenix Expressions do not carry any information on how they will be
-evaluated later on. They are the data structure on which the `Actions` will work
-on.
+evaluated later on. They are the data structure on which the `Actions` will work.
 
 The library provides a convenience template to define expressions:
     
@@ -59,8 +58,8 @@
 
 [heading meta_grammar]
 
-Defining Expressions is only part of the game to make it a valid Phoenix Expression.
-In order to use the expressions in the Phoenix domain, we need to "register" our newly created
+Defining expressions is only part of the game to make it a valid Phoenix Expression.
+In order to use the expressions in the Phoenix domain, we need to "register" them
 to our grammar.
 
 The `meta_grammar` is a struct for exactly that purpose. It is an openly extendable __proto__ Grammar:
@@ -107,7 +106,7 @@
         return expression::plus<Lhs, Rhs>::make(lhs, rhs);
     }
 
-Look of it really works:
+Look if it really works:
 
     plus(6, 5)();
 
@@ -125,11 +124,11 @@
 See [@../../example/define_expression.cpp define_expression.cpp] for the full example.
 
 [note
-	The example shown here only works because `default_actions` know how to handle
+	The example shown here only works because `default_actions` knows how to handle
 	an expression having the `proto::tag::plus` and two children. This is because
 	`default_actions` uses the `proto::_default<meta_grammar>` transform to
     evaluate operators and functions. Learn more about actions
-    [link phoenix.inside.actions here]
+    [link phoenix.inside.actions here].
 ]
 
 [/section Boilerplate Macros]
@@ -138,8 +137,8 @@
 repetetive task. Phoenix provides boilerplate macros that make defining Phoenix
 Expressions as you have seen in the
 [link phoenix.inside.expression previous section] look like a piece of cake.
-]
 
+
 [/
 These expressions generate the following:
 * A tag (in the underlying namespace tag)
Index: inside/actions.qbk
===================================================================
--- inside/actions.qbk	(revision 69506)
+++ inside/actions.qbk	(working copy)
@@ -75,7 +75,7 @@
 [*But there is more:] As Actions /can/ be full fletched __proto_transforms__, you can
 in fact use any proto expression you can imagine as the action. Phoenix predifines a
 set of callables and transform to deal with the Context information passed along and
-of course every phoenix expression can be used as a phoenix grammar or
+of course every Phoenix expression can be used as a Phoenix grammar or
 __proto_pass_through_transform__.
 
 [variablelist
Index: inside/placeholder.qbk
===================================================================
--- inside/placeholder.qbk	(revision 69506)
+++ inside/placeholder.qbk	(working copy)
@@ -19,6 +19,6 @@
     };
 
 To adapt your own placeholder, the nested value needs to be greater than 0
-for your types. This is done with specializing this trait.
+for your types. This is done by specializing this trait.
 
 [endsect]
Index: examples/adding.qbk
===================================================================
--- examples/adding.qbk	(revision 69506)
+++ examples/adding.qbk	(working copy)
@@ -66,7 +66,7 @@
     }}
 
 `while_eval` is an example of how to evaluate an expression. It gets called in
-the `rule::while` action. `while_gen` and `while? are the expression template
+the `rule::while` action. `while_gen` and `while_` are the expression template
 front ends. Let's break this apart to undestand what's happening. Let's start at
 the bottom. It's easier that way.
 
@@ -87,8 +87,8 @@
 
     expression::while_<Cond, Do>::type
 
-where `Cond` is the type of `cond` and `Do` is the type of `do_`. Notice how we are using phoenix's
-[link phoenix.inside.expression Expression) mechanism here
+where `Cond` is the type of `cond` and `Do` is the type of `do_`. Notice how we are using Phoenix's
+[link phoenix.inside.expression Expression] mechanism here
         
     template <typename Do>
     typename expression::while_<Cond, Do>::type const
Index: examples/extending_actors.qbk
===================================================================
--- examples/extending_actors.qbk	(revision 69506)
+++ examples/extending_actors.qbk	(working copy)
@@ -13,7 +13,7 @@
 library, and one of the many customization points. The default actor implementation
 provides several operator() overloads which deal with the evaluation of expressions.
 
-For some uses cases this might not be enough. For convenience it is thinkable to
+For some use cases this might not be enough. For convenience it is thinkable to
 provide custom member functions which generate new expressions. An example is the
 [link phoenix.modules.statement.___if_else_____statement '''if_else_'''
 Statement] which provides an additional else member for generating a lazy if-else
