Re: [boost] Egg 2nd request for reviews

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-04-14 22:48:35

On Sat, Apr 12, 2008 at 2:14 PM, Giovanni Piero Deretta
<gpderetta_at_[hidden]> wrote:
<snip>
> On Sat, Apr 12, 2008 at 6:40 PM, Daniel Walker
> >  My initial interests in Egg stems from my experience last year looking
> >  into the whole lambda/result_of compatibility issue (as some of you
> >  may remember since you gave me great feedback and advice!). It was
> >  fairly simple to modify lambda to work with TR1 result_of. (I think my
> >  patch may have gotten lost in the SVN migration.) I also tried to
> >  bring lambda completely up to date by making it play nicely with TR1
> >  bind and placeholders as well. But the project died under feature
> >  bloat; bind and placeholders were too much for me, or at least, it got
> >  too tedious to keep my interest. I think it doesn't really matter,
> >  though. Given the most recent draft of C++0x (n2588), there will no
> >  longer be result_of/lambda compatibility problems as std::result_of
> >  will always work by fiat - even with lambda-style functors.
>
> Yes, but lambda will still expect bound funcions to use the sig
> protocol. Unless it
> is modified to use boost::result_of of course.
> I think that just making lambda a result_of compatible (both ways) is
> enough. Bind compatibility is not necessary.
> Do you think you could resurrect the patch.

Sure, I can look into it. I'm not sure if I would do it the same today
as I did last year, but I'll look into it and send something to the
list.

>
> > Actually,
> >  things are progressing so quickly with C++0x that Boost.Lambda itself
> >  may be made obsolete by the new lambda language extension (n2550),
> >  which apparently was adopted sometime in the last six weeks. I think
> >  that's great news! But I'm not sure what it means for Egg.
>
> I wish it was that easy! C++0x lambdas are monomorphic. Support for
> polymorphic lambdas has been dropped because of feared implementation
> problems (i guess it was just that monomorphic lambdas had an higher
> chance of being standardized with such a tight time constrain).
>
> And anyways, in some cases boost.lambda has notational advantages with
> respect of explicit lambdas (especially for very small functions)

Yeah, I guess you're right that Lambda won't be completely obsolete.
Still, since lambda functors are defined very near the call site where
types are generally known, their lack of polymorphism may not be that
bad. Correct me if I'm wrong (I'm not even sure if I have the syntax
right), but won't the following work?

template<class Iterator>
void f(Iterator first, Iterator last)
{
    typedef typename std::iterator_traits<
        Iterator
    >::value_type value_type;
    std::for_each(first, last, [](value_type const& x)
        {
            // do something ...
        }
    );
}

If that works than, C++0x lambdas would suffice for a large subset of
Boost.Lambda use-cases. Also, the C++0x lambda functors themselves are
not (parametric) polymorphic, but their arguments could be sub-type
polymorphic, right?

> >
<snip>
> > For example, in C++03
> >  (and C++0x) there's a need for more flexible/powerful function
> >  parameters. C++0x variadic functions provides for a variable number of
> >  type-safe parameters, but what if a user wants to change their order
> >  or name them? In other words, in either standard, when users need more
> >  advanced function parameters, how does Egg relate to Boost.Parameter?
>
> ATM it wouldn't be pretty to have them cooperate without built in
> support. On the other hand combining both libraries wouldn't be hard.
> In fact I think that having Boost.Parameters
> macros automatically generate egg-boosted function objects
> (pipability, result_of compatibility, etc) would make a great user
> interface.

Hmm, yes, you may be onto something there.

> >  Another example: there's a long standing practice of currying
> >  functions with bind, which will be standardized in C++0x. How does
> >  Egg's curring "function adaptor" relate to std::bind? (These are just
> >  some questions that jumped out at me on my first impression. I haven't
> >  spent a lot of time trying to reason through the documentation.)
> >
>
> They are just two different ways to do partial application. Both
> return result_of compatible function objects. They would work just
> fine togheter (you can bind a curryied object and viceversa)

Yes, but bind already curries functions. Why use Egg's currying adaptor instead?

Daniel