Re: [boost] Egg review period extended until April 20th

From: shunsuke (pstade.mb_at_[hidden])
Date: 2008-04-15 01:35:37

Daniel Walker wrote:
 > OK, I still don't want to give a formal review, because I haven't
 > looked at the whole library and I don't want to be unfair. However, I
 > sent some comments off-list to Shunsuke, and he asked me to post them
 > here. As he pointed out to me, it's the Boost way! :-)

Thank you, Daniel.

 > I really do think that Egg is technologically solid. If the list is
 > slow to show interest, I think that's not a reflection of some
 > technical concern, but perhaps it's a sign of usability hurdles... In
 > other words, how do you convince users that using the library would
 > make their lives easier? How do you sell the library?

I probably failed to sell the library.

 > Approaching the library for the first time, as a new user as much as a
 > potential reviewer, it seemed to me that Egg overlaps a great deal
 > with existing Boost libraries and with C++0x. I constantly found
 > myself asking: "Why would I want to learn this? Can't I just use bind?

egg::lazy is useful.
`lazy_plus(lazy_plus(_1, 3), lazy_plus(_2, _1))` is much more
readable than an expression using bind.

 > Yes, this is better than writing a function, but how is this any
 > better than just writing a class with operator()?" That last question
 > was the show stopper for me;

It depends on some conditions:
   * C++0x is available for you?
   * Your FunctionObject should be Polymorphic?

 > I don't have the time, energy or
 > inclination to learn a new paradigm for writing functors unless there
 > is a strong motivating need or big potential payoff. Remember,
 > fundamentally, the raison d'etre of Boost is to increase productivity.
 > At least, that's what the FAQ says. ;-) And in reality, if this wasn't
 > the case, no one would have ever started using Boost, it wouldn't be
 > famous today, and there would be no demand for Boost libraries to be
 > adopted into the standard. It's because of the Boost libraries' great
 > utility that they're so widely employed and admired.

According to my experience, directly or indirectly,
Egg has been increasing productivity.
FWIW, Egg is used to implement a Range Library:
   http://p-stade.sourceforge.net/oven/index.html

 > Each of the Egg components are interesting, but how are they helpful?
 > The name 'Egg' is a great example of what I'm talking about. It's an
 > interesting name, but I can't tell from the name how the library would
 > be useful to me.

"egg" didn't show a bad impression in [interest] phase,
so I kept the name.

 > The same is true for many of Egg's "selling points,"
 > for lack of a better term. For example, static initialization is
 > interesting, but in the highly unusual circumstance where I would find
 > myself using global or static objects of any sort (let alone
 > functors), I can already write "const my_functor f = my_functor()" and
 > most modern compilers will optimize away any significant run time
 > overhead. Also, as I understand it, supporting list initialization
 > does nothing to help the initialization order fiasco. That problem is
 > solved by avoiding constructor dependencies between static objects,
 > regardless of what sort of constructor they're built with. If I'm
 > wrong about these points, Shunsuke, you may want to make a
 > stronger/clearer explanation of the feature in the documentation. But
 > it could be that global/static functors are such an obscure use-case
 > that potential users simply won't care one way or the other. What
 > might be useful is to have some sort of global object manager, but
 > that's a different library, call it Boost.GOM ;-), and that doesn't
 > directly relate to functional programming.

I actually thought so.
(The old Egg supported only dynamic-initialization.)
I was upset when I saw a document about static-initialization in Proto.
I quote this: http://lists.boost.org/Archives/boost/2008/04/135452.php

 > Not that Egg shouldn't have a static initialization feature; it's just
 > to say that static initialization may not be a compelling selling
 > point. The same is true for the forwarding problem workarounds. The
 > by_ref strategy simply means passing arguments by reference, by_cref
 > means by const reference, etc. That's such a simple idea that it seems
 > convoluted to wrap it in some framework of forwarding strategies. I
 > just don't understand what it buys me. Whatever happened to
 > boost::call_traits? Would the forwarding strategies find a better home
 > there? Or are they really more of a backend detail? Maybe they should
 > be put in a special "Advanced Features" section of the documentation
 > for "power users." Either way, I don't feel like it's an attractive
 > selling point; to me it made me feel as if Egg requires you to jump
 > through hoops to do a simple thing like change function parameters
 > from refs to const refs.

I actually noted "You can skip reading Forwarding Strategies
when first reading the documentation." in QuickStart section.
Probably I should place it in top of ForwardingStrategies section.

 > On both of these points, I haven't thoroughly looked into the
 > documentation, the implementation, or played around with actual code
 > at all, which is part of the reason that I didn't think it would be
 > fair for me to write a review. However, I did play around with the
 > code snippet in the Overview section of the documentation. So, I
 > believe, here's how you would write my_plus using Egg:
 >
 > struct little_plus
 > {
 >    template<class Me, class X, class Y>
 >    struct apply
 >        : boost::remove_cv<X>
 >    { };
 >
 >    template<class Re, class X, class Y>
 >    Re call(X &x, Y &y) const
 >    {
 >        return x + y;
 >    }
 > };
 > typedef egg::function<little_plus> my_plus;
 >
 > ... and here's how you would write it normally:
 >
 > struct my_plus
 > {
 >    template<class> struct result;
 >    template<class Me, class X, class Y>
 >    struct result<Me(X,Y)>
 >        : boost::remove_cv<X>
 >    { };
 >
 >    template<class X, class Y>
 >    typename result<my_plus(X,Y)>::type
 >    operator()(X x, Y y) const
 >    {
 >        return x + y;
 >    }
 > };
 >
 > To my eye, I can't see how Egg makes things that much easier. It
 > doesn't look particularly helpful.

