From: isis-tech_at_[hidden]
Date: 2001-05-26 21:58:38
--- In boost_at_y..., Larry Evans <jcampbell3_at_p...> wrote:
> joel de guzman wrote:
>
> > From: "Douglas Gregor" :
> >
> > > > I agree. I think that reads much more clear to me. The [][]
idea is
> > > > only useful if you REALLY want to use []'s.
> > >
> > > I also like the a.repeat(0, more) and repeat<0, more>(a)
syntax, though my
> > > preference would be to remove some of the extra typing and go
to:
> > >
> > > a<0, more>()
> > > a(0, more)
> > >
> > > Supporting both may help some optimizations but also allows
variable
> > lengths.
> > >
> >
> > Yet after sometime tinkering with the [][], it grows on you. One
thing
> > 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 []?
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.