Re: [boost] Formal Review: The Spirit Parser Framework.

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2002-10-13 15:08:04

Joel de Guzman wrote:
 > ----- Original Message -----
 > From: "Larry Evans" <jcampbell3_at_[hidden]>
[snip]

 >>which is followed by an example with no cycles.  However, I think
 >>even with cycles, there should be some explanation of why weak_ptr<rule>
 >>couldn't occur on the rhs and avoid the cycle problem.
 >
 >
 > I re-read the paragraph again and indeed it is confusing. I
 > will try to restructure the paragraph as you suggested.
 >
 > Thanks again!
 > --Joel
 >

You're welcome.  I'm still curious about why weak_ptr doesn't
solve the cycle problem.  Are the posts about rule_holder<RuleT>
between you and Hartmut related to this?

Also, I've continued to read the docs and gotten to trees.html,
but I still have a ways to go.  Anyway, what I've got so far
follows:

Spirit html suggestions:
-----------------------

The format of these suggestions is the .html filename followed by
':' on 1 line, followed by suggestions for that file.
Sometimes the current contents are presented followed by a line
prefixed with -> and containing the suggested change.

This file is best viewed with a fixed width font.

<------------------- begin corrections ------------------->

indepth_the_parser.html:

   Basically, a parser accepts a scanner comprising of a
->                                      comprised of

indepth_the_scanner.html:

   Dereference/get a character from the input
->                  value_t

    The following code snippet demonstrates a simple policy that
    inhibits the case of the read character from the input:
-> converts all characters to lower case:

functional.html:

    In Haskell, for example, there is what are called parser
    combinators which are strikingly similar to the approach taken
    by Spirit- parser functions are composed using various
-->by Spirit- parser functions which are composed using

    In the "snippet from the phoenix_calc.cpp example" there
    appears "arg1" several times.  This is also true in
    closures.html; however, there's no explanation of its meaning
    and a `grep arg1 *.html` only shows it occurs in these two
    files.  The documentation needs some explanation of its
    meaning.

closures.html:

     We subclass a user defined closure struct, my_closure, from
     free_closure. The parameters to free_closure from left to
     right are:

     1. The user defined my_closure.
->  1. The user defined my_closure3.
     2. The type of the first closure member: double.
     3. The type of the second closure member: int.

confix.html:

     start >> (expr[func] - close) >> close
->  open  >> (expr[func] - close) >> close

     A similar typo appears several times.

trees.html:

     pt_parse() is similar to parse(), there are a total of four.

->  There are a total of four what?  Also, maybe this should be
     prefixed by ',and' instead of just ','. (English grammar
     experts please?). Based on ouput of `find . -name \*.hpp
     -exec grep pt_parse {} \; -ls` in boost/spirit, this probably
     refers to the next sentence, in which case, maybe it should
     be rephrased as:

       There are a total of 4 pt_parse overloads: ...

     However, I'm wondering if this extra information is needed
     since it's repeated with more specific information in the
     "Usage" section, and I didn't see where it was used between
     the "total of four" sentence and the "Usage" section.  It
     seemed like it was just a distraction at the "total of four"
     point.