Hi News (a.k.a. Dave ;-), news.gmane.org wrote:

...

Please always state in your review, whether you think the library should be accepted as a Boost library!

Yes, Proto should definitely be accepted. It is a very useful foundation tool for building a DSEL with efficient execution performance.

Thanks!

...

- What is your evaluation of the design?

The design is very clean and well thought out. This is Eric's second version of Proto and he obviously learned valuable lessons from the earlier version(s).

Actually it's version 3, but who's counting? ;-)

...

- What is your evaluation of the implementation?

I read through much of the code and while I can't claim to understand it all, it seems well written.

Would it be possible to eliminate the need for dummy parameters in examples like "make_pair_(1, 3.14), j, j )", where the state and visitor parameters are not used?

It would be nice, but I can't think of a way to do this without forcing everyone who wants to write a new transform to write additional operator() overloads and result<> specializations.

In many places I see "when<_, xxx>" to mean transform anything to xxx. Is there an advantage to this syntax or would "always<xxx>" be simpler?

When you see when<_,xxx> e.g. in the definition of another transform, it usually means "interpret xxx as a transform in the way when<> does." xxx can be a primitive transform, or a function type that when<> interprets as a transform. So, you can read when<_,xxx> as if it were "as_primitive_transform<xxx>". As for whether I should actually add "as_primitive_transform<xxx>" as a synonym for when<_,xxx>, I'd rather not because that would duplicate when<>'s functionality for little benefit, IMO. I believe I had already promised Larry Evans to add a note somewhere in the docs clarifying this somewhat non-obvious use Proto makes of when<>.

...

- What is your evaluation of the documentation?

The documentation is good with many examples, but it took me several readings to "get it".

I would like to see a section on debugging strategies and examples, particularly for Proto transforms. The display_expr() function could be documented with an example.

Good point. I don't think I document display_expr() anywhere in the users' guide.

Is there a way to create a "trace" of compiler messages, for something like the CalcArity example, where the compiler outputs warning messages as it does the mpl::max comparisons? I tried using techniques from the "C++ Template Metaprogramming" book, but couldn't get it to work. Any tools or techniques to help debugging would be appreciated.

An interesting suggestion, but I'm not sure how to go about baking debugging features into the transforms. I can give it some thought.

I couldn't find definitions for macros like BOOST_PROTO_EXTENDS_xxx, BOOST_PROTO_DEFINE_OPERATIONS, and BOOST_PROTO_AUTO. Also, proto::pod_generator isn't described anywhere.

Thanks for pointing out these omissions.

It would be helpful if the Concepts section were expanded with more definitions, because I kept getting confused about the precise meaning of grammar, transform, pattern, context, domain, generator, etc.

The concepts section needs to be fleshed out, and a brief glossary of terms is a great suggestion, thanks.

...

- What is your evaluation of the potential usefulness of the library?

It will be useful in a variety of problem domains, where it's important to define a clean syntax to a high-performance implementation. However, the effort needed to understand Proto and write and debug code for it is a significant consideration.

I hope Proto finds more uses than just hi-perf DSELs, and that people aren't scared off by its apparent complexity. I see it as a useful tool whenever you'd like to assign novel semantics to operator overloads. Perhaps I need to add more simple examples that solve real-world problems and comment them heavily. See the new Map Assign example, for instance. It's a DSEL with only 1 operator overload: operator().

...

- Did you try to use the library? With what compiler? Did you have any problems?

I wrote some small test cases and they ran well. The only problem I had was a proto::flatten test case that caused a "C1001 internal compiler error" on the msvc9.0 compiler. I sent this test case to Eric.

...

- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?

I've been following Proto for over a year. I spent about two days reviewing the current version.

...

- Are you knowledgeable about the problem domain?

Yes, somewhat. I've written some test cases but haven't tried a real application.

Thanks for your time, -- Eric Niebler Boost Consulting www.boost-consulting.com