I was feeling annoyed that I had to write `typename result<my_plus(X,Y)>::type`.
Also, your `result<>` implementation is wrong.
It is error-prone to write ResultOf-conforming FunctionObject without some indirection.

 > Now, here's how you would write it
 > in C++0x:
 >
 > struct my_plus
 > {
 >    template<class X, class Y>
 >    typename boost::remove_cv<X>::type
 >    operator()(X x, Y y) const
 >    {
 >        return x + y;
 >    }
 > };
 >
 > So, as a new user, I'm going to spend my time learning C++0x! Why
 > should I instead sacrifice time learning Egg? If that question remains
 > unanswered for other potential users, then they will never get beyond
 > the introduction in the documentation, and you will attract no new
 > users.

It might depend on when C++0x will be available for users.
FWIW, many Egg components will be useful even in C++0x.

 > Meanwhile. there's all this great technology in Egg going to waste.
 > I'm not sure if the situation is as bad as I'm describing it, and if
 > so I'm not sure if I have any good suggestions to help. Perhaps, I
 > would again suggest looking at Boost.Iterator as an example.
 > Boost.Iterator has all sorts of gizmos, tricks, workarounds, etc. in
 > the backend; I get dizzy thinking about it! I don't want to know about
 > a single one of them, but I'm grateful for all of them. From my
 > perspective, as a user, I know std::iterator and the classic SGI
 > Iterator concepts. Then, I see Boost.Iterator makes these concepts
 > easier to program for (by providing archetypes to test against) and
 > more expressive (by expanding the number of concepts). Inheriting from
 > std::iterator is fragile and doesn't do much for you. Boost.Iterator
 > provides iterator_facade, so I inherit from it instead and get stuff
 > for free. Switching from std::iterator to iterator_facade is fairly
 > intuitive, and the new iterator classes are generally easier to write.
 > So, for all these reasons, I choose to learn and use Boost.Iterator.
 >
 > Maybe the key is that Boost.Iterator starts from something everyone is
 > already familiar with - the standard library's iterator utilities.
 > Since people are familiar with the standard and its shortcomings,
 > Boost.Iterator is more intuitive and accessible. So, maybe Egg should
 > start from the same place.
 >
 > In the Quick Start section of the documentation, as a motivating
 > example you use a code snippet to show the problems with function
 > templates. However, most of these problems are solved by the standard
 > AdaptableBinaryFunction concept. So, the question is not whether Egg
 > is more useful than a function template, but whether Egg is more
 > useful than an AdaptableBinaryFunction. So, your motivating example
 > should start not from ...
 >
 > template< .. >
 > .. make_filtered( .. )
 > {
 > ..
 > }
 >
 > ... but from ...
 >
 > template< .. >
 > struct make_filtered : std::binary_function< .. >
 > {
 > ..
 > }

You pointed an interesting comparison.
I could say "As std::iterator<> is fragile, std::unary/binary/nary_function<> is fragile.".
E.g. It would be difficult to express `make_filtered(make_filtered(src, &is_not_X), &is_not_Y)`
without PolymorphicFunctionObject concept.

 > Again, people are already familiar with the standard library and its
 > shortcomings. By framing your library in terms of solving problems
 > with the standard, rather than solving problems with static
 > initialization, the forwarding problem, result_of/lambda
 > compatibility, etc., I think your library would appear more useful.

Probably I should have emphasized advantages of PolymorphicFunctionObjects.
I assumed users were already familiar with it while using Boost.Lambda.

 > (The other more technical/mundane issues can be left in the backend;
 > users would be grateful for them without having to be specifically
 > aware of them.) Of course, the obvious problem with the standard is
 > that there's no std::nary_function<>. I think most C++ programmers can
 > relate to that problem. Can't function_facade be viewed as a solution?

The problem is that std::unary/binary/nary_function<> is not Polymorphic.
E.g. they are not usable when you write an overloaded function.

 > Ideally, you could start not only with the C++98 library but also with
 > TR1/C++0x. Boost.Function has already been accepted into TR1. Now,
 > couldn't the differed callback std::function<> be viewed as simply a
 > specific instance of an Egg "function adaptor"?

Yes. std::function<> can be regarded as one of the FunctionAdaptors.
It is similar to egg::mono, but it performs type-erasure.

 > I think it would be
 > exciting to see a new rewrite/drop-in-replacement/extension of
 > Boost.Function (or maybe call it Boost.Functor) that would move
 > function objects beyond both C++98 and C++0x. Egg could be a first
 > step in that direction. It's mostly a matter of refocusing your design
 > objectives and refactoring the code accordingly.

Sorry, I couldn't understand what you want.
Any (imaginary) example?

 > So, those are just some thoughts that occurred to me while I was
 > fiddling around with Egg over the weekend. In it's current state, I
 > have trouble getting excited about it. But I can see Egg has the
 > potential to become something that would appeal to me. Regardless, I
 > admire Shunsuke's openness and courage in submitting his work for
 > public scrutiny, and I hope my comments are helpful and encouraging in
 > at least some small way.

It is really helpful.

Regards,

-- 
Shunsuke Sogame