[Boost-commit] svn:boost r51585 - in trunk/libs/proto/doc: . reference/transform

Subject: [Boost-commit] svn:boost r51585 - in trunk/libs/proto/doc: . reference/transform
From: eric_at_[hidden]
Date: 2009-03-03 19:01:10

Author: eric_niebler
Date: 2009-03-03 19:01:09 EST (Tue, 03 Mar 2009)
New Revision: 51585
URL: http://svn.boost.org/trac/boost/changeset/51585

Log:
minor doc tweaks
Text files modified: 
   trunk/libs/proto/doc/back_end.qbk                 |     2 +-                                      
   trunk/libs/proto/doc/front_end.qbk                |     2 +-                                      
   trunk/libs/proto/doc/reference/transform/make.xml |    36 +++++++++++++++++-------------------    
   3 files changed, 19 insertions(+), 21 deletions(-)

Modified: trunk/libs/proto/doc/back_end.qbk
==============================================================================
--- trunk/libs/proto/doc/back_end.qbk	(original)
+++ trunk/libs/proto/doc/back_end.qbk	2009-03-03 19:01:09 EST (Tue, 03 Mar 2009)
@@ -19,7 +19,7 @@
   expression, but with rules in a Proto grammar. In this way, they are like 
   semantic actions in other compiler-construction toolkits.
 
-Two ways to evaluate expressions! How to choose? Contexts are a bit simpler to understand and to debug, since they are largely procedural, so contexts are a good place to start. But although transforms are more advanced, they are also more powerful; since they are associated with rules in your grammar, you can select the proper transform based on the entire /structure/ of a sub-expression rather than simply on the type of its top-most node.
+Two ways to evaluate expressions! How to choose? Since contexts are largely procedural, they are a bit simpler to understand and debug so they are a good place to start. But although transforms are more advanced, they are also more powerful; since they are associated with rules in your grammar, you can select the proper transform based on the entire /structure/ of a sub-expression rather than simply on the type of its top-most node.
 
 Also, transforms have a concise and declarative syntax that can be confusing at first, but highly expressive and fungible once you become accustomed to it. And -- this is admittedly very subjective -- the author finds programming with Proto transforms to be an inordinate amount of /fun!/ Your mileage may vary.
 

Modified: trunk/libs/proto/doc/front_end.qbk
==============================================================================
--- trunk/libs/proto/doc/front_end.qbk	(original)
+++ trunk/libs/proto/doc/front_end.qbk	2009-03-03 19:01:09 EST (Tue, 03 Mar 2009)
@@ -389,7 +389,7 @@
 
 We need to make one additional small change to accommodate the POD-ness of our expression extension, which we'll describe below in the section on expression generators.
 
-What does _EXTENDS_ do? It defines a data member of expression type being extended; some nested typedefs that Proto requires; `operator=`, `operator[]` and `operator()` overloads for building expression templates; and a nested `result<>` template for calculating the return type of `operator()`. In this case, however, the `operator()` overloads and the `result<>` template are not needed because we are defining our own `operator()` in the `calculator<>` type. Proto provides additional macros for finer control over which member functions are defined. We could improve our `calculator<>` type as follows:
+What does _EXTENDS_ do? It defines a data member of the expression type being extended; some nested typedefs that Proto requires; `operator=`, `operator[]` and `operator()` overloads for building expression templates; and a nested `result<>` template for calculating the return type of `operator()`. In this case, however, the `operator()` overloads and the `result<>` template are not needed because we are defining our own `operator()` in the `calculator<>` type. Proto provides additional macros for finer control over which member functions are defined. We could improve our `calculator<>` type as follows:
 
     // The calculator<> expression wrapper makes expressions
     // function objects.

Modified: trunk/libs/proto/doc/reference/transform/make.xml
==============================================================================
--- trunk/libs/proto/doc/reference/transform/make.xml	(original)
+++ trunk/libs/proto/doc/reference/transform/make.xml	2009-03-03 19:01:09 EST (Tue, 03 Mar 2009)
@@ -85,7 +85,7 @@
         
         <inherit><classname>proto::transform</classname>&lt; make&lt;T&gt; &gt;</inherit>
         
-        <purpose>A <conceptname>PrimitiveTransform</conceptname> which computes a type by evaluating
+        <purpose>A <conceptname>PrimitiveTransform</conceptname> that computes a type by evaluating
           any nested transforms and then constructs an object of that type. </purpose>
         
         <description>
@@ -124,20 +124,28 @@
 
               <para>
                 If <computeroutput>T</computeroutput> is an <conceptname>ObjectTransform</conceptname> of the form
-                <computeroutput>
-                  Object(A<subscript>0</subscript>,...A<subscript>n</subscript>)
-                </computeroutput>, then let <computeroutput>O</computeroutput> be
-                the return type <computeroutput>Object</computeroutput>. Otherwise, let <computeroutput>O</computeroutput>
+                <computeroutput>Object(A<subscript>0</subscript>,...A<subscript>n</subscript>)</computeroutput>,
+                then let <computeroutput>O</computeroutput> be the return type
+                <computeroutput>Object</computeroutput>. Otherwise, let <computeroutput>O</computeroutput>
                 be <computeroutput>T</computeroutput>. The <computeroutput>result_type</computeroutput> typedef is
                 then computed as follows:
               </para>
               <para>
                 <itemizedlist>
                   <listitem>
-                    If <computeroutput>O</computeroutput> is a template like
-                    <computeroutput>
-                      S&lt;X<subscript>0</subscript>,...X<subscript>n</subscript>&gt;
-                    </computeroutput>, then the result type is calculated as follows:
+                    <para>
+                      If <computeroutput>O</computeroutput> is a <conceptname>Transform</conceptname>, then let
+                      the result type be
+                      <computeroutput>
+                        boost::result_of&lt;<classname>proto::when</classname>&lt;<classname>_</classname>, O&gt;(Expr, State, Data)&gt;::type
+                      </computeroutput>.
+                      Note that a substitution took place.
+                    </para>
+                  </listitem>
+                  <listitem>
+                    Otherwise, if <computeroutput>O</computeroutput> is a template like
+                    <computeroutput>S&lt;X<subscript>0</subscript>,...X<subscript>n</subscript>&gt;</computeroutput>,
+                    then the result type is calculated as follows:
                     <itemizedlist>
                       <listitem>
                         <para>
@@ -175,16 +183,6 @@
                     </itemizedlist>
                   </listitem>
                   <listitem>
-                    <para>
-                      Otherwise, if <computeroutput>O</computeroutput> is a <conceptname>Transform</conceptname>, then let
-                      the result type be
-                      <computeroutput>
-                        boost::result_of&lt;<classname>proto::when</classname>&lt;<classname>_</classname>, O&gt;(Expr, State, Data)&gt;::type
-                      </computeroutput>.
-                      Note that a substitution took place.
-                    </para>
-                  </listitem>
-                  <listitem>
                     Otherwise, the result type is <computeroutput>O</computeroutput>, and note that no
                     substitution took place.
                   </listitem>