Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk