
Boost : 
From: Larry Evans (jcampbell3_at_[hidden])
Date: 20010526 22:24:42
isistech_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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk