Re: [boost] [Proto] review

From: Eric Niebler (eric_at_[hidden])
Date: 2008-03-02 20:19:15

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