# Boost :

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.