Re: [boost] Re: [ANN] Spirit C++ parser framework.

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2001-05-26 22:24:42

isis-tech_at_[hidden] wrote:

> --- In boost_at_y..., Larry Evans <jcampbell3_at_p...> wrote:
> > joel de guzman wrote:
> > > I like about the [] is that it clearly separates iteration from
> grouping:
> > >
> > > (a | b | c)[0][more]
> > >
> > > vs.
> > >
> > > (a | b | c)(0, more)
> > >
> > > So, why is the [][] yucky?
> > >
> >
> > With normal bnf, for any expression, e.
> >
> >      e** == e*
> >
> > the analogy with [][] would be
> >      e[0][more][0][more] == e[0][more]
> > but then what does:
> >       e[0]
> > mean?  The empty language or the empty string?
> > And is the following:
> >       e[0] == e[0][more][0]
> > true?  Or are an even number of [] required?  In other words,
> >    e[whatever]  | f
> >    e[whatever] >> f
> > are not defined?
>
> Load and clear! I'm convinced.
> Joel de Guzman
>
> PS> But what if we disallow the third level []?

The only way I can think of to make this work is if each odd number of applications
results in a type, call it ProxParser, which you can only do one thing with: apply the []
operator again, the result of which is a Parser.  In other words:

      ProxParser Parser::operator[](int){...}
      struct ProxParser{
         friend Parser;
        Parser operator[](int){...}
      };

>
> e[0] is a paradox even with the other iterator
> styles: e(0) or e.repeat(0). Should it match
> anything or nothing? Matching anything is
> the universal string U. The simplest way out
> thatI could think of is to disallow it.

In compiler texts, the epsilon symbol matches
the null string.  In other words:

        epsilon | e == "optional e"

and, I think:

        epsilon >> e == e

so, maybe e[0] could be defined, but with the
above semantics for epsilon?  OOPS, if it is, then
that raises the question of is e[1] >>e defined;
so,  I agree that leaving it undefined for any
operation other than []is the way to go.