[Boost-commit] svn:boost r78835 - trunk/libs/proto/doc

Subject: [Boost-commit] svn:boost r78835 - trunk/libs/proto/doc
From: eric_at_[hidden]
Date: 2012-06-06 16:07:34

Author: eric_niebler
Date: 2012-06-06 16:07:33 EDT (Wed, 06 Jun 2012)
New Revision: 78835
URL: http://svn.boost.org/trac/boost/changeset/78835

Log:
fix minor typos
Text files modified: 
   trunk/libs/proto/doc/back_end.qbk          |     2 +-                                      
   trunk/libs/proto/doc/front_end.qbk         |     8 ++++----                                
   trunk/libs/proto/doc/installation.qbk      |     2 +-                                      
   trunk/libs/proto/doc/intermediate_form.qbk |     4 ++--                                    
   trunk/libs/proto/doc/preface.qbk           |     2 +-                                      
   trunk/libs/proto/doc/proto.qbk             |     4 ++--                                    
   6 files changed, 11 insertions(+), 11 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-06-06 16:07:33 EDT (Wed, 06 Jun 2012)
@@ -696,7 +696,7 @@
 
 [note *Transforms are a Domain-Specific Language*
 
-`LeftmostLeaf( proto::_child0 )` /looks/ like an invocation of the `LeftmostLeaf` function object, but it's not, but then it actually is! Why this confusing subterfuge? Function types give us a natural and concise syntax for composing more complicated transforms from simpler ones. The fact that the syntax is suggestive of a function invocation is on purpose. It is a embedded domain-specific language for defining expression transformations. If the subterfuge worked, it may have fooled you into thinking the transform is doing exactly what it actually does! And that's the point.]
+`LeftmostLeaf( proto::_child0 )` /looks/ like an invocation of the `LeftmostLeaf` function object, but it's not, but then it actually is! Why this confusing subterfuge? Function types give us a natural and concise syntax for composing more complicated transforms from simpler ones. The fact that the syntax is suggestive of a function invocation is on purpose. It is an embedded domain-specific language for defining expression transformations. If the subterfuge worked, it may have fooled you into thinking the transform is doing exactly what it actually does! And that's the point.]
 
 The type `LeftmostLeaf( proto::_child0 )` is an example of a /callable transform/. It is a function type that represents a function object to call and its arguments. The types `proto::_child0` and `proto::_value` are /primitive transforms/. They are plain structs, not unlike function objects, from which callable transforms can be composed. There is one other type of transform, /object transforms/, that we'll encounter next.
 

Modified: trunk/libs/proto/doc/front_end.qbk
==============================================================================
--- trunk/libs/proto/doc/front_end.qbk	(original)
+++ trunk/libs/proto/doc/front_end.qbk	2012-06-06 16:07:33 EDT (Wed, 06 Jun 2012)
@@ -10,13 +10,13 @@
     Defining Terminals and Non-Terminals of Your EDSL]
 [/================================================================================]
 
-Here is the fun part: designing your own mini-programming language. In this section we'll talk about the nuts and bolts of designing a EDSL interface using Proto. We'll cover the definition of terminals and lazy functions that the users of your EDSL will get to program with. We'll also talk about Proto's expression template-building operator overloads, and about ways to add additional members to expressions within your domain.
+Here is the fun part: designing your own mini-programming language. In this section we'll talk about the nuts and bolts of designing an EDSL interface using Proto. We'll cover the definition of terminals and lazy functions that the users of your EDSL will get to program with. We'll also talk about Proto's expression template-building operator overloads, and about ways to add additional members to expressions within your domain.
 
 [/=======================]
 [section Making Terminals]
 [/=======================]
 
-As we saw with the Calculator example from the Introduction, the simplest way to get a EDSL up and running is simply to define some terminals, as follows.
+As we saw with the Calculator example from the Introduction, the simplest way to get an EDSL up and running is simply to define some terminals, as follows.
 
     // Define a literal integer Proto expression.
     proto::terminal<int>::type i = {0};
@@ -501,7 +501,7 @@
 [/==========================================================]
 
 By default, Proto defines every possible operator overload for Protofied
-expressions. This makes it simple to bang together a EDSL. In some cases, however, the presence of Proto's promiscuous overloads can lead to confusion or worse. When that happens, you'll have to disable some of Proto's overloaded operators. That is done by defining the grammar for your domain and specifying it as the second parameter of the _domain_ template.
+expressions. This makes it simple to bang together an EDSL. In some cases, however, the presence of Proto's promiscuous overloads can lead to confusion or worse. When that happens, you'll have to disable some of Proto's overloaded operators. That is done by defining the grammar for your domain and specifying it as the second parameter of the _domain_ template.
 
 In the [link boost_proto.users_guide.getting_started.hello_calculator Hello Calculator] section, we saw an example of a Proto grammar, which is repeated here:
 
@@ -862,7 +862,7 @@
 [section:code_repetition Generating Repetitive Code with the Preprocessor]
 [/=======================================================================]
 
-Sometimes as a EDSL designer, to make the lives of your users easy, you have to make your own life hard. Giving your users natural and flexible syntax often involves writing large numbers of repetitive function overloads. It can be enough to give you repetitive stress injury! Before you hurt yourself, check out the macros Proto provides for automating many repetitive code-generation chores.
+Sometimes as an EDSL designer, to make the lives of your users easy, you have to make your own life hard. Giving your users natural and flexible syntax often involves writing large numbers of repetitive function overloads. It can be enough to give you repetitive stress injury! Before you hurt yourself, check out the macros Proto provides for automating many repetitive code-generation chores.
 
 Imagine that we are writing a lambda EDSL, and we would like to enable syntax for constructing temporary objects of any type using the following syntax:
 

