[Boost-commit] svn:boost r50010 - trunk/libs/spirit/doc/lex

Subject: [Boost-commit] svn:boost r50010 - trunk/libs/spirit/doc/lex
From: jamin.hanson_at_[hidden]
Date: 2008-11-29 07:33:46

Author: ben_hanson
Date: 2008-11-29 07:33:45 EST (Sat, 29 Nov 2008)
New Revision: 50010
URL: http://svn.boost.org/trac/boost/changeset/50010

Log:
grammar fixes
Text files modified: 
   trunk/libs/spirit/doc/lex/introduction.qbk |    30 +++++++++++++++---------------          
   1 files changed, 15 insertions(+), 15 deletions(-)

Modified: trunk/libs/spirit/doc/lex/introduction.qbk
==============================================================================
--- trunk/libs/spirit/doc/lex/introduction.qbk	(original)
+++ trunk/libs/spirit/doc/lex/introduction.qbk	2008-11-29 07:33:45 EST (Sat, 29 Nov 2008)
@@ -29,17 +29,17 @@
   though since some tools such as lint look at comments, this conflation is not 
   perfect.
 
-[heading Why Using a Separate Lexer]
+[heading Why Use a Separate Lexer?]
 
 Typically, lexical scanning is done in a separate module from the parser, 
-feeding the parser with a stream of input tokens only. Now, theoretically it is 
-not necessary to do this separation. In the end there is only one set of 
+feeding the parser with a stream of input tokens only. Theoretically it is 
+not necessary implement this separation as in the end there is only one set of 
 syntactical rules defining the language, so in theory we could write the whole 
-parser in one module. In fact, __qi__ allows to write parsers without using a 
+parser in one module. In fact, __qi__ allows you to write parsers without using a 
 lexer, parsing the input character stream directly, and for the most part this 
 is the way __spirit__ has been used since its invention.
 
-However, the separation has both practical and theoretical bases and proves to 
+However, this separation has both practical and theoretical bases and proves to 
 be very useful in practical applications. In 1956, Noam Chomsky defined the 
 "Chomsky Hierarchy" of grammars:
 
@@ -67,10 +67,10 @@
     digit      := [0-9]
 
     identifier := letter [ letter | digit ]*
-    integer    := digit*
+    integer    := digit+
 
 Higher level parts of practical grammars tend to be more complex and can't be
-implemented using plain regular expressions anymore. We need to store 
+implemented using plain regular expressions. We need to store 
 information on the built-in hardware stack while recursing the grammar 
 hierarchy, and that in fact this is the preferred approach used for top-down 
 parsing. Since it takes a different kind of abstract machine to parse the two 
@@ -78,7 +78,7 @@
 into a separate module which is built around the idea of a state machine. The 
 goal here is to use the simplest parsing technique needed for the job.
 
-Another, more practical reason for separating the scanner from the parser is
+Another, more practical, reason for separating the scanner from the parser is
 the need for backtracking during parsing. The input data is a stream of 
 characters, which is often thought to be processed left to right without any 
 backtracking. Unfortunately, in practice most of the time that isn't possible.
@@ -114,14 +114,14 @@
 rest of your program, making it possible to freely access any context 
 information and data structure. Since the C++ compiler sees all the code it
 will generate optimal code nomatter what configuration options have been chosen
-by the user. __lex__ gives you all the features you could get from a similar
+by the user. __lex__ gives you the vast majority of features you could get from a similar
 __flex__ program without the need to leave C++ as a host language:
 
-* the definition of tokens is done using regular expressions (patterns)
-* the token definitions can refer to special substitution string (pattern 
+* The definition of tokens is done using regular expressions (patterns)
+* The token definitions can refer to special substitution strings (pattern 
   macros) simplifying pattern definitions
-* the generated lexical scanner may have multiple start states
-* it is possible to attach code to any of the token definitions; this code gets
+* The generated lexical scanner may have multiple start states
+* It is possible to attach code to any of the token definitions; this code gets
   executed whenever the corresponding token pattern has been matched
 
 Even if it is possible to use __lex__ to generate C++ code representing 
@@ -129,10 +129,10 @@
 more detail in the section __sec_lex_static_model__) - a model
 very similar to the way __flex__ operates - we will mainly focus on the 
 opposite, the /dynamic/ model. You can directly integrate the token definitions 
-into your C++ program, building the lexical analyzer dynamicly at runtime. The 
+into your C++ program, building the lexical analyzer dynamically at runtime. The 
 dynamic model is something not supported by __flex__ or other lexical scanner 
 generators (such as __re2c__, __ragel__, etc.). But it is very flexible and 
-allows to speed up the development of your application.
+allows you to speed up the development of your application.
 
 [heading The Library Structure of __lex__]