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

Subject: [Boost-commit] svn:boost r76479 - in trunk/libs/proto/doc: . reference
From: eric_at_[hidden]
Date: 2012-01-14 00:10:42

Author: eric_niebler
Date: 2012-01-14 00:10:41 EST (Sat, 14 Jan 2012)
New Revision: 76479
URL: http://svn.boost.org/trac/boost/changeset/76479

Log:
fix some typos. thanks david j.
Text files modified: 
   trunk/libs/proto/doc/back_end.qbk          |     2 +-                                      
   trunk/libs/proto/doc/front_end.qbk         |    16 ++++++++--------                        
   trunk/libs/proto/doc/reference/extends.xml |     7 ++++---                                 
   3 files changed, 13 insertions(+), 12 deletions(-)

Modified: trunk/libs/proto/doc/back_end.qbk
==============================================================================
--- trunk/libs/proto/doc/back_end.qbk	(original)
+++ trunk/libs/proto/doc/back_end.qbk	2012-01-14 00:10:41 EST (Sat, 14 Jan 2012)
@@ -1322,7 +1322,7 @@
         std::cout << "caught division by zero!\n";
     }
 
-The above code demonstrates how a single grammar can be used with different transforms specified externally. This makes it possibly to reuse a grammar to drive several different computations.
+The above code demonstrates how a single grammar can be used with different transforms specified externally. This makes it possible to reuse a grammar to drive several different computations.
 
 [endsect]
 

Modified: trunk/libs/proto/doc/front_end.qbk
==============================================================================
--- trunk/libs/proto/doc/front_end.qbk	(original)
+++ trunk/libs/proto/doc/front_end.qbk	2012-01-14 00:10:41 EST (Sat, 14 Jan 2012)
@@ -748,7 +748,7 @@
 
 [note This is an advanced topic. Feel free to skip this if you're just getting started with Proto.]
 
-The ability to /compose/ different EDSLs is one of their most exciting features. Consider how you build a parser using yacc. You write your grammar rules in yacc's domain-specific language. Then you embed semantic actions written in C within your grammar. Boost's Spirit parser generator gives you the same ability. You write grammar rules using Spirit.Qi and embed semantic actions using the Phoenix library. Phoenix and Spirit are both Proto-based domain-specific languages with their own distinct syntax and semantics. But you can freely embed Phoenix expressions within Spirit expressions. This section describes Proto's /sub-domain/ feature that lets you define famalies of interoperable domains.
+The ability to /compose/ different EDSLs is one of their most exciting features. Consider how you build a parser using yacc. You write your grammar rules in yacc's domain-specific language. Then you embed semantic actions written in C within your grammar. Boost's Spirit parser generator gives you the same ability. You write grammar rules using Spirit.Qi and embed semantic actions using the Phoenix library. Phoenix and Spirit are both Proto-based domain-specific languages with their own distinct syntax and semantics. But you can freely embed Phoenix expressions within Spirit expressions. This section describes Proto's /sub-domain/ feature that lets you define families of interoperable domains.
 
 [/======================]
 [heading Dueling Domains]
@@ -767,7 +767,7 @@
     struct spirit_domain  : proto::domain<proto::generator<spirit_expr> > {};
     struct phoenix_domain : proto::domain<proto::generator<phoenix_expr> > {};
 
-    // Implement the two expresison wrappers
+    // Implement the two expression wrappers
     template<typename E>
     struct spirit_expr
       : proto::extends<E, spirit_expr<E>, spirit_domain>
@@ -787,7 +787,7 @@
         proto::literal<int, spirit_domain> sp(0);
         proto::literal<int, phoenix_domain> phx(0);
 
-        // Whoops! What does it mean to add two expression in different domains?
+        // Whoops! What does it mean to add two expressions in different domains?
         sp + phx; // ERROR
     }
 
@@ -795,7 +795,7 @@
 
 [def __spirit_domain__ [*spirit_domain]]
 