Modified: trunk/libs/proto/doc/installation.qbk
==============================================================================
--- trunk/libs/proto/doc/installation.qbk	(original)
+++ trunk/libs/proto/doc/installation.qbk	2012-06-06 16:07:33 EDT (Wed, 06 Jun 2012)
@@ -42,7 +42,7 @@
 
 Currently, Boost.Proto is known to work on the following compilers:
 
-* Visual C++ 7.1 and higher
+* Visual C++ 8 and higher
 * GNU C++ 3.4 and higher
 * Intel on Linux 8.1 and higher
 * Intel on Windows 9.1 and higher

Modified: trunk/libs/proto/doc/intermediate_form.qbk
==============================================================================
--- trunk/libs/proto/doc/intermediate_form.qbk	(original)
+++ trunk/libs/proto/doc/intermediate_form.qbk	2012-06-06 16:07:33 EDT (Wed, 06 Jun 2012)
@@ -1073,7 +1073,7 @@
 contexts within your EDSL. This is easy to express with a grammar, and hard to do 
 with straight operator overloading.
 
-Third, using a EDSL grammar to flag invalid expressions can often yield better 
+Third, using an EDSL grammar to flag invalid expressions can often yield better 
 errors than manually selecting the overloaded operators.
 
 Fourth, the grammar can be used for more than just validation. You can use your 
@@ -1084,7 +1084,7 @@
 operators are overloaded within your domain. And to do it, you need to define a 
 grammar!]
 
-In a previous section, we used Proto to define a EDSL for a lazily evaluated calculator that allowed any combination of placeholders, floating-point literals, addition, subtraction, multiplication, division and grouping. If we were to write the grammar for this EDSL in [@http://en.wikipedia.org/wiki/Extended_Backus_Naur_Form EBNF], it might look like this:
+In a previous section, we used Proto to define an EDSL for a lazily evaluated calculator that allowed any combination of placeholders, floating-point literals, addition, subtraction, multiplication, division and grouping. If we were to write the grammar for this EDSL in [@http://en.wikipedia.org/wiki/Extended_Backus_Naur_Form EBNF], it might look like this:
 
 [pre
 group       ::= '(' expression ')'

Modified: trunk/libs/proto/doc/preface.qbk
==============================================================================
--- trunk/libs/proto/doc/preface.qbk	(original)
+++ trunk/libs/proto/doc/preface.qbk	2012-06-06 16:07:33 EDT (Wed, 06 Jun 2012)
@@ -27,7 +27,7 @@
 
 Expression Templates are an advanced technique that C++ library developers use to define embedded mini-languages that target specific problem domains. The technique has been used to create efficient and easy-to-use libraries for linear algebra as well as to define C++ parser generators with a readable syntax. But developing such a library involves writing an inordinate amount of unreadable and unmaintainable template mumbo-jumbo. Boost.Proto eases the development of [link boost_proto.users_guide.glossary.edsl domain-specific embedded languages (EDSLs)]. Use Proto to define the primitives of your mini-language and let Proto handle the operator overloading and the construction of the expression parse tree. Immediately evaluate the expression tree by passing it a function object. Or transform the expression tree by defining the grammar of your mini-language, decorated with an assortment of tree transforms provided by Proto or defined by you. Then use the grammar to give your users short and readable syntax err
ors for invalid expressions! No more mumbo-jumbo -- an expression template library developed with Proto is declarative and readable.
 
-In short, Proto is a EDSL for defining EDSLs.
+In short, Proto is an EDSL for defining EDSLs.
 
 [/====================================]
 [heading How to Use This Documentation]

Modified: trunk/libs/proto/doc/proto.qbk
==============================================================================
--- trunk/libs/proto/doc/proto.qbk	(original)
+++ trunk/libs/proto/doc/proto.qbk	2012-06-06 16:07:33 EDT (Wed, 06 Jun 2012)
@@ -36,7 +36,7 @@
 [/  Links   ]
 
 [def _PETE_                 
-  [@http://www.codesourcery.com/pooma/download.html PETE]]
+  [@http://acts.nersc.gov/formertools/pete/index.html PETE]]
 [def _spirit_fx_            
   [@http://spirit.sourceforge.net Spirit Parser Framework]]
 [def _spirit_               
@@ -252,7 +252,7 @@
 
 Most compilers have front ends and back ends. The front end parses the text of an input program into some intermediate form like an abstract syntax tree, and the back end takes the intermediate form and generates an executable from it.
 
-A library built with Proto is essentially a compiler for a embedded domain-specific language (EDSL). It also has a front end, an intermediate form, and a back end. The front end is comprised of the symbols (a.k.a., terminals), members, operators and functions that make up the user-visible aspects of the EDSL. The back end is made of evaluation contexts and transforms that give meaning and behavior to the expression templates generated by the front end. In between is the intermediate form: the expression template itself, which is an abstract syntax tree in a very real sense.
+A library built with Proto is essentially a compiler for an embedded domain-specific language (EDSL). It also has a front end, an intermediate form, and a back end. The front end is comprised of the symbols (a.k.a., terminals), members, operators and functions that make up the user-visible aspects of the EDSL. The back end is made of evaluation contexts and transforms that give meaning and behavior to the expression templates generated by the front end. In between is the intermediate form: the expression template itself, which is an abstract syntax tree in a very real sense.
 
 To build a library with Proto, you will first decide what your interface will be; that is, you'll design a programming language for your domain and build the front end with tools provided by Proto. Then you'll design the back end by writing evaluation contexts and/or transforms that accept expression templates and do interesting things with them.