Boost logo

Boost :

From: joel de guzman (isis-tech_at_[hidden])
Date: 2001-06-03 20:30:38


First a news tidbit:
The micro parser functionality as hinted by Vesa Karvonen
is already fully operational in the Spirit parser framework.
I'll upload the code asap (

We have uint_p, int_p(var) and real_p(var) parsers that can
be used as terminals in a Spirit EBNF descriptor.

Re-coding Vesa's original pseudo code:

Input formats for a complex ("f" indicates a floating point number):


We have:

   double re = 0;
   double im = 0;
    (real_p(re) | '(' >> real_p(re) >> !(',' >> real_p(im)) >>
')' ).Parse(scanner);

Syntax notes:

   a | b... alternative
   a >> b... sequencing
   !a... optional a


real_p(var) creates a RealParser<T> object parameterized by the floating
point type passed in. The type can be a user defined type such as Rational
or BigFloat or any type that conforms to the semantics of a real number.


Now onto another matter...

While coding the floating point parser of the form nnn.fffeee with the
Spirit framework, the sequence (concatenation) syntax issue keeps on
lurking in my mind.

It has been my goal to introduce as much operators and functionality
into the framework to compensate for the waknesses of RD while
taking advantage of its strengths (e.g. flexibility and LL(inf)). With
that in mind, I took more time to scrutinize the real number parser.

At first, I came up with this <simplistic> ENBF pseudo grammar:

dec = '.' >> ddd;
exp = ('e' | 'E') >> eee;
float = (nnn | dec | nnn >> dec ) >> !exp;

I thought, if I have an operator for sequential-or operator

   a <seq_or> b; ---> a | b | ab
   /* at least one must hold true. If both, it should be in sequence */

then this could have been simplified. It dawned on me that sequencing
as we have it now, is actually sequential-and (hinted by Larry
Evans) where:

   a <seq_and> b; ---> a b
   /* both must hold true and in sequence */

Now, I thought, what if we use && to mean sequential-and
and || to mean sequential-or (a new operator)? Would that
be a good alternative to the controversial >> operator?


Thank you,
Joel de Guzman

PS> Thank God for C's abundance of operators.

Boost list run by bdawes at, gregod at, cpdaniel at, john at