Hi All The review of the Egg library by Shunsuke Sogame has been running for 1 week now. There has been some discussion of the library on a couple of related threads, but no reviews submitted so far. Please try and find time to submit a review of this library if possible. If you wish to review, but don't have time before the review ends on April 13th, please post to that effect, we may be able to extend / move the review period to help reviewers. Introduction: It is not so easy to define Function Objects especially if you want to support Boost.ResultOf and Boost.Lambda. Therefore, as Boost provides iterator_facade and iterator adaptors, Egg provides function_facade and function adaptors. Egg provides the following features: * Workaround for the Forwarding Problem http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm * Helpers to build Function Objects: * egg::function and egg::function_facade provides the way to build Function Objects which supports Boost.ResultOf and Lambda. * Function Objects Adaptors(in other words, higher-order functions): * egg::curryN supports the currying. * egg::pipable emulates extension methods(C#). * egg::fuse/unfuse emulates variadic functions. * egg::nestN represents nested lambda expressions. * etc... The documentation is on line: http://p-stade.sourceforge.net/boost/libs/egg/ The zipped source code is in Vault/FunctionObjects: http://tinyurl.com/34lgda Tested under: Boost Development Trunk and Boost Version1.34.1. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Thanks Dan Marsden Review Manager ___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/
Hello, As you can see this is not a review. I have no doubt that Egg is an excelent candidate for a Boost library and that there are a lot of hidden diamons. I have only started to read the docummentation (the introduction adn the quick start) and for the moment I'm not sure that I will find the time to see the impementaion. The subject is really abstract and it is hard to read without stoping every two lines to se if I have realy understood. I supose that there are other boosters in the same situation. I have a little problem that could be a major one. In the documentation it is cleary state: "Also, assume that every expression is placed after: namespace egg = boost::egg; using namespace egg;" Does it means that every not prefixed symbol comes from egg? I think that it will be better to prefix every specific egg class by egg::. There are some moments that I dont't know if the used class is a egg class or a boost class. This is surely due to the fact that Egg use class or functions names already in use on Boost or the STL. This has nothing to be with the contents. I recognize that this is not natural (I'm writing now a library and I use the same style) for the writer to prefix every new symbol, but I'm sure the reader will apreciate. We shouldn't mix documentation and coding styles. I dont find too much clear the naming of Major and Little. "Function Adaptors which take Polymorphic Function Objects then return adapted ones." Could you ad to what these are adapted? "Function Objects which are ports of famous function templates." Could you explain why this is useful? I really think that the introduction do not show clearly what is the problem Egg try to solve. " Unfortunately, if you need a Polymorphic Function Object whose return type depends on its argument types, it is not easy. " I think that you should present here what can or can not be done without Egg, and show how Egg helps to do that. The section "Problems of function templates" for the "Quick Start" shoud appear in the introduction to my taste. May be you can add a 6th problem: a template cannot be passed to boost::lambda::bind as it seam from the introductuion this is a majot goal of the Egg library. maybe it would be a good idea to show hwhat the user needs to do today to pass a template to the boost::lambda::bind function and how Egg make it easier. One minor remark on the documentation. There is an incoherence on the two first pages: Portability Egg is known to work on the following platforms: a.. Microsoft Visual C++ .NET Version 7.1 SP1 b.. Microsoft Visual C++ 2005 Express Edition SP1 c.. Microsoft Visual C++ 2008 Express Edition d.. MinGW with GCC 3.4.4 e.. MinGW with GCC 4.1.2 Portability Egg is known to work on the following platforms: a.. Microsoft Visual C++ Version 7.1 or later b.. GCC 3.4.4 or later The Rationale in the Introduction seam to not add nothing interesting. Are there some missing links? I expect to have enough time to do a review, even a little one. Best _____________________ Vicente Juan Botet Escriba ----- Original Message ----- From: "dan marsden" <danmarsden@yahoo.co.uk> To: "Boost" <boost@lists.boost.org>; "Boost Announce" <boost-announce@lists.boost.org>; "Boost Users" <boost-users@lists.boost.org> Sent: Sunday, April 06, 2008 1:59 PM Subject: [boost] Egg 2nd request for reviews
Hi All
The review of the Egg library by Shunsuke Sogame has been running for 1 week now. There has been some discussion of the library on a couple of related threads, but no reviews submitted so far. Please try and find time to submit a review of this library if possible.
If you wish to review, but don't have time before the review ends on April 13th, please post to that effect, we may be able to extend / move the review period to help reviewers.
Introduction: It is not so easy to define Function Objects especially if you want to support Boost.ResultOf and Boost.Lambda. Therefore, as Boost provides iterator_facade and iterator adaptors, Egg provides function_facade and function adaptors.
Egg provides the following features:
* Workaround for the Forwarding Problem http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm
* Helpers to build Function Objects: * egg::function and egg::function_facade provides the way to build Function Objects which supports Boost.ResultOf and Lambda.
* Function Objects Adaptors(in other words, higher-order functions): * egg::curryN supports the currying. * egg::pipable emulates extension methods(C#). * egg::fuse/unfuse emulates variadic functions. * egg::nestN represents nested lambda expressions. * etc...
The documentation is on line: http://p-stade.sourceforge.net/boost/libs/egg/ The zipped source code is in Vault/FunctionObjects: http://tinyurl.com/34lgda Tested under: Boost Development Trunk and Boost Version1.34.1.
---------------------------------------------------
Please always state in your review, whether you think the library should be accepted as a Boost library!
Additionally please consider giving feedback on the following general topics:
- What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain?
Thanks
Dan Marsden Review Manager
___________________________________________________________ Yahoo! For Good helps you make a difference
http://uk.promotions.yahoo.com/forgood/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Could you tell me if the following is equivalent to what appears in the quick start. I'm not very confortable with foreach. </code> template<class Range, class Predicate> struct mono_make_filtered { typedef boost::filter_iterator< typename boost::remove_cv<Predicate>::type, typename boost::range_result_iterator<Range>::type > iter_t; typedef boost::iterator_range<iter_t> result_type; result_type operator()(Range &rng, Predicate &pred) const { return result_type( iter_t(pred, boost::begin(rng), boost::end(rng)), iter_t(pred, boost::end(rng), boost::end(rng)) ); } }; bool is_not_X(char ch) { return ch != 'X'; } bool is_not_Y(char ch) { return ch != 'Y'; } bool is_lower(char ch) { return std::islower(ch, std::locale()); } void quick_start_make_filtered() { std::string src("abXcYdXefXgYhY"); mono_make_filtered::result_type lowers = make_filtered(src, &is_lower); foreach (char ch, lowers) { std::cout << ch; } foreach (char ch, make_filtered(make_filtered(src, &is_not_X), &is_not_Y)) { std::cout << ch; } } </code> If this is the case could you show which is really the advantage to use Egg. I 'm sure there are a lot of, but I think the example do not show them. Best regards _____________________ Vicente Juan Botet Escriba ----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Sunday, April 06, 2008 6:05 PM Subject: Re: [boost] Egg 2nd request for reviews: Some comments
Hello,
As you can see this is not a review. I have no doubt that Egg is an excelent candidate for a Boost library and that there are a lot of hidden diamons.
I have only started to read the docummentation (the introduction adn the quick start) and for the moment I'm not sure that I will find the time to see the impementaion. The subject is really abstract and it is hard to read without stoping every two lines to se if I have realy understood. I supose that there are other boosters in the same situation.
I have a little problem that could be a major one. In the documentation it is cleary state: "Also, assume that every expression is placed after: namespace egg = boost::egg; using namespace egg;"
Does it means that every not prefixed symbol comes from egg? I think that it will be better to prefix every specific egg class by egg::. There are some moments that I dont't know if the used class is a egg class or a boost class. This is surely due to the fact that Egg use class or functions names already in use on Boost or the STL. This has nothing to be with the contents. I recognize that this is not natural (I'm writing now a library and I use the same style) for the writer to prefix every new symbol, but I'm sure the reader will apreciate. We shouldn't mix documentation and coding styles.
I dont find too much clear the naming of Major and Little.
"Function Adaptors which take Polymorphic Function Objects then return adapted ones." Could you ad to what these are adapted?
"Function Objects which are ports of famous function templates." Could you explain why this is useful?
I really think that the introduction do not show clearly what is the problem Egg try to solve. " Unfortunately, if you need a Polymorphic Function Object whose return type depends on its argument types, it is not easy. " I think that you should present here what can or can not be done without Egg, and show how Egg helps to do that. The section "Problems of function templates" for the "Quick Start" shoud appear in the introduction to my taste.
May be you can add a 6th problem: a template cannot be passed to boost::lambda::bind as it seam from the introductuion this is a majot goal of the Egg library. maybe it would be a good idea to show hwhat the user needs to do today to pass a template to the boost::lambda::bind function and how Egg make it easier.
One minor remark on the documentation. There is an incoherence on the two first pages: Portability Egg is known to work on the following platforms:
a.. Microsoft Visual C++ .NET Version 7.1 SP1 b.. Microsoft Visual C++ 2005 Express Edition SP1 c.. Microsoft Visual C++ 2008 Express Edition d.. MinGW with GCC 3.4.4 e.. MinGW with GCC 4.1.2
Portability Egg is known to work on the following platforms:
a.. Microsoft Visual C++ Version 7.1 or later b.. GCC 3.4.4 or later
The Rationale in the Introduction seam to not add nothing interesting. Are there some missing links?
I expect to have enough time to do a review, even a little one.
Best _____________________ Vicente Juan Botet Escriba
----- Original Message ----- From: "dan marsden" <danmarsden@yahoo.co.uk> To: "Boost" <boost@lists.boost.org>; "Boost Announce" <boost-announce@lists.boost.org>; "Boost Users" <boost-users@lists.boost.org> Sent: Sunday, April 06, 2008 1:59 PM Subject: [boost] Egg 2nd request for reviews
Hi All
The review of the Egg library by Shunsuke Sogame has been running for 1 week now. There has been some discussion of the library on a couple of related threads, but no reviews submitted so far. Please try and find time to submit a review of this library if possible.
If you wish to review, but don't have time before the review ends on April 13th, please post to that effect, we may be able to extend / move the review period to help reviewers.
Introduction: It is not so easy to define Function Objects especially if you want to support Boost.ResultOf and Boost.Lambda. Therefore, as Boost provides iterator_facade and iterator adaptors, Egg provides function_facade and function adaptors.
Egg provides the following features:
* Workaround for the Forwarding Problem http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm
* Helpers to build Function Objects: * egg::function and egg::function_facade provides the way to build Function Objects which supports Boost.ResultOf and Lambda.
* Function Objects Adaptors(in other words, higher-order functions): * egg::curryN supports the currying. * egg::pipable emulates extension methods(C#). * egg::fuse/unfuse emulates variadic functions. * egg::nestN represents nested lambda expressions. * etc...
The documentation is on line: http://p-stade.sourceforge.net/boost/libs/egg/ The zipped source code is in Vault/FunctionObjects: http://tinyurl.com/34lgda Tested under: Boost Development Trunk and Boost Version1.34.1.
---------------------------------------------------
Please always state in your review, whether you think the library should be accepted as a Boost library!
Additionally please consider giving feedback on the following general topics:
- What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain?
Thanks
Dan Marsden Review Manager
___________________________________________________________ Yahoo! For Good helps you make a difference
http://uk.promotions.yahoo.com/forgood/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
vicente.botet wrote:
Could you tell me if the following is equivalent to what appears in the quick start. I'm not very confortable with foreach.
</code> template<class Range, class Predicate> struct mono_make_filtered { typedef boost::filter_iterator< typename boost::remove_cv<Predicate>::type, typename boost::range_result_iterator<Range>::type > iter_t;
typedef boost::iterator_range<iter_t> result_type;
result_type operator()(Range &rng, Predicate &pred) const { return result_type( iter_t(pred, boost::begin(rng), boost::end(rng)), iter_t(pred, boost::end(rng), boost::end(rng)) ); } };
bool is_not_X(char ch) { return ch != 'X'; } bool is_not_Y(char ch) { return ch != 'Y'; } bool is_lower(char ch) { return std::islower(ch, std::locale()); }
void quick_start_make_filtered() { std::string src("abXcYdXefXgYhY");
mono_make_filtered::result_type lowers = make_filtered(src, &is_lower);
foreach (char ch, lowers) { std::cout << ch; }
foreach (char ch, make_filtered(make_filtered(src, &is_not_X), &is_not_Y)) { std::cout << ch; } } </code>
If this is the case could you show which is really the advantage to use Egg. I 'm sure there are a lot of, but I think the example do not show them.
No, it's not equivalent. mono_make_filtered<std::string, bool(*)(char)>::result_type lowers = ... is equivalent, though. A problem of this form is that users of `make_filtered` have to remember the usage of `mono_make_filtered` instead of the standardized metafunction `result_of`. Regards, -- Shunsuke Sogame
I think that I start to understand. _____________________ Vicente Juan Botet Escriba ----- Original Message ----- From: "shunsuke" <pstade.mb@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, April 06, 2008 8:55 PM Subject: Re: [boost] Egg 2nd request for reviews: Some comments
vicente.botet wrote:
Could you tell me if the following is equivalent to what appears in the quick start. I'm not very confortable with foreach.
</code> template<class Range, class Predicate> struct mono_make_filtered { typedef boost::filter_iterator< typename boost::remove_cv<Predicate>::type, typename boost::range_result_iterator<Range>::type > iter_t;
typedef boost::iterator_range<iter_t> result_type;
result_type operator()(Range &rng, Predicate &pred) const { return result_type( iter_t(pred, boost::begin(rng), boost::end(rng)), iter_t(pred, boost::end(rng), boost::end(rng)) ); } };
bool is_not_X(char ch) { return ch != 'X'; } bool is_not_Y(char ch) { return ch != 'Y'; } bool is_lower(char ch) { return std::islower(ch, std::locale()); }
void quick_start_make_filtered() { std::string src("abXcYdXefXgYhY");
mono_make_filtered::result_type lowers = make_filtered(src, &is_lower);
foreach (char ch, lowers) { std::cout << ch; }
foreach (char ch, make_filtered(make_filtered(src, &is_not_X), &is_not_Y)) { std::cout << ch; } } </code>
If this is the case could you show which is really the advantage to use Egg. I 'm sure there are a lot of, but I think the example do not show them.
No, it's not equivalent. mono_make_filtered<std::string, bool(*)(char)>::result_type lowers = ... is equivalent, though. A problem of this form is that users of `make_filtered` have to remember the usage of `mono_make_filtered` instead of the standardized metafunction `result_of`.
Regards,
-- Shunsuke Sogame
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi again, In the Quick start, I found this use of macros very odd egg::result_of_pipable<T_make_filtered>::type const filtered = BOOST_EGG_PIPABLE_L BOOST_EGG_POLY() BOOST_EGG_PIPABLE_R; egg::result_of_pipable< egg::result_of_indirect<T_make_filtered const *>::type
::type const her_filtered = BOOST_EGG_PIPABLE_L BOOST_EGG_INDIRECT(&make_filtered) BOOST_EGG_PIPABLE_R;
Could you show what a user that do not use the macros needs to write. This will surely help to understand why these macros a necessary. It would be very nice if the docummentation contains links for the macros the same way you have done for the specific notation. By the way I fond this link to specific notation very useful. Thanks for the trick. I have no doubt that the use of bind expressions may be less readable than: void quick_start_nest() { int i6 = 6, i7 = 7; std::plus<int> plus; std::minus<int> minus; int r = // Lv: 0 1 2 // \x -> (\(y,z) -> plus(5, y(z, x))) egg::nest2(plus)(5, egg::nest2(_1_(_1))(_1_(_2), _0_(_1))) (i6)(minus, i7); std::cout << r; } Prints 6. But, do you really think that some one is able to read this without taking 5 minutes :-(. I think that you should start with more simple examples, showing only a new feature and comparing with code without Egg. I like a lot your fuse/unfuse technique for emulating variadic functions. Only this is enough to see in the implementation. On the section The Return of the Monomorphic It would be greate to see the compiler messages with and without Egg. Best ____________________ Vicente Juan Botet Escriba ----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Sunday, April 06, 2008 6:05 PM Subject: Re: [boost] Egg 2nd request for reviews: Some comments
Hello,
As you can see this is not a review. I have no doubt that Egg is an excelent candidate for a Boost library and that there are a lot of hidden diamons.
I have only started to read the docummentation (the introduction adn the quick start) and for the moment I'm not sure that I will find the time to see the impementaion. The subject is really abstract and it is hard to read without stoping every two lines to se if I have realy understood. I supose that there are other boosters in the same situation.
I have a little problem that could be a major one. In the documentation it is cleary state: "Also, assume that every expression is placed after: namespace egg = boost::egg; using namespace egg;"
Does it means that every not prefixed symbol comes from egg? I think that it will be better to prefix every specific egg class by egg::. There are some moments that I dont't know if the used class is a egg class or a boost class. This is surely due to the fact that Egg use class or functions names already in use on Boost or the STL. This has nothing to be with the contents. I recognize that this is not natural (I'm writing now a library and I use the same style) for the writer to prefix every new symbol, but I'm sure the reader will apreciate. We shouldn't mix documentation and coding styles.
I dont find too much clear the naming of Major and Little.
"Function Adaptors which take Polymorphic Function Objects then return adapted ones." Could you ad to what these are adapted?
"Function Objects which are ports of famous function templates." Could you explain why this is useful?
I really think that the introduction do not show clearly what is the problem Egg try to solve. " Unfortunately, if you need a Polymorphic Function Object whose return type depends on its argument types, it is not easy. " I think that you should present here what can or can not be done without Egg, and show how Egg helps to do that. The section "Problems of function templates" for the "Quick Start" shoud appear in the introduction to my taste.
May be you can add a 6th problem: a template cannot be passed to boost::lambda::bind as it seam from the introductuion this is a majot goal of the Egg library. maybe it would be a good idea to show hwhat the user needs to do today to pass a template to the boost::lambda::bind function and how Egg make it easier.
One minor remark on the documentation. There is an incoherence on the two first pages: Portability Egg is known to work on the following platforms:
a.. Microsoft Visual C++ .NET Version 7.1 SP1 b.. Microsoft Visual C++ 2005 Express Edition SP1 c.. Microsoft Visual C++ 2008 Express Edition d.. MinGW with GCC 3.4.4 e.. MinGW with GCC 4.1.2
Portability Egg is known to work on the following platforms:
a.. Microsoft Visual C++ Version 7.1 or later b.. GCC 3.4.4 or later
The Rationale in the Introduction seam to not add nothing interesting. Are there some missing links?
I expect to have enough time to do a review, even a little one.
Best _____________________ Vicente Juan Botet Escriba
----- Original Message ----- From: "dan marsden" <danmarsden@yahoo.co.uk> To: "Boost" <boost@lists.boost.org>; "Boost Announce" <boost-announce@lists.boost.org>; "Boost Users" <boost-users@lists.boost.org> Sent: Sunday, April 06, 2008 1:59 PM Subject: [boost] Egg 2nd request for reviews
Hi All
The review of the Egg library by Shunsuke Sogame has been running for 1 week now. There has been some discussion of the library on a couple of related threads, but no reviews submitted so far. Please try and find time to submit a review of this library if possible.
If you wish to review, but don't have time before the review ends on April 13th, please post to that effect, we may be able to extend / move the review period to help reviewers.
Introduction: It is not so easy to define Function Objects especially if you want to support Boost.ResultOf and Boost.Lambda. Therefore, as Boost provides iterator_facade and iterator adaptors, Egg provides function_facade and function adaptors.
Egg provides the following features:
* Workaround for the Forwarding Problem http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm
* Helpers to build Function Objects: * egg::function and egg::function_facade provides the way to build Function Objects which supports Boost.ResultOf and Lambda.
* Function Objects Adaptors(in other words, higher-order functions): * egg::curryN supports the currying. * egg::pipable emulates extension methods(C#). * egg::fuse/unfuse emulates variadic functions. * egg::nestN represents nested lambda expressions. * etc...
The documentation is on line: http://p-stade.sourceforge.net/boost/libs/egg/ The zipped source code is in Vault/FunctionObjects: http://tinyurl.com/34lgda Tested under: Boost Development Trunk and Boost Version1.34.1.
---------------------------------------------------
Please always state in your review, whether you think the library should be accepted as a Boost library!
Additionally please consider giving feedback on the following general topics:
- What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain?
Thanks
Dan Marsden Review Manager
___________________________________________________________ Yahoo! For Good helps you make a difference
http://uk.promotions.yahoo.com/forgood/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
vicente.botet wrote:
Hi again,
In the Quick start, I found this use of macros very odd
egg::result_of_pipable<T_make_filtered>::type const filtered = BOOST_EGG_PIPABLE_L BOOST_EGG_POLY() BOOST_EGG_PIPABLE_R;
egg::result_of_pipable< egg::result_of_indirect<T_make_filtered const *>::type
::type const her_filtered = BOOST_EGG_PIPABLE_L BOOST_EGG_INDIRECT(&make_filtered) BOOST_EGG_PIPABLE_R;
Could you show what a user that do not use the macros needs to write. This will surely help to understand why these macros a necessary.
It was really odd. Fortunately, in a recent discussion, it is shown that those macros can be removed with a trivial patch. A newly proposed form is: egg::static_< result_of<T_pipable(T_make_filtered)> >::type const filtered = {{}}; How do you think about this form?
It would be very nice if the docummentation contains links for the macros the same way you have done for the specific notation.
By the way I fond this link to specific notation very useful. Thanks for the trick.
Thanks.
I have no doubt that the use of bind expressions may be less readable than: void quick_start_nest() { int i6 = 6, i7 = 7; std::plus<int> plus; std::minus<int> minus;
int r = // Lv: 0 1 2 // \x -> (\(y,z) -> plus(5, y(z, x))) egg::nest2(plus)(5, egg::nest2(_1_(_1))(_1_(_2), _0_(_1))) (i6)(minus, i7);
std::cout << r; } Prints 6.
But, do you really think that some one is able to read this without taking 5 minutes :-(. I think that you should start with more simple examples, showing only a new feature and comparing with code without Egg.
nestN was invented just two weeks ago. I must admit less explanation. And a simple example will be added with a comparison. (Maybe I wanted to show this feature to lambda library authors.)
I like a lot your fuse/unfuse technique for emulating variadic functions. Only this is enough to see in the implementation.
Ok.
On the section The Return of the Monomorphic It would be greate to see the compiler messages with and without Egg.
I will. Regards, -- Shunsuke Sogame
----- Original Message ----- From: "shunsuke" <pstade.mb@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, April 06, 2008 9:10 PM Subject: Re: [boost] Egg 2nd request for reviews: Some comments
vicente.botet wrote:
Hi again,
In the Quick start, I found this use of macros very odd
egg::result_of_pipable<T_make_filtered>::type const filtered = BOOST_EGG_PIPABLE_L BOOST_EGG_POLY() BOOST_EGG_PIPABLE_R;
egg::result_of_pipable< egg::result_of_indirect<T_make_filtered const *>::type
::type const her_filtered = BOOST_EGG_PIPABLE_L BOOST_EGG_INDIRECT(&make_filtered) BOOST_EGG_PIPABLE_R;
Could you show what a user that do not use the macros needs to write. This will surely help to understand why these macros a necessary.
It was really odd. Fortunately, in a recent discussion, it is shown that those macros can be removed with a trivial patch. A newly proposed form is:
egg::static_< result_of<T_pipable(T_make_filtered)> >::type const filtered = {{}};
How do you think about this form?
Well, there are no more macros, this is much better for me.. Sorry, I have missed the post. Could you give me the reference to this discussion?
It would be very nice if the docummentation contains links for the macros the same way you have done for the specific notation.
By the way I fond this link to specific notation very useful. Thanks for the trick.
Thanks.
I have no doubt that the use of bind expressions may be less readable than: void quick_start_nest() { int i6 = 6, i7 = 7; std::plus<int> plus; std::minus<int> minus;
int r = // Lv: 0 1 2 // \x -> (\(y,z) -> plus(5, y(z, x))) egg::nest2(plus)(5, egg::nest2(_1_(_1))(_1_(_2), _0_(_1))) (i6)(minus, i7);
std::cout << r; } Prints 6.
But, do you really think that some one is able to read this without taking 5 minutes :-(. I think that you should start with more simple examples, showing only a new feature and comparing with code without Egg.
nestN was invented just two weeks ago. I must admit less explanation. And a simple example will be added with a comparison. (Maybe I wanted to show this feature to lambda library authors.)
I like a lot your fuse/unfuse technique for emulating variadic functions. Only this is enough to see in the implementation.
Ok.
On the section The Return of the Monomorphic It would be greate to see the compiler messages with and without Egg.
I will.
Regards,
-- Shunsuke Sogame
Best regards _____________________ Vicente Juan Botet Escriba
vicente.botet wrote:
Could you show what a user that do not use the macros needs to write. This will surely help to understand why these macros a necessary. It was really odd. Fortunately, in a recent discussion, it is shown that those macros can be removed with a trivial patch. A newly proposed form is:
egg::static_< result_of<T_pipable(T_make_filtered)> >::type const filtered = {{}};
How do you think about this form?
Well, there are no more macros, this is much better for me.. Sorry, I have missed the post. Could you give me the reference to this discussion?
See this thread: http://lists.boost.org/Archives/boost/2008/03/135317.php Regards, -- Shunsuke Sogame
vicente.botet wrote:
Hello,
As you can see this is not a review. I have no doubt that Egg is an excelent candidate for a Boost library and that there are a lot of hidden diamons.
Thanks.
I have only started to read the docummentation (the introduction adn the quick start) and for the moment I'm not sure that I will find the time to see the impementaion. The subject is really abstract and it is hard to read without stoping every two lines to se if I have realy understood. I supose that there are other boosters in the same situation.
It is mainly because of my broken english. I'm still updating Egg document in local everyday to make it better.
I have a little problem that could be a major one. In the documentation it is cleary state: "Also, assume that every expression is placed after: namespace egg = boost::egg; using namespace egg;"
Does it means that every not prefixed symbol comes from egg? I think that it will be better to prefix every specific egg class by egg::. There are some moments that I dont't know if the used class is a egg class or a boost class. This is surely due to the fact that Egg use class or functions names already in use on Boost or the STL. This has nothing to be with the contents. I recognize that this is not natural (I'm writing now a library and I use the same style) for the writer to prefix every new symbol, but I'm sure the reader will apreciate. We shouldn't mix documentation and coding styles.
I will add `egg::` everywhere. The same thing was requested in Proto review, IIRC.
I dont find too much clear the naming of Major and Little.
Those come from Baseball: Little league(where children play) and Major league(where professionals play). I will add this explanation.
"Function Adaptors which take Polymorphic Function Objects then return adapted ones." Could you ad to what these are adapted?
"Function Objects which are ports of famous function templates." Could you explain why this is useful?
I really think that the introduction do not show clearly what is the problem Egg try to solve. " Unfortunately, if you need a Polymorphic Function Object whose return type depends on its argument types, it is not easy. " I think that you should present here what can or can not be done without Egg, and show how Egg helps to do that. The section "Problems of function templates" for the "Quick Start" shoud appear in the introduction to my taste.
I'm inclined to unify "Introduction" and "Quick Start" with more clarified sentences.
May be you can add a 6th problem: a template cannot be passed to boost::lambda::bind as it seam from the introductuion this is a majot goal of the Egg library. maybe it would be a good idea to show hwhat the user needs to do today to pass a template to the boost::lambda::bind function and how Egg make it easier.
I will add "FAQ" which has been asked many times by users in mailing-lists.
One minor remark on the documentation. There is an incoherence on the two first pages: Portability Egg is known to work on the following platforms:
a.. Microsoft Visual C++ .NET Version 7.1 SP1 b.. Microsoft Visual C++ 2005 Express Edition SP1 c.. Microsoft Visual C++ 2008 Express Edition d.. MinGW with GCC 3.4.4 e.. MinGW with GCC 4.1.2
Portability Egg is known to work on the following platforms:
a.. Microsoft Visual C++ Version 7.1 or later b.. GCC 3.4.4 or later
I wanted to make "Quick Start" quick. :-) But it is really an incoherence. It should be fixed.
The Rationale in the Introduction seam to not add nothing interesting. Are there some missing links?
No. Maybe I should move it to a more elaborate section.
I expect to have enough time to do a review, even a little one.
I hope so. Thanks! Regards, -- Shunsuke Sogame
Hi, thanks for your QUICK answer :-) ----- Original Message ----- From: "shunsuke" <pstade.mb@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, April 06, 2008 8:40 PM Subject: Re: [boost] Egg 2nd request for reviews: Some comments
vicente.botet wrote:
Hello,
As you can see this is not a review. I have no doubt that Egg is an excelent candidate for a Boost library and that there are a lot of hidden diamons.
Thanks.
I have only started to read the docummentation (the introduction adn the quick start) and for the moment I'm not sure that I will find the time to see the impementaion. The subject is really abstract and it is hard to read without stoping every two lines to se if I have realy understood. I supose that there are other boosters in the same situation.
It is mainly because of my broken english.
Your english is very good.
I'm still updating Egg document in local everyday to make it better.
I have a little problem that could be a major one. In the documentation it is cleary state: "Also, assume that every expression is placed after: namespace egg = boost::egg; using namespace egg;"
Does it means that every not prefixed symbol comes from egg? I think that it will be better to prefix every specific egg class by egg::. There are some moments that I dont't know if the used class is a egg class or a boost class. This is surely due to the fact that Egg use class or functions names already in use on Boost or the STL. This has nothing to be with the contents. I recognize that this is not natural (I'm writing now a library and I use the same style) for the writer to prefix every new symbol, but I'm sure the reader will apreciate. We shouldn't mix documentation and coding styles.
I will add `egg::` everywhere. The same thing was requested in Proto review, IIRC.
Greate, I'm sure that this will clarify the documentation.
I dont find too much clear the naming of Major and Little.
Those come from Baseball: Little league(where children play) and Major league(where professionals play). I will add this explanation.
I need to continue reading the documentation.
"Function Adaptors which take Polymorphic Function Objects then return adapted ones." Could you ad to what these are adapted?
"Function Objects which are ports of famous function templates." Could you explain why this is useful?
I really think that the introduction do not show clearly what is the problem Egg try to solve. " Unfortunately, if you need a Polymorphic Function Object whose return type depends on its argument types, it is not easy. " I think that you should present here what can or can not be done without Egg, and show how Egg helps to do that. The section "Problems of function templates" for the "Quick Start" shoud appear in the introduction to my taste.
I'm inclined to unify "Introduction" and "Quick Start" with more clarified sentences.
May be you can add a 6th problem: a template cannot be passed to boost::lambda::bind as it seam from the introductuion this is a majot goal of the Egg library. maybe it would be a good idea to show hwhat the user needs to do today to pass a template to the boost::lambda::bind function and how Egg make it easier.
I will add "FAQ" which has been asked many times by users in mailing-lists.
I think that you can add this kind of issues on a tutorial.
One minor remark on the documentation. There is an incoherence on the two first pages: Portability Egg is known to work on the following platforms:
a.. Microsoft Visual C++ .NET Version 7.1 SP1 b.. Microsoft Visual C++ 2005 Express Edition SP1 c.. Microsoft Visual C++ 2008 Express Edition d.. MinGW with GCC 3.4.4 e.. MinGW with GCC 4.1.2
Portability Egg is known to work on the following platforms:
a.. Microsoft Visual C++ Version 7.1 or later b.. GCC 3.4.4 or later
I wanted to make "Quick Start" quick. :-) But it is really an incoherence. It should be fixed.
The Rationale in the Introduction seam to not add nothing interesting. Are there some missing links?
No. Maybe I should move it to a more elaborate section.
I expect to have enough time to do a review, even a little one.
I hope so. Thanks!
Regards,
-- Shunsuke Sogame
Best _____________________ Vicente Juan Botet Escriba
On Sun, Apr 6, 2008 at 1:59 PM, dan marsden <danmarsden@yahoo.co.uk> wrote:
Hi All
The review of the Egg library by Shunsuke Sogame has been running for 1 week now. There has been some discussion of the library on a couple of related threads, but no reviews submitted so far. Please try and find time to submit a review of this library if possible.
If you wish to review, but don't have time before the review ends on April 13th, please post to that effect, we may be able to extend / move the review period to help reviewers.
Hi, as you may know, me and Shunsuke Sogame had a very fruitful discussion on egg. I was going to finally write a review for today, but I realized that, even if I have extensively analyzed the documentation, I haven't actually tried it. If there is a possibility to extend the review period of another week, I'll take sometime to try the library, possibly with different compilers. This may also let other boosters have time write their own review (even if strangely so far no one else seems to have shown interest). If you think that the review should still end the 13th, I'll wrap up a review for today. -- gpd
On Fri, Apr 11, 2008 at 11:12 AM, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
If there is a possibility to extend the review period of another week, I'll take sometime to try the library, possibly with different compilers. This may also let other boosters have time write their own review (even if strangely so far no one else seems to have shown interest).
If you think that the review should still end the 13th, I'll wrap up a review for today.
Ditto. I have an interest in the problem domain Egg addresses, and from what I've read, I like Shunsuke's approach. But I'm just now sitting down to take a real look at it. I can wrap up a review today, but if you don't mind extending the review period, I think the discussion could benefit from more time. Thanks, Daniel Walker
participants (5)
-
dan marsden -
Daniel Walker -
Giovanni Piero Deretta -
shunsuke -
vicente.botet