Proto<markus>::review()(proto::accept);
Hi! I think Proto should be accepted for inclusion into boost. A general purpose Expression Template library is hard to write. Proto is the most sophisticated and closest approach to perfection available today. - What is your evaluation of the design? Proto is well-designed in many aspects, though I got the impression that some beauty and purity was sacrificed on the altar of compile-time efficiency, but that's OK. (And yes, I hate BOOST_PP_MACROS!) Proto catches the most important issues of a general purpose expression template library, I especially like the way how expression storage and expression evaluation is strictly separated and the way I can add my own functionality. Proto covers the most important aspects of an ET library, sometimes in very elegant ways. Proto's design adressed compile time issues. That's a value in itself. OTOH: Transforms leave me with mixed feelings. I am not very good at catching ideas without good step-by-step documentation and I got messed up with grammars vs. transforms. This part of proto is new and it looks like a candidate for rework. I'd like to have an extra review in half a year only on the grammar and transform part of proto (*)[comment below]. That's a DSEL all by itself and I guess that interface may have some pitfalls. Larry Evans has worked that out in detail. There may be issues in the naming convention used there, e.g. I am unsure whether and_ is the appropriate name for what it does. - What is your evaluation of the implementation? None. Not enough time. Steven Watanabe did it for us all. Code looks clean. For my taste too many levels of nested namespaces, but that's the boost trend at the moment. I may appreciate this style later in my life, once I understand why you need it. - What is your evaluation of the documentation? The quality varies from excellent to hard to read. I agree with all what David writes about the docs. There is some potential for improvement, but that should not hinder the inclusion into boost: we need a community effort here since Eric's skill level probably is way too high in order to have some feeling for why the unaware might have problems with parts of the doc. The teacher should be one step ahead, not too far ahead. - What is your evaluation of the potential usefulness of the library? We really, really need this. Better today than tomorrow. The whole world is waiting for this to come. And C++ again rocks - Did you try to use the library? A couple of hours, but only for some of the examples. - With what compiler? VC8, Intel 10.1 - Did you have any problems? Nope. Eric-faster-than-lightning fixed those before I could run into them ... - How much effort did you put into your evaluation? I read the docs three times and worked through some details. I investigated the type representation of expressions by reading purposely generated compiler error messages and tried to figure out the design. - Are you knowledgeable about the problem domain? I had several attempts to write some kind of ET library on my own, some parts published at daixtrose.sourceforge.net. I also planned to write something like proto myself, but due to lack of time and programming skills I lost the race before it began. (rm -rf /work/markus/ideas/expresion_templates_revisited) Eric, thanks for the time saved by the publication of proto. Markus P.S. This review is short, sorry. I had some unexpected tasks to do the last week which hindered further investigation. I'll put some more effort into this in the future. (*) I'd like to have an extra review on _every_ boost library in a 2-year-cycle. By this boost::multi_array could probably be forced to model assignable like any other STL container and ::_1 from boost::bind will move into its own namespace - just to mention my two favourite change requests ...
Markus Werle wrote:
I think Proto should be accepted for inclusion into boost.
Thanks.
A general purpose Expression Template library is hard to write. Proto is the most sophisticated and closest approach to perfection available today.
- What is your evaluation of the design?
Proto is well-designed in many aspects, though I got the impression that some beauty and purity was sacrificed on the altar of compile-time efficiency, but that's OK. (And yes, I hate BOOST_PP_MACROS!)
I've tried to keep the corner cutting to Proto's guts, not to its public interfaces. There are some minor exceptions here and there, which I'm continually working to eliminate. (Just today I found an efficient way to eliminate an inconsistency with how domains are deduced from the arguments to make_expr and unpack_expr.) Some deficiencies will go away in C++0x. If you spot inconsistencies, uglinesses and impurities in Proto's public interfaces, please bring them to my attention. One deficiency I'd like to address someday is the fact that transforms do not support the full TR1 ResultOf protocol. I'm still looking for an efficient solution to that one.
Proto catches the most important issues of a general purpose expression template library, I especially like the way how expression storage and expression evaluation is strictly separated and the way I can add my own functionality.
Proto covers the most important aspects of an ET library, sometimes in very elegant ways.
Proto's design adressed compile time issues. That's a value in itself.
OTOH: Transforms leave me with mixed feelings. I am not very good at catching ideas without good step-by-step documentation and I got messed up with grammars vs. transforms.
I like to believe that with better documentation your opinion of transforms would be different.
This part of proto is new and it looks like a candidate for rework.
Proto transforms are both new and very old. It's the third design, and the result of 4 years of thought and experimentation. IMO transforms are the strongest part of Proto. OTOH, I think transforms *docs* are easily the weakest. :-P That's not to say I think transforms are perfect. If you have suggestions for improving them, I'm open.
I'd like to have an extra review in half a year only on the grammar and transform part of proto (*)[comment below]. That's a DSEL all by itself and I guess that interface may have some pitfalls. Larry Evans has worked that out in detail.
Perhaps you can explain to me what Larry has worked out. I'm afraid he's lost me. :-(
There may be issues in the naming convention used there, e.g. I am unsure whether and_ is the appropriate name for what it does.
- What is your evaluation of the implementation?
None. Not enough time. Steven Watanabe did it for us all. Code looks clean. For my taste too many levels of nested namespaces, but that's the boost trend at the moment. I may appreciate this style later in my life, once I understand why you need it.
- What is your evaluation of the documentation?
The quality varies from excellent to hard to read. I agree with all what David writes about the docs.
As do I.
There is some potential for improvement, but that should not hinder the inclusion into boost: we need a community effort here since Eric's skill level probably is way too high in order to have some feeling for why the unaware might have problems with parts of the doc. The teacher should be one step ahead, not too far ahead.
The user docs for transforms assume too much, I admit.
- What is your evaluation of the potential usefulness of the library?
We really, really need this. Better today than tomorrow. The whole world is waiting for this to come. And C++ again rocks
:-)
- Did you try to use the library?
A couple of hours, but only for some of the examples.
- With what compiler?
VC8, Intel 10.1
- Did you have any problems?
Nope. Eric-faster-than-lightning fixed those before I could run into them ...
- How much effort did you put into your evaluation?
I read the docs three times and worked through some details. I investigated the type representation of expressions by reading purposely generated compiler error messages and tried to figure out the design.
Thanks for the effort, and for the discussion, and all the feedback.
- Are you knowledgeable about the problem domain?
I had several attempts to write some kind of ET library on my own, some parts published at daixtrose.sourceforge.net. I also planned to write something like proto myself, but due to lack of time and programming skills I lost the race before it began. (rm -rf /work/markus/ideas/expresion_templates_revisited) Eric, thanks for the time saved by the publication of proto.
P.S. This review is short, sorry. I had some unexpected tasks to do the last week which hindered further investigation. I'll put some more effort into this in the future.
Thanks. I'm eager to see what feedback you have after you've used Proto for a while. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Markus Werle wrote:
Proto is well-designed in many aspects, though I got the impression that some beauty and purity was sacrificed on the altar of compile-time efficiency, but that's OK.
<snip>
One deficiency I'd like to address someday is the fact that transforms do not support the full TR1 ResultOf protocol. I'm still looking for an efficient solution to that one.
FYI, I think I finally have a solution to this problem, and a bunch of others to boot. I got the idea from looking over the Egg library (thanks, Shunsuke!). Rather than writing primitive transforms as TR1 function objects directly, you'll use a helper that generates the ResultOf stuff for you. Transforms will now look like this: struct MyPrimitiveTransform : proto::transform< MyPrimitiveTransform > { // nested ternary impl<> function object: template<class Expr, class State, class Data> struct impl : proto::transform_impl<Expr, State, Data> { typedef ... result_type; result_type operator()( typename impl::expr_param expr , typename impl::state_param state , typename impl::data_param data ) const { return ...; } }; }; Doing it this way has the following advantages: * MyPrimitiveTransform is a proper TR1 function object. * When invoked as a function object, the state and data parameters are optional. (David Jenkins requested this feature.) All of Proto's primitive transforms can be defined this way, so that you'll never have to pass dummy state and data arguments. * Transforms are now lvalue/rvalue aware. That is, the Expr, State, and Data template parameters can be references. * The data object can now be const (it had to be non-const before) * The expr object can now be non-const (it had to be const before) * Because of the proper rvalue/lvalue handling, the functionality of proto::default_context can now be provided as a transform. It has a modest impact on compile times, but considering the above advantages, I think it's worth it. -- Eric Niebler Boost Consulting www.boost-consulting.com
Following up on some of Proto's review feedback ... Markus Werle wrote:
OTOH: Transforms leave me with mixed feelings. I am not very good at catching ideas without good step-by-step documentation and I got messed up with grammars vs. transforms. This part of proto is new and it looks like a candidate for rework. I'd like to have an extra review in half a year only on the grammar and transform part of proto (*)[comment below]. That's a DSEL all by itself and I guess that interface may have some pitfalls. Larry Evans has worked that out in detail.
I have been working on improving the documentation for Proto's transforms. I hope that the following is a gentler introduction. I would appreciate any feedback about it. http://tinyurl.com/5hg6ke <http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/expression_transformation.html> As with the rest of Proto's docs, it remains a work in progress. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com
participants (3)
-
Eric Niebler -
Eric Niebler -
Markus Werle