Re: [boost] [Review] xpressive

From: Eric Niebler (eric_at_[hidden])
Date: 2005-09-14 22:05:55

Answers inline...

Scott Woods wrote:
> 
> 1. What is the benefit of providing the complete match in the
> first entry of the results? e.g. "what[0]". While this is consistent
> with a long tradition in RE, after some time with STL it's
> presence at position zero wasnt as comfortable as I expected.

I'm curious, what did your experience with STL lead you to expect?

I did it this way because TR1 regex does it that way. Although xpressive 
is not a fully compliant TR1 regex implementation, minimizing gratuitous 
differences can only help.

> 2. Why the slash syntax in dynamic regex? The resulting
> requirement for a double is fairly ugly. It may be consistent with
> something (Perl/ECMA/..?) but on balance is it worth it?

I'm following the lead of every other regex package for C and C++ out 
there. Anything else, and there would be riots in the streets. I agree 
that the double-slashes are hard on the eyes, though. (So use static 
regexes insted. :-)

> 3. Why ">>" and not "," (comma). Did the "set" facillity
> take priority or does the low precedence of comma just result in
> a different ugliness (sorry, not really the word I want to use :-).

As Joel already said, operator precedence. Also, I completely stole 
Spirit's choice of operators, lock, stock and barrel. That's a conscious 
decision (made after much debate and hand-wringing) to ease any future 
unification, and so that Spirit users can be productive with xpressive 
with a minimum of fuss.

> 4. C++ operators and RE operators are not really comfortable
> bed-fellows. While the operator overloading technique has given
> something useful and concise was there no flirtation with "key words"
> (i.e. in the manner of "as_xpr"). "+" could have been "one_or_more( xpr )".

Joel already answered this one, too. Concise syntax is part of what 
makes regexes powerful. And don't underestimate the power of an infix 
notation to *greatly* reduce the syntactic burden. Imagine if the 
sequence operator were spelled "sequence()" instead of ">>". Instead of 
"a >> b >> c >> d" you would have "sequence(a, sequence(b, sequence(c, 
d)))". This quickly becomes unmanageable.

> 5. There didnt appear to be much specific thought given to file processing.
> Is
> this another "not yet implemented"? In particular elegant integration
> with any async I/O facillity arising from sockets and file I/O initiatives.

xpressive works generically with iterators. Spirit has a file iterator. 
That would be the way to go, IMO.

> 6. Very interested in the future of "semantic actions". Actions and file
> processing probably go together?

They're orthogonal, AFAICT.

> Appeared to be some minor problems such as initially not knowing what
> "_w" and "_d" meant. Was this my failing or was there a missing
> definition. Was the later use of "+alpha" and others inconsistent?

The docs can certainly be more clear on this point. It's been brought to 
my attention that I never say anywhere exactly what _w means. I'll clean 
all this up. Thanks.

> * What is your evaluation of the potential usefulness of the library?
> Huge. Some of that answer refers to the usefulness of RE but xpressive
> is obviously more. There has been some discussion about overlap with
> regex. It would be nice to clarify that.

I tried to clarify the issue of overlap in the following messages:

http://article.gmane.org/gmane.comp.lib.boost.devel/131005
http://article.gmane.org/gmane.comp.lib.boost.devel/131072

Do you have a specific question or concern that hasn't been addressed in 
these messages?

<snip>

> * Do you think the library should be accepted as a Boost library? Be
> sure to say this explicitly so that your other comments don't obscure your
> overall opinion.
> Yes.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com