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::type @@ -229,7 +229,7 @@ #include -Finally, the `expression::null::type` does nothing; (a "bum", if you will :-). +Finally, the `expression::null::type` does nothing; (a "bum", if you will :-) ). There's a sole `expression::null::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 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`. 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 @@ -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::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` 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_::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 expression::while_::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