dan marsden | 18 May 00:58

Egg review result

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.

(Continue reading)

Re: Egg review result

On Sun, May 18, 2008 at 12:59 AM, dan marsden <danmarsden <at> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Daniel Walker | 19 May 16:51

Re: Egg review result

On Sat, May 17, 2008 at 7:14 PM, Giovanni Piero Deretta
<gpderetta <at> gmail.com> wrote:
> On Sun, May 18, 2008 at 12:59 AM, dan marsden <danmarsden <at> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

shunsuke | 20 May 00:52

Re: Egg review result

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Daniel Walker | 20 May 05:01

Re: Egg review result

On Mon, May 19, 2008 at 6:52 PM, shunsuke <pstade.mb <at> 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
(Continue reading)

shunsuke | 20 May 09:10

Re: Egg review result

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; }
> 
(Continue reading)

Marco Costalba | 20 May 19:11

Re: Egg review result

On Tue, May 20, 2008 at 9:10 AM, shunsuke <pstade.mb <at> 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.

(Continue reading)

shunsuke | 20 May 00:51

Re: Egg review result

dan marsden wrote:
> 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.

Sorry, after days of consideration,
I no longer believe this library is in demand enough to
impose a documentation burden on volunteers.
For whatever reason, it is clear that one review is not enough
to promote development.
So, let me postpone this proposal indefinitely.

Finally I would like to thank those who gave me feedbacks.
I'm particularly appreciative of gpd, who makes egg implementation better.

Thank you.

--

-- 
Shunsuke Sogame

Gmane