This is a summary of the review of the Egg library by Shunsuke Sogame. The main issue with this review was the low number of reviews submitted, despite a reasonable amount of discussion on the list. In total only 1 review was received, from Giovanni Piero Deretta. This review was a yes vote, contingent on a mini review of improved documentation. Given this extremely low review count, unfortunately Egg cannot be accepted into Boost at this time. The remainder of this summary will cover some of the themes relating to lack of reviews, and also other highlights of the review. I'll start with some positive notes. Several comments on the list suggested that functionality in Egg was wanted by users, and that they would like to see Egg in Boost in some form in the future. Several writers also pointed out the high quality of the implementation of Egg, and technical issues were not really a focus of the discussions. During discussions on the developer several reviewers comments on the quality / style of the documentation for Egg. Motivation seemed to be a big issue in these comments, questions of the form "why should I use Egg versus Boost.XXX" were common. There typically were good reasons to use Egg, but these were not apparent to readers of the documentation. A related issue that cropped up was the sheer scale of Egg, one potential review was withdrawn as the scale of Egg was so large that the reviewer felt he could not do it justice. A couple of reviews pointed out that the documentation could be hard to follow, sometimes as the assumed expertise of the readers was possibly too high, and also for other reasons, such as the __ prefixed notation used in a lot of the documentation. Both Giovanni and Daniel Walker generously offered to provide assistance with the documentation for Egg. Joel de Guzman pointed out that that the timing of the review was poor, as it was in the immediate run up to Boostcon, and many potential reviewers would be busy with preparation for that event. This comment was supported by several people I discussed this with at Boostcon. There was much incredibly detailed technical discussion, which I cannot do justice to here. Those interested will be able to find the discussion on the mailing list archives. In summary I believe key points of the review were: * The number of reviews was insufficient to accept the library in its current form. This seemed to be due to documentation issues making reviews difficult, and the poor timing of the review before Boostcon. * The library was of high technical quality, and the functionality was needed by Boost users in some form. * Documentation issues would definitely need to be addressed before the library could be satisfactorily reviewed and accepted into Boost. I'd like to thank Shunsuke Sogame for submitting the library, and the hard work that he has put in so far. I'd like to encourage him to continue his efforts, and to take up the offers of assistance with documentation if he feels it appropriate. I personally would like to see many parts of Egg in Boost in some form in the future, and other reviewers seemed to agree. I would also like to thank the reviewer, and the many people that contributed discussion on the list, hopefully this will lead to an improved Egg returning in future. Thanks Dan Marsden Review Manager __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
On Sun, May 18, 2008 at 12:59 AM, dan marsden <danmarsden@yahoo.co.uk> wrote:
This is a summary of the review of the Egg library by Shunsuke Sogame. [...] * The number of reviews was insufficient to accept the library in its current form. This seemed to be due to documentation issues making reviews difficult, and the poor timing of the review before Boostcon.
I really hope that Shunsuke will resubmit the library again. Hopefully not at the same time of next Boostcon, so that we can get more reviews :)
* The library was of high technical quality, and the functionality was needed by Boost users in some form.
Definitely!
* Documentation issues would definitely need to be addressed before the library could be satisfactorily reviewed and accepted into Boost.
I volunteer again to help with the documentation. -- gpd
On Sat, May 17, 2008 at 7:14 PM, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
On Sun, May 18, 2008 at 12:59 AM, dan marsden <danmarsden@yahoo.co.uk> wrote:
* Documentation issues would definitely need to be addressed before the library could be satisfactorily reviewed and accepted into Boost.
I volunteer again to help with the documentation.
Me too! But perhaps more important than the documentation, I think there could be a lot of beneficial synergy between Egg, and the discussions arising from Marco's multi-signature function. Egg is addressing a somewhat higher level problem than the problem of accommodating builtin functions along with polymorphic function objects, but it seems to me that there's still some overlap. For example, how cool would it be if you could defer builtin functions to use them with fusion? With a little work, parts of Egg could feel right at home in a library that offered this sort of functionality. This combination could be much better than just Egg on it's own - strip out some of Egg's less compelling features and fold what's left into a new project with Marco and I - the whole could be greater than the sum of its parts! Daniel Walker
Daniel Walker wrote:
But perhaps more important than the documentation, I think there could be a lot of beneficial synergy between Egg, and the discussions arising from Marco's multi-signature function. Egg is addressing a somewhat higher level problem than the problem of accommodating builtin functions along with polymorphic function objects, but it seems to me that there's still some overlap. For example, how cool would it be if you could defer builtin functions to use them with fusion? With a little work, parts of Egg could feel right at home in a library that offered this sort of functionality. This combination could be much better than just Egg on it's own - strip out some of Egg's less compelling features and fold what's left into a new project with Marco and I - the whole could be greater than the sum of its parts!
Egg experimentally contained a multi-signature function adaptor. Here is an example: http://tinyurl.com/68luzd It doesn't perform type-erasure, so I'm not sure there is an overlap. Regards, -- Shunsuke Sogame
On Mon, May 19, 2008 at 6:52 PM, shunsuke <pstade.mb@gmail.com> wrote:
Daniel Walker wrote:
But perhaps more important than the documentation, I think there could be a lot of beneficial synergy between Egg, and the discussions arising from Marco's multi-signature function. Egg is addressing a somewhat higher level problem than the problem of accommodating builtin functions along with polymorphic function objects, but it seems to me that there's still some overlap. For example, how cool would it be if you could defer builtin functions to use them with fusion? With a little work, parts of Egg could feel right at home in a library that offered this sort of functionality. This combination could be much better than just Egg on it's own - strip out some of Egg's less compelling features and fold what's left into a new project with Marco and I - the whole could be greater than the sum of its parts!
Egg experimentally contained a multi-signature function adaptor. Here is an example: http://tinyurl.com/68luzd It doesn't perform type-erasure, so I'm not sure there is an overlap.
I looked at it briefly and noticed the term overload_set showed up in your implementation as well. I think this must be a recurring pattern - some sort of on-fly set of closely related functions differentiated by their argument types and arity. Also, I noticed we both came up with a similar way of representing the signatures of polymorphic function objects using result_of-style signatures with mpl::placeholders! That has got to be a good sign! The difference is that your Egg-based version cannot handle arbitrary callable objects (builtins as well as function objects). Also, I didn't notice that you have any mechanism for switching out the overloads - an insertion or assignment operation, something more set-like than function-like. I'd like to see us move towards something along the lines of the following, and I think we're getting there. template<class T> T f(T t) { return t; } struct g { template<class> struct result; template<class T> struct result<g(T)> { typedef T type; }; T operator(T t) { return t; } }; overload_set<char(char), int(int), g(_1)> h; h.insert(&f<char>); // type-erasure bound to int(int) h.insert(function<int(int)>(g())); // polymorphic g bound to g(_1) h.insert(g()); // rebind int(int) to f h.insert(&f<int>); // dispatch to the various overloads h('a'); h(0); h("foo"); I have a polymorphic_function (well, I have the boilerplate for a unary version in an attachment on another thread; I'm Boost.Preprocessor metaprogramming the nary version now.), which takes care of promoting the builtins and interpreting both boost::function-style call signatures and result_of-style "polymorphic" signatures with placeholders. overload_set can be built on top of it. I'm not sure that your version can help with this because it seems to be tightly bound to the whole Egg framework. However, it would be nice if overload_set could work with fusion, lambda, etc. out-of-the-box, and I believe Egg has ways of doing that. Could that functionality be made accessible without having the whole framework piggybacking along? Other thoughts? Daniel Walker
Daniel Walker wrote:
Egg experimentally contained a multi-signature function adaptor. Here is an example: http://tinyurl.com/68luzd It doesn't perform type-erasure, so I'm not sure there is an overlap.
I looked at it briefly and noticed the term overload_set showed up in your implementation as well. I think this must be a recurring pattern - some sort of on-fly set of closely related functions differentiated by their argument types and arity. Also, I noticed we both came up with a similar way of representing the signatures of polymorphic function objects using result_of-style signatures with mpl::placeholders! That has got to be a good sign!
egg::overload makes use of placeholders for argument pattern matching. It doesn't mean any signature.
The difference is that your Egg-based version cannot handle arbitrary callable objects (builtins as well as function objects).
Egg works with result_of protocol, which supports function-pointers.
Also, I didn't notice that you have any mechanism for switching out the overloads - an insertion or assignment operation, something more set-like than function-like. I'd like to see us move towards something along the lines of the following, and I think we're getting there.
template<class T> T f(T t) { return t; }
struct g { template<class> struct result; template<class T> struct result<g(T)> { typedef T type; }; T operator(T t) { return t; } };
overload_set<char(char), int(int), g(_1)> h; h.insert(&f<char>);
// type-erasure bound to int(int) h.insert(function<int(int)>(g()));
// polymorphic g bound to g(_1) h.insert(g());
BTW, what if `g(_1)` means templated function returning `g` type?
// rebind int(int) to f h.insert(&f<int>);
// dispatch to the various overloads h('a'); h(0); h("foo");
I have a polymorphic_function (well, I have the boilerplate for a unary version in an attachment on another thread; I'm Boost.Preprocessor metaprogramming the nary version now.), which takes care of promoting the builtins and interpreting both boost::function-style call signatures and result_of-style "polymorphic" signatures with placeholders. overload_set can be built on top of it. I'm not sure that your version can help with this because it seems to be tightly bound to the whole Egg framework. However, it would be nice if overload_set could work with fusion, lambda, etc. out-of-the-box, and I believe Egg has ways of doing that. Could that functionality be made accessible without having the whole framework piggybacking along? Other thoughts?
I'm reading that thread. The motivation and role seems different. For example, struct IfInt { ... }; // a function object type struct Otherwise { ... }; // a function object type /* It is cumbersome to write down something like this: struct F_ { void operator()(int x) { IfInt()(x); }; void operator()(any x) { Otherwise()(x); }; }; */ // Hence, Egg provides a helper to build overloaded function in one shot. static_<result_of_overload<IfInt(int), Otherwise(_)>::type>::type const f = {{}}; // BTW, f is empty. // Now, if type-erasure is needed..., multi_signature_function<void(int), void(double)> msf = f; Egg doesn't touch a job of multi_signature_function. In fact, I've never used anything like multi_signature_function, so, I probably can't advise you. As suggested, I feel container-like behavior is not a job of multi_signature_function, though. Regards, -- Shunsuke Sogame
On Tue, May 20, 2008 at 9:10 AM, shunsuke <pstade.mb@gmail.com> wrote:
struct g { template<class> struct result; template<class T> struct result<g(T)> { typedef T type; }; T operator(T t) { return t; } };
This is a good poly wrapper start. It would be real generic it if was: struct g { template<class> struct result; template<class T> struct result<g(T)> { typedef T type; }; T operator(T t) { return bounded_poly_functor(t); } }; where bounded_poly_functor is what is assigned to the overload_set with operator=(), or insert() as you called it.
overload_set<char(char), int(int), g(_1)> h;
If the 'g' was a real wrapper you don't need to explicit write in overload_set template parameters as long as you don't need to explicit write boost::function wrapper type in normal cases.
h.insert(&f<char>);
The above is really the key of all this stuff. If you are able to do that then perhaps poly wrapper is more real then what I have supposed. Just tho be clear, I imagine that after the above instruction bounded_poly_functor variable becomes 'f' or something similar (read a pointer) to 'f'
// type-erasure bound to int(int) h.insert(function<int(int)>(g()));
This is useless IMHO if 'g' it's just a poly wrapper. I think the key point that is still not completely clear to me is to understand if you think that g() has some functionality apart from forwarding arguments or it's just a wrapper as boost::function is a wrapper for normal functions.
// polymorphic g bound to g(_1) h.insert(g());
BTW, what if `g(_1)` means templated function returning `g` type?
That's very natural. For this reason and because g would be supposed to be by just a wrapper with no functionality but forwarding arguments a better naming IMHO could be _1(_1) where the first _1 is the return type, or a standard name like egg:poly_wapper(_1) or msf::polymorphic(_1). Just examples.
I'm reading that thread. The motivation and role seems different. For example,
struct IfInt { ... }; // a function object type struct Otherwise { ... }; // a function object type
/* It is cumbersome to write down something like this: struct F_ { void operator()(int x) { IfInt()(x); }; void operator()(any x) { Otherwise()(x); }; }; */ // Hence, Egg provides a helper to build overloaded function in one shot. static_<result_of_overload<IfInt(int), Otherwise(_)>::type>::type const f = {{}}; // BTW, f is empty.
Yes. I agree this is different. In your case you pass real functionality in result_of_overload<> template parameters, because IfInt and Otherwise do something. Instead, if I have undersood correctly Daniel, 'g', as he called it, should be just a wrapper, an argument forwarder. It doesn't even need to be explicit in the template a parameters.
As suggested, I feel container-like behavior is not a job of multi_signature_function, though.
I would feel the same... Thanks Marco
participants (5)
-
dan marsden -
Daniel Walker -
Giovanni Piero Deretta -
Marco Costalba -
shunsuke