* What is your evaluation of the design? Good. It has taken some powerful, established technologies (e.g. regular expressions and parser generators) and delivered a C++ facillity that uses some of the latest C++ techniques. Hosting these technologies within C++ syntax has resulted in some slightly jarring constructs (e.g. prefix "one-or-more", tag assignment) but the set of design decisions made seem very reasonable. There were some corners that got me curious; the following queries are therefore more about curiosity than suggestions for change. 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. 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? 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 :-). 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 )". Maybe the keyword version is viable as an alternate targeted at beginners? Unjustifiably complex? 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. 6. Very interested in the future of "semantic actions". Actions and file processing probably go together? * What is your evaluation of the implementation? Cannot say. Not used. * What is your evaluation of the documentation? Good. I liked the balance of technical terminology combined with some informality. 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? * 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. The uptake of RE within the development community (at least, the one where I live) is almost embarrassingly low. I have seen many circumstances that cried out for the power and rigor of RE that instead got limited, buggy hand-written solutions. The ease-of-use (installation, build and coding) of xpressive might help? * Did you try to use the library? With what compiler? Did you have any problems? No. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in-depth study with a glaring omission; the library was not used. Lack of time, old compiler, employer resistance to boost. * Are you knowledgeable about the problem domain? Yes. * 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. Cheers.