-    // Declare that phoenix_domain is a sub-somain of spirit_domain
+    // Declare that phoenix_domain is a sub-domain of spirit_domain
     struct phoenix_domain
       : proto::domain<proto::generator<phoenix_expr>, proto::_, __spirit_domain__>
     {};
@@ -808,7 +808,7 @@
 [heading Domain Resolution]
 [/------------------------]
 
-When there are multiple domains in play within a given expression, Proto uses some rules to figure out which domain "wins". The rules are loosly modeled on the rules for C++ inheritance. `Phoenix_domain` is a sub-domain of `spirit_domain`. You can liken that to a derived/base relationship that gives Phoenix expressions a kind of implicit conversion to Spirit expressions. And since Phoenix expressions can be "converted" to Spirit expressions, they can be freely combined with Spirit expressions and the result is a Spirit expression.
+When there are multiple domains in play within a given expression, Proto uses some rules to figure out which domain "wins". The rules are loosely modeled on the rules for C++ inheritance. `Phoenix_domain` is a sub-domain of `spirit_domain`. You can liken that to a derived/base relationship that gives Phoenix expressions a kind of implicit conversion to Spirit expressions. And since Phoenix expressions can be "converted" to Spirit expressions, they can be freely combined with Spirit expressions and the result is a Spirit expression.
 
 [note Super- and sub-domains are not actually implemented using inheritance. This is only a helpful mental model.]
 
@@ -828,11 +828,11 @@
         sp + 1;
     }
 
-In light of the above discussion about sub-domains, one could think of `proto::default_domain` as a sub-domain of /every other domain/. Expressions in the default domain have a kind of implicit conversion to every other domain type. That's exactly how Proto sees it! What's more, you can define your domain to be a sub-domain of the default domain. In so doing, you give expression in your domain conversions to expressions in every other domain. This is like a "free love" domain, because it will freely mix with all other domains.
+Expressions in the default domain (or non-expressions like [^1]) have a kind of implicit conversion to expressions every other domain type. What's more, you can define your domain to be a sub-domain of the default domain. In so doing, you give expressions in your domain conversions to expressions in every other domain. This is like a ["free love] domain, because it will freely mix with all other domains.
 
-Let's think again about the Phoenix EDSL. Since it provides generally useful lambda functionionality, it's reasonable to assume that lots of other EDSLs besides Spirit might want the ability to embed Phoenix expressions. In other words, `phoenix_domain` should be a sub-domain of `proto::default_domain`, not `spirit_domain`:
+Let's think again about the Phoenix EDSL. Since it provides generally useful lambda functionality, it's reasonable to assume that lots of other EDSLs besides Spirit might want the ability to embed Phoenix expressions. In other words, `phoenix_domain` should be a sub-domain of `proto::default_domain`, not `spirit_domain`:
 
-    // Declare that phoenix_domain is a sub-somain of proto::default_domain
+    // Declare that phoenix_domain is a sub-domain of proto::default_domain
     struct phoenix_domain
       : proto::domain<proto::generator<phoenix_expr>, proto::_, proto::default_domain>
     {};

Modified: trunk/libs/proto/doc/reference/extends.xml
==============================================================================
--- trunk/libs/proto/doc/reference/extends.xml	(original)
+++ trunk/libs/proto/doc/reference/extends.xml	2012-01-14 00:10:41 EST (Sat, 14 Jan 2012)
@@ -79,12 +79,10 @@
       , my_domain       // The domain associated with this expression extension
     &gt;
 {
-    typedef proto::extends&lt; Expr, my_expr&lt; Expr &gt;, my_domain &gt; base_type;
-    
     // An expression extension is constructed from the expression
     // it is extending.
     my_expr( Expr const &amp; e = Expr() )
-      : base_type( e )
+      : my_expr::proto_extends( e )
     {}
     
     // Unhide proto::extends::operator=
@@ -134,6 +132,9 @@
         <typedef name="proto_derived_expr">
           <type>Derived</type>
         </typedef>
+        <typedef name="proto_extends">
+          <type>extends</type>
+        </typedef>
         <typedef name="proto_tag">
           <type>typename proto_base_expr::proto_tag</type>
         </typedef>